STM32f4: How fast can GPIO really be updated?

[michael2]

Posted on June 02, 2013 at 21:41

I am using the STM32f4 series. My goal to drive an external parallel loaded DAC using data from the internal SRAM. So, I need to update the data on a GPIO port and then toggle a pin connected to the load control signal on the DAC to load the new data for each update.

So, my code looks something like this: GPIOE->

BSRRH

= 0x8000;

GPIOE->

BSRRL

= 0x8000;

GPIOE->

ODR

= DAC0[i]; Everything works and the update speed is roughly 19 MHz. I am using a 12 bit DAC, so I tried combining the ODR and BSRRL commands by making bit 15 the load signal and always high regardless of the rest of the data to save one step. This increased the speed to 21 MHz. I have the core clocked at 168 MHz and the GPIO at 100 MHz speed. Anyone know a way to do this faster? thanks

[waclawek.jan]

Posted on June 02, 2013 at 22:36

You are at 8 clocks per data write cycle, which is at least one read from memory and two writes to IO. There's not much room left then for optimisation.

If you want to squeeze out the last nanosecond, you  need to pay attention to all the detail - and you did not provide us enough of that. Also, C is not quite the way to go. Describe what you want to achieve in more detail and post the disassembly of the critical routine. You could also consider using hardware - e.g. DMA transfers to FSMC. JW

[michael2]

Posted on June 03, 2013 at 02:55 Thanks, I was afraid of that. Basically, I have a DAC that has a 12 bit input and a latching pin. Once input data has stablized, you simply apply a positive edge trigger on the latching pin to store it in the DAC each time you want to load a new value. This would be done in a continuous loop repeatedly cycling through a signal profile stored within the STM32 SRAM for analog signal generation, say like a sine wave. I would like this to be done as fast a possible and I have no other code executing at the time. I was afraid I couldn't use DMA because of the sync requirement with the load signal. Also, some people have warned me not to use assembly because it is really tricky to keep track of all the registers that might cause of lock up once you return to C. If I did use assembly, you have any guess about how much faster I might be able to process?

[Tesla DeLorean]

Posted on June 03, 2013 at 15:27

This all seems a rather ill conceived solution, for high and consistent rates an FPGA would be the way to go.

If you're willing to play a little with the profile in RAM, I would suspect 42 MHz might be achievable, but still this would likely have a hideous amount of jitter. Some logic externally to convert a toggling signal to a pulse would also mitigate some of the interfacing issues. You might be able to get 56 MHz via a timer in PWM mode generating an output pulse, and also triggering a DMA copy to the GPIO bank's ODRAlso, some people have warned me not to use assembly because it is really tricky to keep track of all the registers that might cause of lock up once you return to C. Like many things, you need a good grasp of what needs to be done, you should perhaps look to some team members with actual and specific knowledge rather than ones without it for technical advice.

[michael2]

Posted on June 03, 2013 at 17:06

Forgot about jitter. Thanks, I'm trashing the idea for high speeds.