TECHNICAL SUPPORT
Published 2026-03-29
When engaging in product innovation, the biggest fear is that if the main control chip is replaced, the originally well-adjustedservowill stop turning. Many friends got a new STM32 development board and wanted to move theservoprogram originally used on other boards, but found that it either didn't respond or shook violently. In fact, as long as you clarify a few key points of transplantation, it is not complicated at all. Today we will talk about how to smoothly "move" theservoprogram between different STM32 models.
The core of the servo control is to output a PWM wave with a period of about 20ms and a high-level time ranging from 0.5ms to 2.5ms. Therefore, the first step in code migration is to find the timers and channels on the new board that can generate PWM. Your original program used CH1 of TIM2, but now you may have to change it to CH2 of TIM3. This correspondence must be confirmed clearly in the data sheet of the chip. The change is actually just a matter of a few parameters. Once the timer number and channel number are changed, most of the code can be used.
After changing the timer configuration, don't forget to check the clock frequency. Different models of STM32 may have different clock sources for the system clock and timer. For example, the original 72MHz main frequency used in the F1 series may become 48MHz when switched to the F0 series. At this time, you need to recalculate the PWM frequency division coefficient and reload value to ensure that the final output PWM period is still 20ms. To put it simply, the two parameters ARR and PSC are recalculated based on the clock of the new chip to ensure that the servo can receive the signals it recognizes.
When selecting pins, don't just find a GPIO and connect it. You should first look for those pins with the "" function, which are hardware PWM output pins. The advantage of using hardware PWM is that it does not occupy CPU resources, the pulse output is very stable, and the servo rotates smoothly. If you have to use ordinary GPIO to simulate through the delay function, the CPU will be exhausted, and if the program becomes slightly more complicated, the timing will be easily messed up, and the servo will definitely shake.
After selecting the pin, in the program initialization part, you need to set the GPIO working mode to multiplexed push-pull output. This is like assigning job responsibilities to this pin and telling it "you are responsible for outputting the PWM signal." In addition, if the original circuit board has a pull-up resistor but the new one does not, you need to consider whether to enable the internal pull-up in the code to ensure that the pin has a certain level state when idle to avoid signal interference.
Many people have a headache when calculating frequency. In fact, there is a simple way. The PWM cycle required by the servo is 50Hz, which is a cycle of 20ms. No matter which timer you use, the goal is to get the frequency to 50Hz. The calculation formula is simple: timer output frequency = system clock / (PSC+1) / (ARR+1). You first set the PSC to a convenient number, such as 7200-1, and then reverse the ARR value so that the final result is close to 50Hz.
For example, if the system clock is 72MHz and you set PSC to 7200-1, then the counting frequency of the timer becomes 10kHz. To make the output frequency reach 50Hz, ARR must be set to 200-1, so that every 200 numbers are counted, which is 20ms. Different chips have different main frequencies, so you can calculate according to this idea to ensure that the final calculated ARR and PSC are both integers, and the ARR should not exceed the maximum count value of the timer, so that the program will run without problems.
If you want one board to control several servos at the same time, it depends on how many channels the timer has. A timer usually has 4 channels, each channel can independently output a PWM, and the frequency is shared. Therefore, as long as your servos all work at 50Hz, you can use one timer to drive 4 servos, which can save a lot of timer resources. You only need to configure several channels during initialization and set their comparison values respectively.
If more than 4 servos need to be controlled, a second timer must be enabled. When transplanting, you can write the initialization code for controlling a single servo as a function, call it as many times as you need to control, and pass the timer number and channel number as parameters. In this way, the code is highly reusable, and it will be easy to maintain no matter how many servos are added in the future. Remember, the compare register of each channel is independent, and you can operate it separately when setting the duty cycle.
The program is burned in, but the servo does not respond? Don't worry, start with the simplest hardware. Use a multimeter to check whether the power supply and ground of the servo are connected correctly. The servo has high current requirements, so you must use an external power supply. Don't expect the 3.3V on the development board to be able to power up. If there is no problem with the power supply, use an oscilloscope or logic analyzer to see if there is an output waveform on the chip pins, and see if the period and pulse width are correct.
If the waveform is correct but the servo still does not turn, it may be a problem with the code logic. You can write the simplest test program first, and output a fixed high level of 1.5ms to return the servo to the middle position. If this can be turned on, it means that there is no problem with the underlying driver, and the problem lies in your control logic. Gradually add functions, change a little at a time, and use the elimination method to quickly locate the problem, which is much faster than guessing by yourself.
Now that the basic transplantation is done, we can do some tricks. For example, if you want the servo to turn to a specific angle, you can write an angle conversion function to map 0 to 180 degrees to a pulse width value of 0.5ms to 2.5ms. In this way, you don't need to remember those complicated time values. You can directly call the function and pass in the angle. The readability and portability of the code will be greatly improved, and others will understand it at a glance.
For another example, you can also add software filtering to avoid sudden changes in the control signal causing the servo to "tremble". In actual projects, the data sent back by the sensor will inevitably have jitter. If you add a simple moving average filter to the program and then send it to the servo, the movement will be much smoother. Encapsulate these extended functions into independent modules. When transplanting to other projects next time, these "accumulations" can be directly used, and development efficiency will be doubled.
Where is your servo transplantation project stuck? Is it because the pin configuration is not clear, or is the frequency calculation always wrong? Welcome to leave a message in the comment area to talk about your experience. If you think this article is helpful to you, remember to like and save it. You are also welcome to search our company's official website for more practical cases and code templates!
Update Time：2026-03-29
Contact Kpower's product specialist to recommend suitable motor or gearbox for your product.
