Author Topic: Best MCU for the lowest input capture interrupt latency  (Read 17648 times)

0 Members and 1 Guest are viewing this topic.

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Best MCU for the lowest input capture interrupt latency
« Reply #100 on: April 08, 2022, 02:43:55 pm »
Repeat after me until understood: caches do not apply to microcontrollers. Caches do not apply to microcontrollers. Even if they have caches available.

Your third sentence invalidates your first and second sentences! Cache coherence problems? :)

Quote
Usage of caches is not mandatory. Microcontrollers come with fast memory. Microcontrollers allow running ISRs out of fast memory. Cortex-A CPUs are not microcontrollers. Look at what the name of this subforum is. Look what the

That's merely your definition of MCU, and is not universally acknowledged.

An alternative (and arguably more useful) definition of an MCU is a chip where it can use internal memory and peripherals, and does not require external memory nor peripherals. Some Cortex-A devices fit that description.
« Last Edit: April 08, 2022, 02:53:59 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Best MCU for the lowest input capture interrupt latency
« Reply #101 on: April 08, 2022, 03:34:42 pm »
Repeat after me until understood: caches do not apply to microcontrollers. Caches do not apply to microcontrollers. Even if they have caches available.

Your third sentence invalidates your first and second sentences! Cache coherence problems? :)

No. There is no inconsistency, within the context which was discussed - interrupt latency. I have explained it too many times to do it again, and I also understand getting me to waste more time in re-explaining it is just part of your game. I can totally see what you are doing, and also how you do it. You have totally lost your game in my eyes. And I will totally continue debunking your marketing BS every time I see it; no matter how you try to shift goalposts, create strawmen, and confuse others.

I will also do my best to convince people avoid XMOS products wherever I have the power to affect the choice.
« Last Edit: April 08, 2022, 03:37:38 pm by Siwastaja »
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Best MCU for the lowest input capture interrupt latency
« Reply #102 on: April 08, 2022, 03:38:28 pm »
NorthGuy completely missed my point, challenging the claim about 12-cycle Cortex-M7 interrupt latency.

I didn't challenge any claims. The OP tries to get the best latency between the signal and response from an ISR. You suggested that an abstract Cortex-M7 400 MHz MCU will give you the best latency with very low jitter. I was interested in seeing real world measurements. Not to argue any point, but to see real data. You don't have any, don't want to, not gonna. Case closed.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Best MCU for the lowest input capture interrupt latency
« Reply #103 on: April 08, 2022, 03:53:47 pm »
NorthGuy completely missed my point, challenging the claim about 12-cycle Cortex-M7 interrupt latency.

I didn't challenge any claims. The OP tries to get the best latency between the signal and response from an ISR. You suggested that an abstract Cortex-M7 400 MHz MCU will give you the best latency with very low jitter. I was interested in seeing real world measurements. Not to argue any point, but to see real data. You don't have any, don't want to, not gonna. Case closed.

I did not reply to the OP. On discussion forums, discussions are not always linear and without branches. It's quite revealing you missed the point again even after that was pointed out. Partial problem was compared to another partial problem, to demonstrate how stupid it is to look at partial problems. We are probably in total agreement but you are unable to see it.

You are free to perform any real-world measurement you think you want to see. I don't understand why you need me to do it.
« Last Edit: April 08, 2022, 04:01:18 pm by Siwastaja »
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Best MCU for the lowest input capture interrupt latency
« Reply #104 on: April 08, 2022, 04:38:52 pm »
If I understood the Apollo thing correctly, a simplified equivalent problem would be wiring a signal directly into an interrupt pin of a CPU, and not thinking about maximum interrupt rate that can occur, during normal or less-than-normal conditions.

It's good the complete system was able to cope, but it came with the expense of other processes; this is a last-resort attempt to save the day, due to failure at lower level, at which the problem would have been much easier to deal with.

Really the right thing to do is to condition/process the signal on hardware level: for example, use a timer peripheral to count the cycles; something which can deal with whatever pulse rate. Failing to have hardware for that and having to resort to CPU interrupt, then the only sane thing you can do is to turn off the interrupt source for some time, and re-enable it with a timer, setting a maximum limit for interrupts. But then you need something else to detect the "unexpected pulses between allowed interrupt time window" error case.

The Apollo 11 situation was similar to wiring a signal directly to an interrupt pin on an MCU. The rendezvous radar inputs to the AGC were in the form of positions of the shaft axis and trunnion axis. These had analog resolvers that were input to a CDU, which converted the analog position information into a series of digital pulses--the further the radar moves on one of its axes, the larger the number of pulses to the AGC. The AGC handled the pulses by directly incrementing or decrementing (depending on which direction the radar antenna moved) counters without the need to execute any code. Each counter pulse stole one CPU cycle, which was ~12 microseconds. Most of the other data inputs to the AGC also used this pulse counting technique, including the gyros, accelerometers, and the landing radar. The raw data was conditioned by the CDUs and not fed directly to the AGC itself.

The LM used 800 Hz AC power, and, for some reason, the power supply to the rendezvous radar was not phase-locked to the power supply of the AGC, and that caused the radar CDU to to think the radar antenna was oscillating rapidly around its current position, so it generated a series of pulses reflecting that to the AGC. Yes, the CDUs should perhaps have been designed to recognize that condition and filter the data so the AGC wouldn't see the pulse storms that it did, but this was early 1960s technology and it either wasn't feasible or the designers didn't foresee it.

The MIT IL people never saw the issue in testing because they used a single 800 Hz power supply instead of separate ones. Curiously, since 800 Hz AC supplies weren't too common, at one point the MIT people used McIntosh audio amplifiers fed with an 800 Hz audio tone as power supplies for their test setups.

The decision to leave the rendezvous radar on during the descent was a late change to the flight plan suggested by Aldrin, who thought that leaving it on would save time in the event that they had to abort the landing and return to the CSM. It's ironic that this precaution itself almost caused an abort.
Complexity is the number-one enemy of high-quality code.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Best MCU for the lowest input capture interrupt latency
« Reply #105 on: April 08, 2022, 04:58:20 pm »
The LM used 800 Hz AC power, and, for some reason, the power supply to the rendezvous radar was not phase-locked to the power supply of the AGC, and that caused the radar CDU to to think the radar antenna was oscillating rapidly around its current position, so it generated a series of pulses reflecting that to the AGC. Yes, the CDUs should perhaps have been designed to recognize that condition and filter the data so the AGC wouldn't see the pulse storms that it did, but this was early 1960s technology and it either wasn't feasible or the designers didn't foresee it.

I think the really correct way would have been exactly what a modern $0.40 microcontroller does in its quadrature encoder timer module: count the cycles on a simple hardware counter (reg + adder), then have the CPU data bus connected so that this counter can be accessed whenever CPU needs the latest value.

This pattern is completely obvious today, ranging from lowest cost toys to high-reliability stuff. But the Apollo story is interesting because it shows it takes time and iterations to find simple, reliable and effective design patterns, and mistakes are made in the process.

It's best to completely avoid an error scenario, instead of detecting it and working around. In this example, it could have been done in numerous ways.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Best MCU for the lowest input capture interrupt latency
« Reply #106 on: April 08, 2022, 05:25:12 pm »
NorthGuy completely missed my point, challenging the claim about 12-cycle Cortex-M7 interrupt latency.

I didn't challenge any claims. The OP tries to get the best latency between the signal and response from an ISR. You suggested that an abstract Cortex-M7 400 MHz MCU will give you the best latency with very low jitter. I was interested in seeing real world measurements. Not to argue any point, but to see real data. You don't have any, don't want to, not gonna. Case closed.

Not to add to something that's beginning to be fruitless, but 12-cycle latency or whatever is never going to be achieved if, say, the ISR is in Flash and currently not in instruction cache.
There are ways to circumvent that, including putting your ISRs (at least the critical ones) in RAM (and, core-coupled RAM if possible). That's usually doable but many do not even bother doing it or even know how to.

Also, obviously you won't get that latency if another interrupt fires, with a higher priority. There are many real-world cases for which setting up appropriate priorities for "tasks" that are of equivalent importance is nothing trivial, or even tractable.

Again the point is that's exactly why more and more MCUs have hardware trigger capabilities. Use them whenever possible instead of trying to outsmart the whole thing with ISRs.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Best MCU for the lowest input capture interrupt latency
« Reply #107 on: April 08, 2022, 05:37:45 pm »
You are free to perform any real-world measurement you think you want to see. I don't understand why you need me to do it.

I thought you use them regularly and probably have couple of them sitting on your table. That's why.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Best MCU for the lowest input capture interrupt latency
« Reply #108 on: April 08, 2022, 05:48:46 pm »
Not to add to something that's beginning to be fruitless, but 12-cycle latency or whatever is never going to be achieved if, say, the ISR is in Flash and currently not in instruction cache.
There are ways to circumvent that, including putting your ISRs (at least the critical ones) in RAM (and, core-coupled RAM if possible). That's usually doable but many do not even bother doing it or even know how to.

I am sure Siwastaja would know how to place the ISR to achieve the best latency and minimize jitter.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Best MCU for the lowest input capture interrupt latency
« Reply #109 on: April 08, 2022, 06:23:35 pm »
I dunno, he stated that caches did not apply to microcontrollers. ::)
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Best MCU for the lowest input capture interrupt latency
« Reply #110 on: April 08, 2022, 06:45:33 pm »
I dunno, he stated that caches did not apply to microcontrollers. ::)

Caches do not affect timing of critical ISR handlers on microcontrolers because no one in their right mind would place critical ISRs on slow, cached memory (such as SD card or external DRAM). This is what I meant because of the context.

But I'm sure you know this. What I don't understand is why you participate on this trolling, and continue feeding the same old strawman argument.

Functions can be placed in ITCM by modifying the linker script and using section attributes. If you don't know how, you can Google. It's not rocket science. Interrupt priorities is also a very simple concept, almost trivial. One function call to set the priority as you wish: higher priority interrupt pre-empts lower priority one; trivial worst-case timing. You can also demote to lower priority by invoking software interrupt through NVIC->STIR; this is something I regularly do.

I don't understand how this is difficult to anyone except beginners. And beginners can learn.

But I can see what disgusting social game is going on. Surprisingly, I have got private messages with very opposite tone, confirming my suspicions. I would like to ask these frequent posters to come out publicly, but OTOH I can totally see why it is not happening.

But yeah, this thread gives a good idea about the level of mental honesty of certain people. Enjoy, and good luck with that attitude.
« Last Edit: April 08, 2022, 06:58:10 pm by Siwastaja »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Best MCU for the lowest input capture interrupt latency
« Reply #111 on: April 08, 2022, 07:11:20 pm »
I dunno, he stated that caches did not apply to microcontrollers. ::)

Caches do not affect timing of critical ISR handlers on microcontrolers because no one in their right mind would place critical ISRs on slow, cached memory (such as SD card or external DRAM). This is what I meant because of the context.
Yes, although some microcontrollers have flash accellerators that serve like a very small (few words at most) cache that could incur a variable delay.

Quote
Functions can be placed in ITCM by modifying the linker script and using section attributes. If you don't know how, you can Google. It's not rocket science. Interrupt priorities is also a very simple concept, almost trivial. One function call to set the priority as you wish: higher priority interrupt pre-empts lower priority one; trivial worst-case timing. You can also demote to lower priority by invoking software interrupt through NVIC->STIR; this is something I regularly do.
You can ofcourse theorise that having interrupts at different priorities will affect latency but in the end that is part of the design constraints. Servicing two interrupts at the highest priority with the lowest possible latency is impossible so something has got to give.

IMHO the bottom line is that if you really need to rely on theoretical limits of interrupt latency and/or instruction cycle timing, there is something seriously wrong with your system's design to begin with. Finding the limits is more like an academic exersize to get a feel for the platform rather than having a real practical use.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: Best MCU for the lowest input capture interrupt latency
« Reply #112 on: April 08, 2022, 07:28:33 pm »
But I'm sure a British moon mission will do much better and have a much better designed and tested computer system that will do more than just cope... On the other hand, considering my experience with the electrical systems on British cars, the rocket probably won't get off the ground. :-DD

Wow. I can only assume some Brit pissed in your cornflakes this morning. Just ... wow.

Sorry. Sometimes I just get tired of people, who have never done something themselves, second guessing and criticizing those who have. Hindsight is always 20:20 after all.

Another example: For years and years I heard that PAL is so much better than NTSC. Well sure, PAL was developed a decade after NTSC and had the advantage of learning from NTSC's example. Sometimes being first is a disadvantage because you lock yourself in and have to maintain backwards compatibility with older implementations, like the NTSC designers had to do when they added color (which they did brilliantly, IMO). This kind of Monday morning quarterbacking (sorry all you non-Americans--Google it) annoys me.
Complexity is the number-one enemy of high-quality code.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Best MCU for the lowest input capture interrupt latency
« Reply #113 on: April 08, 2022, 09:11:56 pm »
I found an interesting NXP app note about Cortex M-7 which provides real measurements for i.MX RT1050:

https://www.nxp.com/docs/en/application-note/AN12078.pdf

The case we would be interested in is in the chapter 5.3 - "GPIO interrupt latency"

They send a pulse, fire an interrupt and use 3 commands to produce the output - LDR/MOV/STR (compiled from the C code):

Code: [Select]
void GPIO5_Combined_0_15_IRQHandler (void)
{
    GPIO2->DR = 1u << 23
    GPIO2->DR = 0u;
    GPIO_ClearPinsInterruptFlags(SW_GPIO_BASE, 1u << SW_GPIO_PIN);
}

Running at 600 MHz, they verify that the interrupt latency is 11 cycles (18 ns), but they get 75 ns interval between in and out pulses on the scope. The majority of this time - 34 cycles (57 ns) - is consumed by the execution of 3 (presumably uncached) commands. I don't know where thir ISR was located. Running from ITCM could probably cut down on the number of the cycles, but nobody knows by how much.

BTW: Unrelated, but interesting: When they move processing to a RTOS task, the latency goes to almost a microsecond.
 
The following users thanked this post: SiliconWizard

Online uer166

  • Frequent Contributor
  • **
  • Posts: 872
  • Country: us
Re: Best MCU for the lowest input capture interrupt latency
« Reply #114 on: April 08, 2022, 10:30:07 pm »
I think the really correct way would have been exactly what a modern $0.40 microcontroller does in its quadrature encoder timer module: count the cycles on a simple hardware counter (reg + adder), then have the CPU data bus connected so that this counter can be accessed whenever CPU needs the latest value.

I don't think that pattern would work, every transistor is precious when you only have 2-3 per chip, there is no way they could afford that many counters (one per peripheral), when you have a few dozen sensors. They re-used hardware that was already there, which happened to be there for CPU as well. Of course today there's no excuse for that, but that amazing system worked for what it was intended in the end, and was probably the densest computing entity at the time.
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1626
  • Country: nl
Re: Best MCU for the lowest input capture interrupt latency
« Reply #115 on: April 09, 2022, 07:21:20 am »
I found an interesting NXP app note about Cortex M-7 which provides real measurements for i.MX RT1050:

https://www.nxp.com/docs/en/application-note/AN12078.pdf

The case we would be interested in is in the chapter 5.3 - "GPIO interrupt latency"

They send a pulse, fire an interrupt and use 3 commands to produce the output - LDR/MOV/STR (compiled from the C code):

Code: [Select]
void GPIO5_Combined_0_15_IRQHandler (void)
{
    GPIO2->DR = 1u << 23
    GPIO2->DR = 0u;
    GPIO_ClearPinsInterruptFlags(SW_GPIO_BASE, 1u << SW_GPIO_PIN);
}

Running at 600 MHz, they verify that the interrupt latency is 11 cycles (18 ns), but they get 75 ns interval between in and out pulses on the scope. The majority of this time - 34 cycles (57 ns) - is consumed by the execution of 3 (presumably uncached) commands. I don't know where thir ISR was located. Running from ITCM could probably cut down on the number of the cycles, but nobody knows by how much.

BTW: Unrelated, but interesting: When they move processing to a RTOS task, the latency goes to almost a microsecond.
Interesting numbers.
Perhaps the limitation is also in a different part of the MCU, though. But I don't know the i.MX chips too well, only talking from investigations in STM32s..

I think on most microcontrollers running up to the 100-200MHz range, they have their GPIO peripherals directly onto the main AHB bus, along with CPU, FLASH, RAM etc. However for these high-speed MCUs that run at 500MHz+ or so, the GPIOs may be behind several peripheral bridges that increase latency. For example on the STM32H7, the GPIO peripheral is behind an AXI bus matrix and a AHB bus matrix. The AXI and AHB4 bus runs "only" at 200MHz.

I don't have a STM32H7 board in my desk. But I've read stories from people "complaining" about slow GPIO speed, in the order of 10 cycles per register write. That way a simple pin toggle could even be slower than on STM32F7. Perhaps this is also the case on the NXP chip. In that case 34 cycles could be explained, e.g. 3x 9 = 27, leaves 7 extra for loading constants and stack maintenance.
Or there is still some latency in there from FLASH. Who knows. If the test program is small (just this IRQ and main() with an infinite loop), then caches should also "do their job" even when it's not placed in ITCM.

So even though the IRQ latency can be great, the time till GPIO toggle can be still quite high if ran through software.
And those 2 goals can also be quite different.
« Last Edit: April 09, 2022, 09:08:35 am by hans »
 

Offline mino-fm

  • Regular Contributor
  • *
  • Posts: 142
  • Country: de
Re: Best MCU for the lowest input capture interrupt latency
« Reply #116 on: April 09, 2022, 10:08:45 am »
Now I tried to get max. speed of IO-response using EXTI-signal from PE5 and watching PB3 as output.
STM32H723 @ 550 MHz ISR looks like this:

#define PE5_RISING  (1 << 5)
#define PB3         3
void EXTI9_5_IRQHandler(void)
{
  GPIOB->BSRR = (SET_GPIO << PB3);    // IO-Bit set
  GPIOB->BSRR = (RESET_GPIO << PB3);  // IO-Bit reset
  GPIOB->BSRR = (SET_GPIO << PB3);    // IO-Bit set
  GPIOB->BSRR = (RESET_GPIO << PB3);  // IO-Bit reset

  EXTI->PR1 = PE5_RISING;             // clear flag
  __DSB();
}


Caches are enabled and ISR has highest priority. 1. picture shows a typical response of arround 70 ns. 2. picture shows jitter of >= 10s sampling time of 100 kHz input signal.

Although PB3 is set and reset writing directly to BSRR, output signal needs 12 cycles of 550 MHz (22 ns) to set or reset the output pin.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Best MCU for the lowest input capture interrupt latency
« Reply #117 on: April 09, 2022, 02:37:12 pm »
Running at 600 MHz, they verify that the interrupt latency is 11 cycles (18 ns), but they get 75 ns interval between in and out pulses on the scope. The majority of this time - 34 cycles (57 ns) - is consumed by the execution of 3 (presumably uncached) commands

No, I think you authors misinterpret the results; the "majority" of time is not used to fetch and execute the instructions; majority of the delay is:
* Synchronization of the input to the IPG clock domain and generating the interrupt signal to the CPU clock domain - this part is completely lacking from the analysis,
and then,
* STR instruction writing from the CPU clock domain to the IPG clock domain.

They seem to give the impression that the STR instruction "stalls" until the result is seen on the scope screen, but this is not the case.

Instructions run fast. IO clock domain runs slower. That's exactly why we have data barrier instructions; when we need to "slow down" the instructions.

And this is where assumptions go wrong. You scope like they did on the paper, and calculate it took 34 cycles. But it really didn't. The CPU went on executing the code faster; the IO is just slower than the CPU! That's also why it's not fruitful to count CPU cycles because it's not the bottleneck.

Not 100% sure, but I'd guess most M7 MCUs would prefetch the first ISR instructions in parallel to stacking registers from flash, so there should be no difference in the first few linear instructions whether running from flash or ITCM. This could be proven, too, if necessary, but it's needless extra work when you can just place the routine in ITCM (or main RAM); that's why it exists. The benefit of ITCM compared to main RAM is independence of DMA transfers affecting the timing.

Having IPG set at 150MHz, IO operations are way slower than the 600MHz CPU clock might indicate for a casual reader. As you say, it's not said where the ISR resides, moving it to ITCM might shed out a few clock cycles, but OTOH might not due to parallel flash prefetch making it already as fast as possible from the CPU point of view.

STM32H7 series, which I have used on quite a few projects since the introduction, for example supports IO clock domain (D3 domain; AHB3 or AHB4 IIRC) up to 240MHz. With fCPU of "only" 480MHz, the performance would be still better than the iMX running at IPG = 150MHz. The revision history of that pdf indicates they accidentally ran at IPG=300MHz at first, which is beyond the allowed range, but the results would have been interesting to see.

But I don't actually live in my lab so I can't measure anything now.

The point is, the clock domain speed is the most defining factor. Instruction counting is secondary, especially because CPU core tends to run at higher clock speed than the IO, so even if you have 1-2 cycles of jitter there, it's just... insignificant. Hence, the separation of computing timing from the everything else. Instruction timing might have mattered a lot more when it happened at 8MHz in a CPU with lousy peripherals.

But I'm sure I know nothing because I dare to challenge a "well respected" member.

EDIT: Even with FLASH prefetch going in parallel with stacking, that piece of LDR-MOV-STR code does have one disadvantage: the LDR (which loads the IO port address, I guess) likely accesses outside of the FLASH prefetch range, requiring spending the number of FLASH wait states anyway. So it pays off to have the ISR in ITCM (or even just main RAM) anyway.
« Last Edit: April 09, 2022, 02:46:52 pm by Siwastaja »
 
The following users thanked this post: hans

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Best MCU for the lowest input capture interrupt latency
« Reply #118 on: April 09, 2022, 03:18:46 pm »
But I'm sure I know nothing because I dare to challenge a "well respected" member.

Passive-aggressive statements don't do you a favour; they are often intended to shut down discussion.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Best MCU for the lowest input capture interrupt latency
« Reply #119 on: April 09, 2022, 04:49:04 pm »
Instructions run fast. IO clock domain runs slower.

You're right. And the mino-fm's data are more telling because they show jitter. The peripheral clock is running at, perhaps 50 MHz, then you get up to 2 cycles of jitter because of the phase errors, then 1 cycle to sync, then there's interrupt inovocation - roughly 20 ns, then the output stage (STR instruction) takes 1 cycle to get it out.

Or it might be that the peripheral clock is 100 MHz, or 150 MHz with longer pipelines, but for such clocks the jitter would have been smaller I think. It should be possible to run the peripheral clock faster (to some extent) and thus to make the reaction time shorter.

The net result - roughly 80 ns average latency with 40 ns peak-to-peak jitter, with worst case being 100 ns. The interrupt latency is not very significant in the great scheme of things - only 20 ns out of the 60 ns minumum latency.
 

Offline mino-fm

  • Regular Contributor
  • *
  • Posts: 142
  • Country: de
Re: Best MCU for the lowest input capture interrupt latency
« Reply #120 on: April 09, 2022, 05:45:33 pm »
And the mino-fm's data are more telling because they show jitter. The peripheral clock is running at, perhaps 50 MHz, then you get up to 2 cycles of jitter because of the phase errors, then 1 cycle to sync, then there's interrupt inovocation - roughly 20 ns, then the output stage (STR instruction) takes 1 cycle to get it out.

AHB4 clock is running at 275 MHz - as fast as possible ;-)
I didn't expect that it takes so much time. As said before, instruction timing doesn't matter at all.

There is one thing to say: I added this ISR to an operating system (frequency counter) which accesses PORTB and PORTE too. It looks like this will slow down synchronisation and append this jitter.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Best MCU for the lowest input capture interrupt latency
« Reply #121 on: April 09, 2022, 09:24:15 pm »
AHB4 clock is running at 275 MHz - as fast as possible ;-)

Wow! The output pulse is slightly longer than 20 ns, so it's most likely 6 peripheral clocks (or 12 instruction clocks). It does need to do a lot - at least 3 instruction clocks for the execution, there there may be wait states for CPU accesses to the bus, then the periphery must read from the bus and process it somehow.

The numbers look very similar to i.MX RT1050 so it looks typical.

I don't quite understand why the jitter is so high - 10-11 peripheral clocks. May be some sort of bus contention.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: Best MCU for the lowest input capture interrupt latency
« Reply #122 on: April 10, 2022, 06:26:47 am »
But I'm sure I know nothing because I dare to challenge a "well respected" member.

Passive-aggressive statements don't do you a favour; they are often intended to shut down discussion.

I'm not passive-aggressive, I am active-aggressive. I have called you out explicitly, and honestly stated I think you really are a guerilla marketing shill. I did ask the question does anybody else see like this, and would have preferred honest answers. I only got those via PM. Publicly, no one except me dares to say either "yes" or "no". Instead they go for passive-aggressive attacks against me. I think this tells a lot about these people and their moral. Heck, if you really disagree, just say so.

I encourage everyone to run a forum search with search term "xcore" and look at the results. Almost 100% are by a single person, date back for years and years, and are written exactly like marketing people write ("silver bullet points" style). Most are on-topic, but you will be able to see some that stand out in a bizarre way, just like having to meet a certain quota of writing xcore-positive messages, and no one happened to ask about timing that month.

And, I might still be wrong. But I also might not.
« Last Edit: April 10, 2022, 06:30:24 am by Siwastaja »
 
The following users thanked this post: hans, enz, uer166

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Best MCU for the lowest input capture interrupt latency
« Reply #123 on: April 10, 2022, 08:06:26 am »
But I'm sure I know nothing because I dare to challenge a "well respected" member.

Passive-aggressive statements don't do you a favour; they are often intended to shut down discussion.

I'm not passive-aggressive, I am active-aggressive.

Yours was a passive-aggressive statement. Your personality is a strawman argument in that context.

Quote
I have called you out explicitly, and honestly stated I think you really are a guerilla marketing shill. I did ask the question does anybody else see like this, and would have preferred honest answers.
I only got those via PM.

Obviously there cannot be any reponse whatsoever to those unpleasant innuendos. They have no place in a technical discussion.

SpacedCowboy made this observation, earlier in this thread: https://www.eevblog.com/forum/microcontrollers/best-mcu-for-the-lowest-input-capture-interrupt-latency/msg4106905/#msg4106905

Quote
Publicly, no one except me dares to say either "yes" or "no". Instead they go for passive-aggressive attacks against me. I think this tells a lot about these people and their moral. Heck, if you really disagree, just say so.

What on earth are you on about?!

When I disagree, I say so - and give my reasons. I don't resort to innuendos.

Quote
I encourage everyone to run a forum search with search term "xcore" and look at the results. Almost 100% are by a single person, date back for years and years, and are written exactly like marketing people write ("silver bullet points" style). Most are on-topic,

That's the very important point, although I would think 100% are on topic.


Quote
but you will be able to see some that stand out in a bizarre way, just like having to meet a certain quota of writing xcore-positive messages, and no one happened to ask about timing that month.

And, I might still be wrong. But I also might not.

You are wrong. Completely wrong.
« Last Edit: April 10, 2022, 08:33:36 am by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline mino-fm

  • Regular Contributor
  • *
  • Posts: 142
  • Country: de
Re: Best MCU for the lowest input capture interrupt latency
« Reply #124 on: April 10, 2022, 11:32:24 am »
To get minimal jitter - avoiding distortion of other functions - I made a CubeMX startup-file and added only one init-function and the ISR. Now jitter is reduced to less than 10 ns. Sampling time of 100 kHz input signal has been several minutes. This is for H7xx.

Going on, I wanted to see how F746 will response to an external signal. Again I made a small startup-file configuring SystemCoreClock and AHB1 to 216 MHz and looked what happens.
Response time is about 110 ns but - surprising for me - speed of GPIO now is four times faster as H7. So I had to proof H7-code again, but it will not work faster as before.
To get better control of timing F746 generates 4 output periods at PB3.
« Last Edit: April 10, 2022, 11:36:01 am by mino-fm »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf