Best MCU for the lowest input capture interrupt latency

[rstofer]

For the GNU chain (and others) you can use the 'naked' attribute in the function definition to eliminate the generation of prolog and epilog code:

naked
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that the specified function does not need prologue/epilogue sequences generated by the compiler. It is up to the programmer to provide these sequences. The only statements that can be safely included in naked functions are asm statements that do not have operands. All other statements, including declarations of local variables, if statements, and so forth, should be avoided. Naked functions should be used to implement the body of an assembly function, while allowing the compiler to construct the requisite function declaration for the assembler

https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html

I have no idea whether this applies to dsPICs or any other chip.  It does work for ARM.

[Sal Ammoniac]

How about a PIC32MZ? Runs at 252 MHz and has register banks to reduce interrupt latency down to a minimum.

besides the fact that unless you write the ISR in asm interrupt latency in MIPS is horrific compared to dsPIC...

Well, yes, that's generally the case with a more complex CPU (PIC32) versus a simpler one (dsPIC). The latency is more visible to the programmer for something like a PIC32 versus something like an ARM Cortex-M because the CPU does essentially nothing before jumping to the ISR, whereas with the ARM it saves registers automatically before jumping to the ISR.

Overall, I'd agree--if the absolute lowest interrupt latency was important, I wouldn't use a PIC32 or even an ARM.

[Sal Ammoniac]

For the GNU chain (and others) you can use the 'naked' attribute in the function definition to eliminate the generation of prolog and epilog code:

naked
Use this attribute on the ARM, AVR, MCORE, RX and SPU ports to indicate that the specified function does not need prologue/epilogue sequences generated by the compiler. It is up to the programmer to provide these sequences. The only statements that can be safely included in naked functions are asm statements that do not have operands. All other statements, including declarations of local variables, if statements, and so forth, should be avoided. Naked functions should be used to implement the body of an assembly function, while allowing the compiler to construct the requisite function declaration for the assembler

https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html

I have no idea whether this applies to dsPICs or any other chip.  It does work for ARM.

It works for MIPS (PIC32) too.

[SiliconWizard]

No need to bother with interrupts. As some of us have already said, the safest bet here is to use a MCU with peripheral hardware triggers.

The OP mentioned the dsPIC33E, and they do not need to look any further if that's what they are currently using. The "output compare" peripheral can be triggered from a wide variety of hardware trigger sources. See the SYNCSEL field of the control register OCxCON2.

[jemangedeslolos]

So much passion for interrupt latency 
I love this forum 

I will try to answer to all.

So, to be honest, I cheated. I used CCS compiler and all is done by the built in functions :
The exact MCU is a dsPIC33EP512MC806

Code: [Select]

#INT_IC1
void  ic1_isr(void)
{
   output_high(OUT1);
   delay_us(20);
   output_low(OUT1);
   clear_interrupt(INT_IC1);
}

void main()
{
   setup_capture(1, CAPTURE_RE | INTERRUPT_EVERY_CAPTURE | CAPTURE_SYSTEM_CLOCK | CAPTURE_SYNCHRONIZE | CAPTURE_TRIG_SYNC_NONE);
   enable_interrupts(INT_IC1);
   enable_interrupts(INTR_GLOBAL);
   
   set_pulldown(TRUE, PIN_E2);

   while(TRUE)
   {

   }
}
This code gives me less than 600ns latency.
Just by adding the keyword "fast" after the interrupt handler "INT_IC1" to use shadow register gives me around 320ns.

Without interrupt handler, just by checking the interrupt flag inside the loop, I measure around 200ns but with a lot more jitter.
The result are more consistant inside the Interrupt handler.

I will check the ASM generated by CCS but Im not familiar with ASM.
All of your posts have made me want to dig deeper than I initially wanted 

I will check the new dsPIC33CK.
STM32H7 would have been interesting to try but there is no stock.
And I will also try MPLAB and XC16, maybe the result are better.

If you have any ideas about my code, I'm all ears. I'm not a software guy.

Thank you very much to all of you 

[JPortici]

I don't know about CCS so it's possible it's performing a full context save before in the ISR (which would be the case for XC16 as well as you are calling functions?)
i don't know what "fast" does but it's possible it uses shadow registers to speed up context save/restore.

If what you need to do is a fixed length pulse on an capture then you can use an output compare module and trigger it from either the input capture event of the PTG

let's say IC1 capture triggers OC1 pulse
OC1CON1, OC1 Mode is "Single Compare Single-Shot mode"
OC1R is set so that the pulse time is 20us (20us = OC1R / OC1CLK)
OC1CON2, OCTRIG = 1
OC1CON2, SYNCSEL set so that "IC1 input capture event synchronizes or triggers OC1"

that should do it, no cpu intervention

on the top of my head, i don't remember if in single shot mode OC1TMR is reset every time or if you have to manually reset it, but it should be clear from the diagrams in the "Output Compare with Dedicated Timer" reference manual chapter (DS70005159A)

try and experiment

[nctnico]

What would be helpfull here is a dissassembler output with source code mixed in. Likely there is a whole bunch of overhead between the interrupt firing and the function being called. The code as-is doesn't really 'link' the interrupt routine to the interrupt. I assume there is much more to it.

[DavidAlfa]

Definitely, check the dissassembly, and the compiler optimizations!
Try using asm to set the pin high, ex "asm("BSET LATA,1");" for RA1 pin, the rest of the interrupt is not so critical.

[emece67]

.

[mino-fm]

Using input-capture of TIM15 of STM32H723 @ 550 MHz takes 80 ns.
(Sorry for bad GND connection.)

void TIM15_IRQHandler(void)
{
       TIM15_IRQHandler: (+1)
0x0   0xB57C             PUSH     {R2-R6,LR};                  push some registers
//      volatile uint32_t temp;
//      GPIOB->BSRR = (SET_GPIO << KONTROLL_AUSGANG);
0x2   0x....'....           LDR.W    R4,??DataTable36_8;;    0x58020400
0x6   0x2008             MOVS     R0,#+8
0x8   0x61A0             STR      R0,[R4, #+24];           set PortB.3
//    if(TIM15->SR & TIM_SR_CC2IF) {

Input = falling edge (yellow)
Output = rising edge (blue)

[SpacedCowboy]

For the specific problem (generate a pulse from a pulse), I'd be tempted to use an RP2040. This is the second post I've made this morning espousing their benefits. I don't work for them, honest

They have PIO blocks, which are programmable state machines running at the clock frequency (and the RP2040 can be pushed way beyond 133MHz), and run independent of the ARM CPU. People have implemented SPI, I2C, UART, and even dual-display DVI output (see the other post in the link). You can do quite a bit with the state-machine language, there's DMA to/from main RAM, and you can notify the ARM when there's stuff for it to do. The general-purpose GPIOs in the dual-display DVI project are toggling at 252MHz successfully...

The PIO blocks are very similar to (if more limited than) the PRUs of the beagle-board, and the idea of creating software-peripherals is very similar to the XMOS concept (though again, more limited than where XMOS took it). I always found it was hard to actually get the PRUs to work on the beagle-board though. I always wanted to use the ports for other things. The lack of "other things" is actually working out as a benefit here, and the parts are very cheap

[SiliconWizard]

So much passion for interrupt latency 

I did not see any passion, just a few answers that were to the point IMO.
And you are not listening. Why are you not considering using a trigger for the output compare peripheral as I suggested? Is there any valid reason?
Note that if the reason for having an ISR is that you're doing more upon said event than just generate a pulse, you can still do both. Set up a hardware trigger for the OC, and set up an ISR for the same source (that'll probably be INTx), and do in it whatever else needs to be done - but with a higher latency.

[jemangedeslolos]

So much passion for interrupt latency 

I did not see any passion, just a few answers that were to the point IMO.
And you are not listening. Why are you not considering using a trigger for the output compare peripheral as I suggested? Is there any valid reason?
Note that if the reason for having an ISR is that you're doing more upon said event than just generate a pulse, you can still do both. Set up a hardware trigger for the OC, and set up an ISR for the same source (that'll probably be INTx), and do in it whatever else needs to be done - but with a higher latency.

SiliconWizard,

This was by no means a criticism.
I was rather pleasantly surprised to have so many answers in such a short time.

Im listening but I wanted to try all the different suggestions.
I tried to replace some C lines with assembler with my two kids in the background which is a bad idea to make things work.

Now I am trying to configure the output capture module but It is not working in trigger mode. I have something on the OC1 ouput in synchronize mode and double compare continuous pulse mode which is promising.
I have a 20us pulse on OC1 every rising edge in IC1 ( 2Khz 50us pulse ).

Code: [Select]

   IC1CON1.ICTSEL = 0b111;
   IC1CON1.ICI    = 0b00;
   IC1CON1.ICM    = 0b011;
   IC1CON2.ICTRIG = 1;

   OC1CON2.SYNCSEL  = 0b10000;
   OC1CON2.OCTRIG   = 0;
   
   OC1CON1.OCTSEL   = 0b111;    // Peripheral clocl as clock source
   OC1CON1.TRIGMODE = 1;        // trigstat cleared in software AND when IC1RS = OC1TMR
   OC1CON1.OCM      = 0b101;
   
   OC1R             = 0;
   OC1RS            = 1410;
But in trigger mode and single compare single shot mode, I have nothing on OC1 output 

Code: [Select]

OC1CON2.OCTRIG    = 1;
OC1CON1.OCM       = 0b001;
Do you have any idea ?

[NorthGuy]

I tried to replace some C lines with assembler with my two kids in the background which is a bad idea to make things work.

It would only make sense if you needed fast ISR.

What pin are you checking for the OC output? Usually, you would have to assign the pin to OC using PPS.

I would suggest starting from something very simple, such as a program which generates some output on OC. Then re-write it to produce a single pulse. Then link the pulse to INT1 or INT2. It's much easier to do things by little steps rather than all at once.

I don't think you need IC.

[PCB.Wiz]

This code gives me less than 600ns latency.
Just by adding the keyword "fast" after the interrupt handler "INT_IC1" to use shadow register gives me around 320ns.

Without interrupt handler, just by checking the interrupt flag inside the loop, I measure around 200ns but with a lot more jitter.
The result are more consistent inside the Interrupt handler.

I will check the ASM generated by CCS but Im not familiar with ASM.

You do not need to be an ASM expert at all, just scanning the listing shows 'what the compiler is up to', and your "fast" keyword almost halved the delays. That sort of change will be very visible  in the ASM (see comments above about register bank switch vs multiple push/pop )

Keep in mind interrupts can jitter too, depending on what opcodes are running at the time (they need to complete first)

If you have other interrupts running,  you need to make your vital one highest priority, otherwise it is forced to wait until the first INT completes, and you will get rare-but-large jitter.

If the MCU is not doing anything else, placing it into idle can often lower the jitter in the INT response delay to smallest.

If absolute delay from trigger to output edge matters, you could use config logic cells, if your MCU has them, or external logic to merge the trigger and an external pin.
If the trigger is always wider than the INT response time,  a simple MUX can select trigger initially, (controls leading edge) then flip to a PWM or SW pin pulse, (controls trailing edge) and your MCU will behave very like a HW monostable with sub 10ns trigger to output times.

[tggzzz]

This code gives me less than 600ns latency.
Just by adding the keyword "fast" after the interrupt handler "INT_IC1" to use shadow register gives me around 320ns.

Without interrupt handler, just by checking the interrupt flag inside the loop, I measure around 200ns but with a lot more jitter.
The result are more consistent inside the Interrupt handler.

I will check the ASM generated by CCS but Im not familiar with ASM.

You do not need to be an ASM expert at all, just scanning the listing shows 'what the compiler is up to', and your "fast" keyword almost halved the delays. That sort of change will be very visible  in the ASM (see comments above about register bank switch vs multiple push/pop )

Keep in mind interrupts can jitter too, depending on what opcodes are running at the time (they need to complete first)

If you have other interrupts running,  you need to make your vital one highest priority, otherwise it is forced to wait until the first INT completes, and you will get rare-but-large jitter.

If the MCU is not doing anything else, placing it into idle can often lower the jitter in the INT response delay to smallest.

Agreed.

Depending on the complexity of the MCU - and they can be very complex nowadays - jitter can also be introduced by instruction/data caches and hierarchy, TLB caches. Those can introduce very large jitter.

The xCORE devices don't have caches, and a core does idle until the relevant input arrives.

Engineering is about understanding limitations of tools. If one tool (e.g. an MCU) can't guarantee timing sufficiently, then you have to use another (e.g. FPGA, external hardware, specialised peripheral)

[jemangedeslolos]

Hello,

All hardware connections are fine.
I assigned RE2 for IC1 and RE4 for OC1.
I already used dsPIC in the past and I know how to use peripheral pin select.

I just wanted to know how much I could lower the latency inside the ISR with assembly line instead of C line to toggle pin.
I get around 300ns instead of 320ns ( The measurements are not very accurate because I use a 100 MSa/s oscilloscope ).

Now I would like to try the idea from SiliconWizard and JPortici but I didn't manage to get it works in trigger mode.
I don't use assembler anymore, it was just for curiosity.

I have something very promising in synchronize mode and  double compare continuous pulse mode.





As you can see, there is a continuous 20us pulse at around 1Khz on OC1 ( yellow ) AND there is a pulse synchronized with IC1 ( blue ).
But in trigger and single compare single shot mode, I have nothing on OC1.
just a high level or a low level depending on OC1CON1.OCM  ( 0b001 or 0b010 ).

There is surely a counter or a flag to reset but I don't know which one and when to do it.

[Siwastaja]

Depending on the complexity of the MCU - and they can be very complex nowadays - jitter can also be introduced by instruction/data caches and hierarchy, TLB caches. Those can introduce very large jitter.

Again, again and again;

Nobody in their right mind would put the timing critical ISR in the cached instruction area - the problem isn't cache, the problem is slow memory -; they would use ITCM, (or just fast on-chip RAM) instead. Those fancy MCUs that are fancy enough to have caches, also tend to come with ITCM for obvious reasons. Instruction cache is actually used to speed up average runtime of non-timing critical application code in external (slow) memory (which is there because of the sheer amount of that code; large user interfaces etc). This does not affect ISR jitter in any way because you don't put those functions there.

Your continued crusade and ignorance of counterarguments suggest you might have some financial motivation behind your posts, which are written like typical guerilla marketing. I have been hesitant of making that conclusion, but the repeatability of this pattern suggests that way. Do others see this or is it just me? Maybe the forum moderation should look into this?

[MarkF]

How about a PIC32MZ? Runs at 252 MHz and has register banks to reduce interrupt latency down to a minimum.

Also the PIC32MX series with DMA.
You could setup one of the DMA channels to be triggered by the interrupt and then output any sequence you want using hardware without ANY cpu interaction or ISR routine.  The delay would be based on the master clock.

[tggzzz]

Depending on the complexity of the MCU - and they can be very complex nowadays - jitter can also be introduced by instruction/data caches and hierarchy, TLB caches. Those can introduce very large jitter.

Again, again and again;

Nobody in their right mind would put the timing critical ISR in the cached instruction area - the problem isn't cache, the problem is slow memory -; they would use ITCM, (or just fast on-chip RAM) instead. Those fancy MCUs that are fancy enough to have caches, also tend to come with ITCM for obvious reasons. Instruction cache is actually used to speed up average runtime of non-timing critical application code in external (slow) memory (which is there because of the sheer amount of that code; large user interfaces etc). This does not affect ISR jitter in any way because you don't put those functions there.

Your continued crusade and ignorance of counterarguments suggest you might have some financial motivation behind your posts, which are written like typical guerilla marketing. I have been hesitant of making that conclusion, but the repeatability of this pattern suggests that way. Do others see this or is it just me? Maybe the forum moderation should look into this?

The keywords in your statements is "...tend to come...".

OK, here's the first example I came across of measured ARM MCU latencies for the differing memory and cache conditions:
https://www.jblopen.com/arm-cortex-a-interrupt-latency/
He then improves that, but there is still noticeable jitter:
https://www.jblopen.com/improving-interrupt-latency-on-the-cortex-a9/
Whether that is a problem depends on the application's constraints. Clearly in the Zynq chips it would be possible - and maybe necessary or preferable - to use the PL rather than PS where latency and jitter must be defined.

Apart from that, ad hominem attacks are undesirable. The most you can accurately accuse me of is being a fanboy, and of wanting to kick people out of the mindset that conventional processors are the only (and therefore best) way of achieving hard realtime performance. Measuring hard realtime latencies is a methodological sin, of course.

[Siwastaja]

Cortex-A is not a microcontroller core. It's an application CPU, and very commonly code is ran out of DRAM (with large random-access latency). Does not relate to microcontrollers; so completely apples-to-oranges comparison. One of the defining factors of what microcontroller is, is the ability of timing critical control with low latency and low jitter, compared to application CPUs. Hence simplicity and lack of caches, or in more complex MCUs like Cortex-M7, addition of core-coupled memories.

Now I understand completely where your strawman is coming from. You mix application CPUs and microcontrollers up.

I'm not "attacking" ad hominem. I'm truly suspecting based on your behavior, and I think with good reasons. I might be wrong, though, in which case I'm sorry. On the other hand, I hope I'm right, because your continued mispresentation of facts, which seems to be on purpose, is detrimental to the discussion. I hope it at least does good on your wallet, then there would be at least one winner in this stupid reoccurring game - yourself.

Interestingly, you reply to threads that talk about "MCU"s, write "MCU" yourself, but somehow, suddenly, it has been changed to "conventional processors".

Nobody outside of your strawman is using Pentium or Cortex-A9 for nearly cycle-accurate hard realtime applications, or ever suggested doing that. We use microcontrollers, such as Cortex-M7. Caches do not affect the ISR jitter, because ISRs where this matters are not in cacheable (slow) memory. This is a fact.

I want to call BS out in a well-mannered way, but continued ignorance of the arguments for years leads to certain conclusions being made. You are supplying the same completely wrong information repeatedly, and it seems this behavior can't be corrected by rational argumentation (i.e., supplying the correct information), which has been attempted by me and many others, time after time. You continue to present the same old strawman, made up by calling not-a-microcontroller a microcontroller, and pretending this strawman has any relevance to real life.

[NorthGuy]

I just wanted to know how much I could lower the latency inside the ISR with assembly line instead of C line to toggle pin.
I get around 300ns instead of 320ns ( The measurements are not very accurate because I use a 100 MSa/s oscilloscope ).

Post the disassembly of your INT ISR code.

I have something very promising in synchronize mode and  double compare continuous pulse mode.

Very well. Now switch to the trigger mode (OCTRIG = 1) and create an interrupt which clears the TRIGSTAT bit after the pulse is produced.

[tggzzz]

Cortex-A is not a microcontroller core. It's an application CPU, and very commonly code is ran out of DRAM (with large random-access latency). Does not relate to microcontrollers; so completely apples-to-oranges comparison. One of the defining factors of what microcontroller is, is the ability of timing critical control with low latency and low jitter, compared to application CPUs. Hence simplicity and lack of caches, or in more complex MCUs like Cortex-M7, addition of core-coupled memories.

Now I understand completely where your strawman is coming from. You mix application CPUs and microcontrollers up.

I'm not "attacking" ad hominem. I'm truly suspecting based on your behavior, and I think with good reasons. I might be wrong, though, in which case I'm sorry. On the other hand, I hope I'm right, because your continued mispresentation of facts, which seems to be on purpose, is detrimental to the discussion. I hope it at least does good on your wallet, then there would be at least one winner in this stupid reoccurring game - yourself.

Interestingly, you reply to threads that talk about "MCU"s, write "MCU" yourself, but somehow, suddenly, it has been changed to "conventional processors".

Nobody outside of your strawman is using Pentium or Cortex-A9 for nearly cycle-accurate hard realtime applications, or ever suggested doing that. We use microcontrollers, such as Cortex-M7. Caches do not affect the ISR jitter, because ISRs where this matters are not in cacheable (slow) memory. This is a fact.

I want to call BS out in a well-mannered way, but continued ignorance of the arguments for years leads to certain conclusions being made. You are supplying the same completely wrong information repeatedly, and it seems this behavior can't be corrected by rational argumentation (i.e., supplying the correct information), which has been attempted by me and many others, time after time. You continue to present the same old strawman, made up by calling not-a-microcontroller a microcontroller, and pretending this strawman has any relevance to real life.

The problem is that devices - whatever you call them - are becoming ever more capable and complex, at rapidly decreasing cost. The consequence is that nothing is black and white (it is shades of gray), the boundaries are becoming increasingly blurred, and there is no simple distinction that can be made.

From that point of view, the key distinction is the definition of various terms - and neither of us has made our definition explicit.

To me an MCU is a single chip computer, embedded within a system and not acting as a fully-fledged general purpose computer. The Zynq devices are used like that, e.g. in the Red Pitaya oscilloscope (and other embedded systems and, I believe, other scopes). Hence to me they constitute an MCU, albeit a very powerful one. They are also capable of much more.

Similarly Z80s and their more integrated modern variants are also MCUs - but they are/were also general-purpose computers running general purpose operating systems. In my case I used Z80a+CP/M for cross-compiling C for an embedded Z80.

Now if you use MCU to mean something without caches or where caches can be disabled, that's one other valid definition of the term. But only one other.

[SpacedCowboy]

The problem is that devices - whatever you call them - are becoming ever more capable and complex, at rapidly decreasing cost. The consequence is that nothing is black and white (it is shades of gray), the boundaries are becoming increasingly blurred, and there is no simple distinction that can be made.

I think this is a fair point. I think there is a 'crossover' market right now, but I don't think it really changes the definitions.

To me an MCU is a single chip computer, embedded within a system and not acting as a fully-fledged general purpose computer. The Zynq devices are used like that, e.g. in the Red Pitaya oscilloscope (and other embedded systems and, I believe, other scopes). Hence to me they constitute an MCU, albeit a very powerful one. They are also capable of much more.

What you're describing sounds more like a SOC to me. A Zynq can be used as a 'microcontroller' to talk to the PL, but it's a stretch. There's too much associated with a Zynq that is more APU-like (DDR ram with its vagaries, for example) although you certainly can try and use it as an MCU, I don't think that's it's real purpose - it's aimed somewhat higher IMHO. SOCs can range from something like the Zynq, or embedded IP on and FPGA, all the way up to the Apple M1, although that doesn't really fit into your 'not acting as a fully-fledged general purpose computer' clause.

If you look at how ST do it, they have their MP1 which has an MCU in it (Cortex M4) but it also has APU's (Cortex A7's) - I'd say the M4 was the MCU, and the A7's were not. The reason they include the M4 is basically the laundry list already discussed, where a predictable and deterministic device is required. The reason they include the A7's is for general-purpose computing and speed, but with determinism trade-offs. Anything 'A'-designated (including the Zynq) isn't really an MCU, at least IMHO.
 
I'd say the RP2040 was an MCU, I'd say the R-Pi was not. I'd say the PIC range, anything ARM-M-designated were MCU's, as are the XMOS chips. I'd say the SiFive SOCs (eg: U540) were not.

IMHO it's pretty simple: determinism is the defining factor of an MCU. If I know I can guarantee it'll take X clocks to service my interrupt under <condition> and I can set up my code to be in <condition>, then it's a microcontroller. If there's even a chance that this can't be done, it's not.

Shrug. I guess YMMV, but that's my $0.02.

[SiliconWizard]

Now I am trying to configure the output capture module but It is not working in trigger mode. I have something on the OC1 ouput in synchronize mode and double compare continuous pulse mode which is promising.
I have a 20us pulse on OC1 every rising edge in IC1 ( 2Khz 50us pulse ).

Code: [Select]

   IC1CON1.ICTSEL = 0b111;
   IC1CON1.ICI    = 0b00;
   IC1CON1.ICM    = 0b011;
   IC1CON2.ICTRIG = 1;

   OC1CON2.SYNCSEL  = 0b10000;
   OC1CON2.OCTRIG   = 0;
   
   OC1CON1.OCTSEL   = 0b111;    // Peripheral clocl as clock source
   OC1CON1.TRIGMODE = 1;        // trigstat cleared in software AND when IC1RS = OC1TMR
   OC1CON1.OCM      = 0b101;
   
   OC1R             = 0;
   OC1RS            = 1410;
But in trigger mode and single compare single shot mode, I have nothing on OC1 output 

Code: [Select]

OC1CON2.OCTRIG    = 1;
OC1CON1.OCM       = 0b001;
Do you have any idea ?

I haven't use dSPICs for a few years, so I'll have to dig a little deeper.
One first remark: you are apparently trying to trigger OC1 from IC1? Are you sure IC1 is properly configured to begin with?