Interrupt latency questions
Re: Interrupt latency questions
Thank you for the replies. I’m going to try using timer DMA with an external clock. If I can get it to work it’ll be fast enough.
-
trimarco232
- Posts: 34
- Joined: Wed Jul 12, 2023 11:09 am
Re: Interrupt latency questions
I remember , I got 200ns with PI PICO (which is ARM , too) ...
Re: Interrupt latency questions
pico is running from *sram*? it could be a factor for the differences.
flash i'd guess would at least need 3-7 wait states, even SD cards can have a latency of 500 us (1/2 milli sec)
https://news.ycombinator.com/item?id=32 ... e%20higher.
flash i'd guess would at least need 3-7 wait states, even SD cards can have a latency of 500 us (1/2 milli sec)
https://news.ycombinator.com/item?id=32 ... e%20higher.
-
trimarco232
- Posts: 34
- Joined: Wed Jul 12, 2023 11:09 am
Re: Interrupt latency questions
yes , I have put the ISR in RAM , but I have no idea of the code between the trigger event and the ISR start
the speed is 133MHz , so the number of cycles is just 17-18
back to STM32 , I wonder if we can put ISRs (or other critical functions) in RAM , in order to make it faster ; I never done it because 1.6us was "fast" enough for my projects , thus far
the speed is 133MHz , so the number of cycles is just 17-18
back to STM32 , I wonder if we can put ISRs (or other critical functions) in RAM , in order to make it faster ; I never done it because 1.6us was "fast" enough for my projects , thus far
Re: Interrupt latency questions
a 'simple' way is to use stm32f4xx, that one has cpu cache (ART accelerator) and is zero wait.
but that the interrupt codes needs to be in cache when it is called, in theory if say a cpu / mcu is running at 100 mhz, that is like 10 ns for 1 cpu cycle.
I'm not sure what it'd take to 'measure' that. stm32f4xx is possibly faster than 1 us, but that I'm not sure what are the factors (slowing it down) and how to measure that.
servicing interrupts is quite a lot of ops for a cpu, it needs to stack the main stack save all the current processing state, jump to isr code which would setup a new stack and run codes, then that on return, unstack and resume from interrupted main code.
and that because interrupts can be disabled/masked. sometimes we may mistake that as latency when some 'driver' codes mask interrupts even for a while.
but that the interrupt codes needs to be in cache when it is called, in theory if say a cpu / mcu is running at 100 mhz, that is like 10 ns for 1 cpu cycle.
I'm not sure what it'd take to 'measure' that. stm32f4xx is possibly faster than 1 us, but that I'm not sure what are the factors (slowing it down) and how to measure that.
servicing interrupts is quite a lot of ops for a cpu, it needs to stack the main stack save all the current processing state, jump to isr code which would setup a new stack and run codes, then that on return, unstack and resume from interrupted main code.
and that because interrupts can be disabled/masked. sometimes we may mistake that as latency when some 'driver' codes mask interrupts even for a while.