2016-12-14 05:36 AM
hello,
I'am use for a project the stm32f429. The interrupt handler must react so soon as possible.The stm32f429 interrupt responstime is 218ns.It's fast but not fast enough. I decided to make a new design with the stm32f767 running at 216 mhz. With the same configuration as the stm32f429 running at 180mhzThis configruation is generated with STM32CubeMX / KEIL vision MDK-ARM V5However the interrupt response time is much longer, it is 376ns !!
Well is the processing of instructions faster.What is the reason that the stm32f767 has a longer response time compared to the stm32f429 ??
#interupt-stm32f767-vs-stm32f429-responstime2016-12-14 05:58 AM
Instead of trying to explain the many sources of interrupt latency (and there are many of them, most of them hard to control or avoid) and its jitter, and difference between mcu models and other particularities of design, I suggest to give up the idea of having latencies below dozens of machine cycles in any 32-bitter up front.
For controlled latencies below 1us, use hardware. There's plenty of hardware in these chips. Tell us more details of your requirements to receive more help.
2016-12-14 07:04 AM
Hi Hans,
Are you measuring the interrupt response time on the first iteration? Could you give as the response times for the second and the third iterations?
If you will use the STM32F7, I advise you to use the ITCM RAM memory. It is reserved for the CPU Execution/Instruction
useful for critical real-time routines.By the way, what is the the response time value needed for your application ?Note:
Thestm32f429 and
stm32f767 devices do not share the same bus-matrix architecture; So, using the same configuration (with the same clock value) does not mean that you will get the same interrupt time response.
Regards,
Lawliet.
2016-12-14 07:19 AM
Hello waclawek.jan thanks for your reply
I am aware that there is faster hardware. Often, there is provided a FPGA with embedded ARM core.
I want to find the limit. The STM comes at the place of a RAM chip, any read / write comes within an interrupt in the STMit works good with the stm32f4 <250ns, the more time I have on the more opportunities I get to influence the RAM data.2016-12-14 07:42 AM
Some of the possible sources of latency:
- stack in slow memory
- execution from slow memory
- complete vs. lazy FP stacking
Perceived latency (e.g. delay between interrupt edge on input pin and edge on an output pin manipulated at the beginning of ISR) is added up from the hardware latency and any software the compiler might insert between ISR entry and the instruction which performs the pin manipulation. Study the disassembly.
JW
2016-12-14 08:49 AM
Hello Lawliet
The same configuration I mean the test, see scoop image.
Yellow channel is the chip select connected to the PC0 of the STMThe PCO is configured as ''Interrupt Mode Ecternal widh trigger Falling edge detection''Purple channel is the PG13 standard GPIO output (High speed) GPIOG-> = BSRR GPIO_PIN_13.;Very simlpe test.The question remains, What is the reason the stm32f767 That Has A higher response time Compared to the stm32f429 ??and has the stm32h7 same response time (next year)2016-12-14 08:56 AM
I gave you several possible reasons above. It's up to you to sort out.
Lawliet gave you
a question
a couple of questions, please answer them (one of them is aimed at the slow memory to execute from, accelerated by cache).JW
2016-12-14 09:04 AM
An MCU and an FPGA have different merits... which was commented already.
Assuming this is highest priority level interrupt, and someone would like to reduce the latency, here would be the things to look at:
1. Make the interrupt vectors in RAM
2. Put the interrupt routine in RAM or in CCM memory on F4 (no stolen cycles by DMA)
Let us know how much of a difference this makes.
2016-12-14 09:20 AM
I thought The interrupt routine sevice from the STM is running in Flash Memory. is the ''accelerated by cache'' this what you see in the picture ??
I am a beginer ...
2016-12-14 09:21 AM