When I open up a project in STM32CubeMX and configure a UART, there's a Maximum output speed configuration (under GPIO Settings) that defaults to Very High. The options are:

  • Low
  • Medium
  • High
  • Very High

In STM32CubeMX User Manual it says the following about Maximum output speed:

GPIO maximum output speed (for communication peripherals only)
It is set to Low by default for power consumption optimization and can be changed to a higher frequency to fit application requirements.

But it's actually set to "Low" only for regular Output GPIOs. For UART TX/RX pins it's actually set to Very High.

I have a few questions regarding this:

  1. What "application requirements" would require a higher setting?
  2. Why does this settings default to Very High in UART, and Low in Output GPIO?
  3. Most importantly, can 2 UARTs with different Maximum Output Speeds talk (communicate), or should they be configured the same? What implications would occur if the UART of each side was configured differently regarding this setting?

2 Answers 2


The GPIO speed setting just configures the drive strength or the ability how much the pin can source and sink current. More current means faster signal transitions to heavier capacitive loads.

1) For example driving a FET gate which is highly capacitive and it needs to spend minimum time being halfway on

2) Somebody has chosen these defaults often just because you need to have some basic default setting that mostly work. Using say 3 megabaud with long wires for debug UART might be safer to have high drive ability, but blinking a LED on GPIO once per second does not matter which setting is used.

3) Of course they can communicate if the baud rate used is slow enough that signal slew rate does not contribute to the error much. Weakest drive strength can work to about 2 MHz maybe, depends on which MCU is used.

  • \$\begingroup\$ Regarding 3, how do I know if my baud rate is "slow enough"? It's 115200 \$\endgroup\$
    – Alaa M.
    Commented May 15, 2019 at 10:23
  • 1
    \$\begingroup\$ You look at the numbers in datasheets. If weakest setting can output at least 2MHz frequency, that is roughly 17 times the 115200 bit rate you need. Looking things from the maximum rise/fall time of 100 ns, your bit period is 8680 ns, so your bits are almost 87 times longer so spending about 1% of bit time changing the state is nothing in UARTs, as UART samples the pin at 16x the bitrate, or about every 543ns at 115200 bitrate. \$\endgroup\$
    – Justme
    Commented May 15, 2019 at 12:34

This corresponds to the drive strength configuration of the GPIO pin, configured by the OSPEEDR register bits. For each pin, there is 4 possible settings. Choosing stronger output drive allows higher maximum operating frequency (because the transitions are made faster), but lead to higher power consumption when the pin toggles, and higher EMI emissions. Lower strength means lower EMI, lower power consumption and lower max speed.

Have a look at the datasheet of the specific MCU you're using to check what exactly this translates to. For example, for STM32F405/407 here it is (chapter 5.3.16: I/O port characteristics, paragraph Input/output AC characteristics):

enter image description here

So you see that even at the minimum setting, in the worst case mentioned, you can expect 2MHz. This is probably much higher than what your UART is configured at already, so there is actually no need to set it to "very high". They probably do it by default so to be on the safe side, but you don't have your baud rate configured to 100Mbps, do you?

As a general advice, keep this setting to "low" unless really necessary.

Now, of course two UART configured with different settings can talk together (provided that the bit rate is lower than the max speed what the GPIO can sustain according to the above table and the setting you chose). The UART configured with a stronger setting will have its output much sharper than the other, and will radiate more EMI, but they will be able to talk to each other.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.