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

[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)

[MBo�?.7]

We use timers and their interrupts, but they are switched off/on when situation requires it(meaning that there are times when we have time to do something else than monitor pulses). Also sometimes inputs are read as interrupt and other times are pooled in the loop.

[S.Ma]

Well, to reduce jitter, use interrupts or even code in SRAM (core pipeline, ART accelerator for Flash), put all IRQ vectors in RAM, and adjust IRQ priorities.

After this, it's a matter at calculating the max jitter and look at the ASM instructions.... right?

In STM32L4 there is CCM SRAM code dedicated which also reduce jitter coming from DMA bus access cycle.

[Pavel A.]

Use a FPGA or maybe CPLD instead of MCU.

-- pa

[MBo�?.7]

KIC84: Yes, will do. I guess F4 or L4 will be our choice for now, we are still investigating and testing but we now know what to look for.

Pavel: We considered FPGA/CPLD but dismissed it.

Thanks all!