Is there a microcontroller with zero interrupt jitter?

Question

I know that interrupt latency depends on what the CPU is doing when the interrupt takes place (arm interrupt latency guide). This effect is called interrupt jitter. For my application I need an MCU with fixed interrupt latency (zero interrupt jitter). The latency may be arbitrarily high but the jitter must be zero. Do you know any MCU for that?

If there is no any zero jitter MCU, is there a way to programmatically compensate latency differences, adding some processor cycles for cases when interrupt latency is lower than maximum?

I need such MCU to measure times between two events with precision up to 1 cycle. Maybe it would be better not to look for specialized MCU but to construct an external circuit for measuring time?

Answer 1

You are approaching this from the wrong direction. You shouldn't have a specification which says "I need such mcu to measure times between two events with precision up to 1 cycle". You should have a specification which says precision of +/- x (milli/micro/nano) seconds. Time units, not cycles. In my experience, many instruction sets have a fixed amount of cycles. Then you pick a system clock which suits your specification.

Also as mentioned in comments, if you have an input capture timer peripheral (which is very likely), then that one will trigger very accurately. Then it will fire up the interrupt, which executes some time later. If you have a cyclic input capture timer, then you reset it by setting it to "previous trigger point + delay", not "the value of my timer by the time I hit the ISR + delay".

Answer 2

I believe some of the simpler PIC series have constant interrupt latency. For example, the ancient PIC16F84 has latency listed as 3.25 Tcy (or 13 clock cycles).

Unless your interrupt request is synchronized with the MCU clock there will be additional +/-0.5 clock cycle.

In situations where you might ask this question, usually the answer is to use hardware such as a timer capture input or timer compare output.

In the dark ages of MCUs (think i8049) I once was able to correct for interrupt latency variations by a variable jump into a field of NOPs as part of a slope ADC, but that would be a bit crazy in 2021 where there is so much hardware available for no cost.

Answer 3

One way would be to not use interupts for measuring the time at all. Certain processors like the SAMD series from Microchip have an event system, where peripherals can trigger events which lead to other hardware to perform different actions.

Considering you want to measure the time taking for charging a Capacitor:

• Analog Comparator 1 (low Voltage) -> Timer start
• Analog Comparator 2 (high Voltage) -> Timer capture & CPU Interupt

The interupt routine can then be executed without timepressure as the time value is saved in the capture register. This way the only jitter would be from the Analog Comparator and the length of it's clock. With a maximum clock speed of 48Mhz you end up with a resolution of 20ns and a jitter of about +-10ns. This also has the advantage that the CPU can run slower than the timer to preserve power.

There will always be jitter when working with a timediscrete processor, it can only be reduced.

Answer 4

Input Capture

Many, many microcontrollers have an "input capture" feature.

A timer runs freely at a fixed frequency. When an external signal happens, the timer value is copied to a register, and an interrupt is raised.

Regardless of the interrupt latency, then, the interrupt handler can read the value in the register and determine the precise instant at which the event happened, down to the frequency of the timer.

Google "input capture timer" or "input capture interrupt" for many links.

Answer 5

For my application I need a mcu with fixed interrupt latency (zero interrupt jitter). The latency may be arbitrarily high but the jitter must be zero. Do you know any mcu for that?

Even if you got a CPU with completely deterministic interrupt latency other things will break your timing. That is to say, deterministic interrupt latency won't by itself guarantee that your interrupt code runs with fixed timing.

• If you are running interrupts its likely that you will have other pieces of code that will need to be interrupt-safe. For example writing or reading a data structure that requires more than one read/write instruction. Safely accessing such structures usually involves defining "critical sections" where you briefly disable interrupts to do something atomically and then re-enable them. If your interrupt occurs while a critical section is executing then you just created non-deterministic interrupt latency.
• If the CPU instructions within your interrupt routine don't have deterministic timing then you will have timing jitter regardless of if the interrupt latency is fixed. This can happen for example if you use a cache. If the instructions/data were/weren't in the cache when the interrupt began then the timing can change.
• If there is any peripherals that share access to the memory bus, then your instruction timing can change. For example if a DMA transfer is running when the interrupt occurs then there your interrupt code may run slower than if a DMA transfer wasn't happening when the interrupt occurred.

So to sum up, if you want completely deterministic timing you can't have any critical sections which disable interrupts. Data structures shared with the interrupt code must be lock free. All code and data used by the interrupt must always permanently be either locked in or out of the cache. And you can't use any DMA or other peripherals that can stall the processor's access to memory.

So if you need very stable timing the solution is to put that timing critical processing into some sort of dedicated hardware that's doing nothing else. This could be...

• A capture-compare peripheral (present in may MCUs)
• A small auxiliary microcontroller running code that just captures your signal.
• An FPGA
• A special chip or circuit.

You can also look at something like the ZYNQ SoC made by Xilinx. The ZYNQ combines either 1 or two ARM Cortex A9 processor cores and FPGA fabric in one chip. Its possible to configure a small part of the FPGA fabric into a specialized circuit that will capture your signal with accuracy down to 1 clock cycle.

If you want both high speed and cycle accurate timing then FPGAs are a good option.

Answer 6

I can't think of any cpu I've used that has a consistent X clocks per instruction. Something like an AVR has most instructions at 1 clock and conditional branches at 2 clocks. Maybe the Propeller or XMOS can do it?

Cortex M ARM can vary significantly, especially as yet get about 30MHz with internal flash as there needs to be wait states, caching or some form of flash accelerator. Get up to the M7 where it can do multiple issue and the execution time of a given instruction depends what other instructions are around it. Cortex A might be 1/2 clock to 1000+ clocks depending on cache hit/miss, page faults etc.

As mentioned in the comments, most micros have an input capture feature for this very reason - it can capture with the resolution of the timer clock. Even the Intel 8052 had it on timer2.

Answer 7

This should be possible with an ARM9 FIQ handler that is locked into instruction cache.

The FIQ is the last exception defined, so the handler can begin immediately without an extra jump, and it has the second-highest priority (after reset) and will interrupt multi-cycle instructions like ldmia and stmdb, that will be restarted afterwards.

Interrupt entry does not generate memory accesses as the CPU switches to a shadow register bank, and if you can get the instruction fetch timing predictable (by locking the handler, or at least the part at the beginning that needs to be jitter-free, into cache), then I can't think of more jitter sources.

Answer 8

Due to different instructions in CPU taking a different number of instruction cycles, whenever a interrupt is triggered it needs to wait until those instruction finish the required cycles (different latency) then push data into the stack and call the INT subroutine. As a result it is not possible to have fixed interrupt latency without hardware help even when using a simple CPU.

Answer 9

• there is no clock (clock source) without jitter, so you can not have an mcu without jitter
• input and output pins in any hardware have a jitter, so your interrupt will have input pin + clock jitter at least
• yes you can compensate deterministic jitter with adding latency.
• no, you can not compensate for random jitter
• jitter always has a deterministic and a non deterministic component.
• if properly designed, systems can reach relative jitter between components below 1ns (CERN does things like that for example), so jitter is something you need to deal with, but it is possible

Edit:

• if the mcu has an deterministic architecture (in Order, no caches,... most old Architectures are deterministic), interrupts are deterministic too (there is still jitter from analog circuits!, digital logic is made of analog transistors, so there is jitter to!). But here interrupts are as precise as e.g. a hardware timer, capture compare peripheral,.-..
• a capture compare peripheral normally is faster, so you can measure e.g. higher frequencies than by using interrupts
• in industrial automation without an RTOS its totally common to use the timer interrupt + state machines to write deterministic software. In fact that is the best RTOS you can have, because if the interrupt is deterministic, the timing performance is mathematically provable!

Answer 10

Interrupts and using code to do the measurement is definitely not the way to do this. You use a timer peripheral that does it for you and can be cycle accurate. Or you use a cpld or other chip to do this measurement if this is a hard requirement. But you are barking up the wrong tree if you want to try to do this with interrupts into the processor.