stm32 gpio speed

[alireza7]

hi

what does the GPIO_Speed setting do?

GPIO_Speed_2MHz  /*!< Low speed */
GPIO_Speed_25MHz /*!< Medium speed */
GPIO_Speed_50MHz /*!< Fast speed */
GPIO_Speed_100MHz

does it change the gpio pin slew rate? or it changes propagation time of gpio pin?

if it changes the gpio pin slew rate ,  how can this possible for a digital gate to change its slew rate during operation time??

[newbrain]

As an example of this, have look at table 52 in the STM32F042 datasheet
https://www.st.com/resource/en/datasheet/stm32f042c4.pdf

Rise and fall times vary from a handful of ns to a hundred according to the OSPEED bits.

[ogden]

Please don't double-post.

https://www.eevblog.com/forum/beginners/stm32-gpio-speed/msg1707104/#msg1707104

[JS]

Could be an intresting experiment to look in the scope under different loads... I do have a few STM32 but no time or a high bandwidth scope which woukd also be nice, 100MHz seems on the edge, but ceertainly enough to take a look

JS

[Siwastaja]

Slew rate to limit EMI. Those megahertz names are complete misleading nonsense (and yet another indication of the broken library they come with).

For those interested, I tested different STM32 gpio slew rate settings for SPI communication between a STM32 and Raspberry Pi, generating long test vectors and looking for any corruption. The cable length was around 15 cm, but the Raspberry side layout is non-optimal (especially regarding ground pins). Unterminated line. STM32 being slave, the MISO pin speed was altered, with the following results:

Speed 0: 17MHz
Speed 1: 31MHz
Speed 2: 31MHz
Speed 3: 41MHz

[ogden]

Slew rate to limit EMI. Those megahertz names are complete misleading nonsense (and yet another indication of the broken library they come with).

For those interested, I tested different STM32 gpio slew rate settings for SPI communication between a STM32 and Raspberry Pi, generating long test vectors and looking for any corruption. The cable length was around 15 cm, but the Raspberry side layout is non-optimal (especially regarding ground pins). Unterminated line. STM32 being slave, the MISO pin speed was altered, with the following results:

Speed 0: 17MHz
Speed 1: 31MHz
Speed 2: 31MHz
Speed 3: 41MHz

Without specifying properties (at least capacitance) of Raspberry Pi pin, your test (using your words) is nonsense. BTW it is ok to specify pin speed in MHz. Datasheet have rise/fall time specs as well.

[newbrain]

Slew rate to limit EMI. Those megahertz names are complete misleading nonsense (and yet another indication of the broken library they come with).

Those are from the standard peripheral library, but the speeds in MHz are also part of the datasheets, and match the constants for worst/average loading and Vcc case.

The HAL contains, I would say, a saner definition:

Code: [Select]

#define  GPIO_SPEED_FREQ_LOW         ((uint32_t)0x00000000)  /*!< IO works at 2 MHz, please refer to the product datasheet */
#define  GPIO_SPEED_FREQ_MEDIUM      ((uint32_t)0x00000001)  /*!< range 12,5 MHz to 50 MHz, please refer to the product datasheet */
#define  GPIO_SPEED_FREQ_HIGH        ((uint32_t)0x00000002)  /*!< range 25 MHz to 100 MHz, please refer to the product datasheet  */
#define  GPIO_SPEED_FREQ_VERY_HIGH   ((uint32_t)0x00000003)  /*!< range 50 MHz to 200 MHz, please refer to the product datasheet  */


[Siwastaja]

Without specifying properties (at least capacitance) of Raspberry Pi pin, your test (using your words) is nonsense.

You are nonsense.

Testing a practical thing is OK for practical purposes. I know how to setup a perfect measurement and report everything in a scientifically sound way, but I have better things to do as well. I build such complex systems that I cannot afford wasting time in every little detail, when a simple test gives an idea of the magnitudes.

Sharing a simple practical result as a grain of salt is often useful for others. You are free to ignore the result if you are uninterested. For others, it can be a valuable pointer regarding the magnitude or ballpark of things.

BTW it is ok to specify pin speed in MHz. Datasheet have rise/fall time specs as well.

Yeah, but the datasheet rise/fall times don't necessarily work out to those numbers, hence they are nonsense, like other library things which are invention of the library writer instead of related to the actual part datasheet.

Good luck trying to remember those define names. Oh wait, you are expected to copy-paste the code containing them.

[newbrain]

Yeah, but the datasheet rise/fall times don't necessarily work out to those numbers, hence they are nonsense, like other library things which are invention of the library writer instead of related to the actual part datasheet.

MHz are there in the DS, but, yes, they are qualified with loading and Vcc ranges.

Good luck trying to remember those define names.

All the IDEs I use (VS, VS Code, Eclipse in various form, PSoC cReator, AS 7 etc...) do that for me, thankfully.

[ogden]

Without specifying properties (at least capacitance) of Raspberry Pi pin, your test (using your words) is nonsense.

You are nonsense.

Kindergarden argument. You better grow up first.

Testing a practical thing is OK for practical purposes.

Sure. Those who will need to connect stm32 uC to undisclosed model of Raspberry PI using 15cm of unknown type cable, will find your practical thing useful.

I know how to setup a perfect measurement and report everything in a scientifically sound way, but I have better things to do as well. I build such complex systems that I cannot afford wasting time in every little detail

You are experienced builder of complex systems, had time to build test that generates long test vectors and looks for any corruption, but had no time to check rPI I/O pin specification. Right. 

BTW it is ok to specify pin speed in MHz. Datasheet have rise/fall time specs as well.

Yeah, but the datasheet rise/fall times don't necessarily work out to those numbers, hence they are nonsense

Don't necessarily work out to what exactly numbers?

[MT]

hi

what does the GPIO_Speed setting do?

GPIO_Speed_2MHz  /*!< Low speed */
GPIO_Speed_25MHz /*!< Medium speed */
GPIO_Speed_50MHz /*!< Fast speed */
GPIO_Speed_100MHz
does it change the gpio pin slew rate? or it changes propagation time of gpio pin? if it changes the gpio pin slew rate ,  how can this possible for a digital gate to change its slew rate during operation time??

The drive capability and slew rate are directly referenced to capacitive and resistive loads on the pin plus the capacitive load of the GPIO pin itself , its spec'ed in data sheets, therefore switching in more drivers gives more bananas to the beat! Try it, toggle GPIO at 50Mhz, apply a load, then vary OSPEED bits, watch a oscope to see the magic.(dont smoke the GPIO by tying to large loads)

[Siwastaja]

You are experienced builder of complex systems, had time to build test that generates long test vectors and looks for any corruption, but had no time to check rPI I/O pin specification. Right. 

It didn't appear to you that just maybe there was an actual reason why I needed to build the communication between the STM32 and the Raspberry, and there might be other reasons I needed to test the reliability of the complete chain (using generated test data instead of actual production point cloud data) - including software timing, and to analyze the Raspberry's CPU load - and just maybe I happened to have a few extra minutes so that I played around with the speed setting as well, just for fun. For production, we are using the highest speed setting IIRC. My "measurement" was not needed to determine this.

You know, maybe I didn't do my "test" just to entertain you on the forum? Maybe it was a side result of something more meaningful? Just maybe? 

Guess what? Raspberry Pi GPIO is not properly specified. So the reason I did "not look up" the spec is that it doesn't exist. The GPIO header hasn't signal integrity thought out too well. Raspberry Pi is a toy you just end up using. If you need to work with it, you'll get very practical about things.

Again - I encourage you to just ignore any information you don't find useful. I prefer having any publicly available datapoints in discussions instead of completely empty babble, but you need to understand what they mean. Not every piece of information is a scientific gem in itself. I find "ballpark pointers" highly useful, and will be supplying them in the future as well, some better, some worse. Deal with it .

About the complexity? The board has 14 impedance controlled and length matched parallel buses of 12 bits each, over 4000 vias, 500-watt software-controlled multiphase switch mode converters, BLDC drivers, MEMS sensors, etc. Getting it all routed in 6 layers only was a demanding task, and 35000 lines of code exists at the moment. For a one-man quickie in less than a year total, once you work with this kind of task, you stop worrying about whether your report of IO speed setting on a casual forum discussion is scientifically sound and complete. 

Bullshit or not? You decide, and you are free to think whatever you want to. I'm not interested.

[ogden]

You know, maybe I didn't do my "test" just to entertain you on the forum? Maybe it was a side result of something more meaningful?

I don't care about reasons of your funny test. Just wanted to tell other readers of this thread that you are wrong saying that library megahertz names are complete misleading nonsense. The same about datasheet gpio slew rate specs.