Which MCU for time critical GPIO application?

[MBo�?.7]

Hi!

We have an application which runs on PIC24H, we would like to port it to another MCU. Application is extremely time critical, meaning that we need extremely deterministic code behaviour. In short, there are pulses which are obtained via special hardware to GPIO pins, data is analyzed right away. Processing of data is not complex(we don't need a beefy cpu/mcu to do it). After analyzing the data GPIO output pins are written to their values.

App in 3 short lines:

• process input pins
• determine pattern within processing of input pins
• based on the received pattern write output pins

We investigated which MCU to use, STM32H7 was our first choice due 400MHz clock, but it can't toggle pins near that speed at all so we disregarded it. It seems F7 and F4 are the same due slower APB.

Any STM32 mcu for the job? Maybe M0?

PIC24H is working at 48MHz, we can toggle the pin in 25ns, we would be grateful with at least 2x speed for future upgrades. So MCU which can run deterministic code and toggle pins with at least 96MHz (12.5ns) would be just fine. We don't need toggling of the pins at constant fast rate, we need a mcu which can toggle it in less than 25ns. We can't waste cycles while toggling, if one cycle is off we loose synchronization. Everything must be done in one cycle precision(or two but constant two cycles), so code should be 100% deterministic.

Please let me know if I'm missing something or if what we need can be done using some other methods. Just keep in mind that if one cycle is lost(due cache or similar) we loose signal sync and app will not do it's work right or at all.

Thanks!

Br

[MBo�?.7]

Sorry, wrong frequency! PIC24H works at 40MHz -> 25ns.

[Ozone]

> Application is extremely time critical, meaning that we need extremely deterministic code behaviour. In short, there are pulses which are obtained via special hardware to GPIO pins, data is analyzed right away. Processing of data is not complex(we don't need a beefy cpu/mcu to do it). After analyzing the data GPIO output pins are written to their values.

Sure a STM32 can do, even a M0/M0+.

But I think a proper architecture of you application is more important, perhaps through selecting an appropriate realtime OS.

My company use FreeRTOS and SafeRTOS for realtime machinery control (basically an ECU).

> We investigated which MCU to use, STM32H7 was our first choice due 400MHz clock, but it can't toggle pins near that speed at all so we disregarded it. It seems F7 and F4 are the same due slower APB.

Pin toggling is no real measure of core speed.

MCUs - at least modern one's - are build to utilize peripherals as autonomously as possible, without permanent core involvement.

Use DMA, FIFOs and interrupts to get the core involved.

> PIC24H is working at 48MHz, ...

If remembering correctly, PIC24 is a 16 bit core.

My recommendation - avoid a one-to-one port of your software. 32-bit machines like ARM Cortex don't do very well with all data misaligned.

I remember a former workmate of mine tried to re-compile PIC18 bit-bang code on a Cortex M3, and wondered about the mediocre preformance.

[Vangelis Fortounas]

Hi

This is STM32F405 Datasheet.

[Uwe Bonnes]

Vangelis: Switching speed != toggle speed. However toggle speed depends on coding style.

Abdiel: Can you perhaps use a timer for your task?

https://jeelabs.org/2018/toggling-io-pins/ talks about 84 Mhz toggle speed on a 168 F4.

[Vangelis Fortounas]

Hi.

It was not my intention to show switch speed but max freq. (i miss to highlight the Max freq)

100 MHZ has 10ns toggling time. STR instruction executes in one cycle so it is possible to produce the 100 MHZ/2 freq by write to ODR directly.

[MBo�?.7]

Ozone: Hm, wouldn't a RTOS include a lot of other stuff which are run in the other threads? Which would then mess up my timely critical function? Like I wrote, we need a deterministic code with ability of pin to be toggled below 25ns. When pin should be toggled no interrupt or other work can be executed because if it does, our code goes out of sync. We don't have experience with RTOS and we don't have problems with mili seconds, we need precision in nano seconds.

Vangelis: The best I can do currently on STM32F407 when switching pin from hi to low is 41ns, that would be around 24MHz... Guess I look into it more!

Uwe: I have no idea how to code that stuff with a timer and determinism...

Example, I need to toggle the pin like this:

• 2 pulses with 25ns (1 pulse = toggle time, 25ns pin HI, 25ns pin LOW)
• pause for 30ns
• 4 pulses with 25ns
• pause for 25ns
• 17 pulses with 25ns
• 3 pulses with 25ns

I would need to configure timer each of this situations but I don't have time, pulses must go one after another as the pauses do...

I'll investigate STM32F407 datasheet and jeelabs for more info. Thnx!

[Ozone]

> Like I wrote, we need a deterministic code with ability of pin to be toggled below 25ns.

I would avoid implementing this in bitbanging software, if possible. Which doesn't mean you can't do it, or an STM32 is not capable.

> We don't have experience with RTOS and we don't have problems with mili seconds, we need precision in nano seconds.

Well, agree. Our application is based on a 10ms cycle time, and operates on CAN sensors/data.

> Example, I need to toggle the pin like this:

• 2 pulses with 25ns (1 pulse = toggle time, 25ns pin HI, 25ns pin LOW)
• pause for 30ns
• 4 pulses with 25ns
• pause for 25ns
• 17 pulses with 25ns
• 3 pulses with 25ns

Why not trying to solve it in hardware ?

A (pre-loadable) shift register, with a clock rate 40MHz ?

Or a bit time of 5ns, and an appropriate number of bits to achieve your sequence length ?

With a timing like yours, you hog any available MCU in your price range. DSPs are specifically made for tasks like yours, but there you are in for a steep learning curve ...

[MBo�?.7]

Ozone: DSP development time lasts(costs) more. DSP chip costs more. Not an option.

"appropriate number of bits to achieve your sequence length" - There can be a lot of bits involved, up to 140 pulses on output...

Vangelis: 100 MHZ has 10ns toggling time - that would be more than enough!

[Vangelis Fortounas]

"that would be more than enough!"

But not by software. . By software you can produce maximum 168/2 = 84MHZ (12ns) for a limited number of cycles by continuously writing STR instructions (assembly). And no Wait States, Interrupts, Power optimizations, etc

[S.Ma]

Your extremely time critical requires extrememly good understanding of the details, right?

[MBo�?.7]

Managed to get 84MHz with STM32F407 which is enough (12ns)! So determinism is left... What if code branches and F4 doesn't cache that branch and we lose cycles and signal desynchronizes...

KIC8462852: Sure, but can't say more about the app regarding NDA, protecting the IP and such... In PIC24H we do not use nothing special to get it work well but those 25ns is getting to big as signals we analyze are getting pulses shorter than that.

[S.Ma]

Are you using EXTI interrupts or just a main loop polling monitoring the inputs, calculate and drive the outputs?

Are there other interrupts in the system? (which can cause jitter)