stm32 gpio speed - Page 1
Forum section: electronics / general

author: alireza7
author_rank: Regular Contributor
timestamp: July 28, 2018, 05:36:15 pm
content: hiwhat does the GPIO_Speed setting do?GPIO_Speed_2MHz /*!< Low speed */GPIO_Speed_25MHz /*!< Medium speed */GPIO_Speed_50MHz /*!< Fast speed */GPIO_Speed_100MHzdoes 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??

author: newbrain
author_rank: Super Contributor
timestamp: July 28, 2018, 06:03:07 pm
content: As an example of this, have look at table 52 in the STM32F042 datasheethttps://www.st.com/resource/en/datasheet/stm32f042c4.pdfRise and fall times vary from a handful of ns to a hundred according to the OSPEED bits.

author: ogden
author_rank: Super Contributor
timestamp: July 28, 2018, 06:12:40 pm
content: Please don't double-post.https://www.eevblog.com/forum/beginners/stm32-gpio-speed/msg1707104/#msg1707104

author: JS
author_rank: Frequent Contributor
timestamp: July 29, 2018, 12:14:10 am
content: 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 lookJS

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2018, 11:21:46 am
content: 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: 17MHzSpeed 1: 31MHzSpeed 2: 31MHzSpeed 3: 41MHz

author: ogden
author_rank: Super Contributor
timestamp: July 29, 2018, 04:12:28 pm
content: Quote from: Siwastaja on July 29, 2018, 11:21:46 amWithout 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.

author: newbrain
author_rank: Super Contributor
timestamp: July 29, 2018, 04:54:16 pm
content: Quote from: Siwastaja on July 29, 2018, 11:21:46 amThose 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:#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 */

author: Siwastaja
author_rank: Super Contributor
timestamp: July 29, 2018, 06:13:36 pm
content: Quote from: ogden on July 29, 2018, 04:12:28 pmYou 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 themagnitudeor ballpark of things.QuoteYeah, 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.

author: newbrain
author_rank: Super Contributor
timestamp: July 29, 2018, 06:36:43 pm
content: Quote from: Siwastaja on July 29, 2018, 06:13:36 pmMHz are there in the DS, but, yes, they are qualified with loading and Vcc ranges.Quote from: Siwastaja on July 29, 2018, 06:13:36 pmAll the IDEs I use (VS, VS Code, Eclipse in various form, PSoC cReator, AS 7 etc...) do that for me, thankfully.

author: ogden
author_rank: Super Contributor
timestamp: July 29, 2018, 07:41:08 pm
content: Quote from: Siwastaja on July 29, 2018, 06:13:36 pmKindergarden argument. You better grow up first.QuoteSure. 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.QuoteYou 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.QuoteDon't necessarily work out to what exactly numbers?

author: MT
author_rank: Super Contributor
timestamp: July 30, 2018, 03:17:24 am
content: Quote from: alireza7 on July 28, 2018, 05:36:15 pmThe 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)

author: Siwastaja
author_rank: Super Contributor
timestamp: July 30, 2018, 02:03:41 pm
content: Quote from: ogden on July 29, 2018, 07:41:08 pmIt didn't appear to you that justmaybethere was an actual reason why I needed to build the communication between the STM32 and the Raspberry, and there might beotherreasons 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 justmaybeI 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.

author: ogden
author_rank: Super Contributor
timestamp: July 30, 2018, 10:52:17 pm
content: Quote from: Siwastaja on July 30, 2018, 02:03:41 pmI don't care aboutreasonsof 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.