Which MCU(Cortex-M) for time critical GPIO application?

0
votes

We have an application which runs on PIC24H, we would like to port it to another MCU, preferably ARM Cortex. 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

PIC24H is working at 40MHz, 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 80MHz (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 on Cortex-M. 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

1
cperformanceassemblygpiocortex-m
App in 3 short lines: 1.) Process input pins 2.) Determine pattern within processing of input pins 3.) Based on the received pattern write output pins - mbozic
Unless the hardware platform you're currently using is being obsoleted, why change? Or are there other parts of your applications requirement that necessitate a change in hardware? Remember that creating new hardware (especially custom hardware) is time-consuming and expensive. - Some programmer dude
There's two bottlenecks apart from system clock: interrupt latency and GPIO toggle speed. I kind of doubt that those two together are so small that they are negligible in your current application? If so, what's your current latency and how did you specify it. If this is where you go "umm", forget about this whole spec. - Lundin
Do you need an ARM at all? FPGA? - Martin James
Well I RTFM of the dsPIC and you have "Port Output Rise Time" typical 5ns, max 10ns. "INTx Pin High or Low Time (input)" min 20ns. Your spec does not add up, your current application does not toggle the pin in 25ns. Get your timing spec straight in your current application before considering porting. And well, invest in an oscilloscope... - Lundin

1 Answers

1
votes

According to this blog post, the interrupt latency for Cortex-M ranges from 12 to 16 cycles (assuming you are not using FPU registers) with best-case memories. M0 and M0+ are slower than M3/M4/M7. On top of this, you need to add the GPIO access times (and watch out for different clock frequencies between the core and the peripherals. Cortex-M7 will suppport higher clock speeds than M3/M4.

It still isn't clear how many cycles are consumed in recognising a pattern, and how an interrupt is useful in doing this - generally a low latency interface function like this would be an obvious target for dedicated hardware, but since you have an existing software solution it seems the problem is mis-specified.

Providing you avoid accessing any 'slow' peripherals which might stall the bus, the interrupt latency should be deterministic - any specific device should have documentation which covers this.

NXP have an application note which describes some of the detail of how to measure what is going on.