Skip to main content
MBo�?.7
Associate II
Apr 26, 2019 8:27 AM UTC
Question

Which MCU for time critical GPIO application?

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

This topic has been closed for replies.

16 replies

MBo�?.7
MBo�?.7Author
Associate II
Apr 26, 2019 1:42 PM UTC

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
Principal
Apr 26, 2019 1:47 PM UTC

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.
Apr 26, 2019 1:58 PM UTC

Use a FPGA or maybe CPLD instead of MCU.

-- pa

MBo�?.7
MBo�?.7Author
Associate II
May 2, 2019 6:09 AM UTC

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!