Thoughts on Low Latency Interrupt Handling | Hacker News Reader

Thoughts on Low Latency Interrupt Handling

blog.adafruit.com

45 pointsrbanffy14 comments

The actual article is at https://www.bigmessowires.com/2018/04/12/thoughts-on-low-lat... The current link is to some kind of aggregator at adafruit.com

That scope display is a classic test of interrupt latency. One of the tests for QNX is to do that, and measure how long it takes from an interrupt until a user-space process can turn on an output pin. The important number for an real-time OS is not the average, but the worst case.

Some boards fail this test badly because they're doing something below the OS level in system management board. You set outliers on the scope. Those boards are unsuitable for real-time work.

A good trick is to set the scopes persistence to infinity and leave the thing running over the weekend.

> system management

Friend that worked on processors said some of them will 'go away' for a ms.

> The choice is also influenced by my desire for a mainstream mcu, with broad availability, good documentation and community support, good development tools, and a positive long-term outlook. This leads me to eliminate some options like the Parallax Propeller and Cypress PSoC.

Can anyone elaborate what kills the Cypress PSoC in that scenario? Never used them, but the reconfigurable logic part looks interesting.

Yeah, I'm confused about that too. I always had a positive experience with the PSoC, unless the author considers it a niche chip that most mainstream embedded developers will never encounter.

For a second I thought the SAMD51 was an 8051-based part. Incidentally, some of the newish 8051 MCUs (SiLabs makes some good ones) have very low interrupt latencies too (<10 cycles) when running at 100MHz.

OP complains about flash wait states but doesn't know you can move your handler code to ram to avoid them?

‘If the flash wait states are a major problem, it may be possible to copy the interrupt handler code to RAM and run it from there. I’m assuming the internal RAM has zero wait states, but I might be wrong on that point.‘

Simpler MCUs have real hardwired SRAM access registers.

On more complex systems, even SRAM access goes through some stateful scheduling circuitry. So, interrupt latency on mainstream MCUs can't be reduced much.

If you want XIP with adequate latency, there is no alternative to spending money on Everspin MRAM. You will have accommodate the latency of SPI access, but that was never an issue in my practice.

What about TCM (Tightly-Coupled Memory) on ARM?

If you have it, then use it. Its purpose is exactly to hold latency sensitive code, like interrupt handlers. The challenge is of course is to fit your code into it as it is usually small.

There's also parallel versions of MRAM that you can hookup just like SRAM.

Indeed, just the amount of mainstream MCUs with external memory bus connection is smaller with each year.

Bwah hah, that reminds of me the ADSP-21xx series... They had a second register file for the interrupts. No pushing or popping. Interrupts happens, bam, all of your accesses are exactly where you left them! And when you're done, return to main thread and all registers are exactly where you left them on the next clock cycle!!!

Reply on news.ycombinator.com