STM32F105 / 205 pin interrupt response time

[ronald23]

Posted on March 21, 2015 at 17:50

Hello,

For a certain application i need to set an output pin after receiving an intput pin interrupt. What is the best way to calculate the fastest possible response time? I assumed following: 1. toggling an input pin will directly trigger the interrupt. The speed of the ABP2 is not a factor here 2. then there is latency from the interrupt until the handler is entered 3. The code will set the pin 4. Then there is latency for the signal to propagate from the core through the APB2 to the output pin Are these correct, or did I miss something? Does anyone know where to find the number of cycles between the pin change and the start of exection of the handler code? Is there a considerable difference between the F105 and the F205? Or is it only in their clock rates? Thanks in advance. #response-time

[waclawek.jan]

Posted on March 22, 2015 at 10:39

> Does anyone know where to find the number of cycles between the pin change and the start of exection of the handler code?

I am not sure about your assumption 1, there may be resynchronisation stages in between, only ST can tell this. As for the interrupt latency and its jitter, the basic document is http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100165_0201_00_en/ric1414056338502.html > Is there a considerable difference between the F105 and the F205? The GPIO in 'F1 sits on an APB bus, behind an AHB/APB bridge, afaik. Again only ST could tell whether there are other differences. Regardless of what said above, this sort of things is better be handled purely in hardware. You probably did not tell us enough to judge but it sounds as a case for a timer. JW

[Tesla DeLorean]

Posted on March 22, 2015 at 16:27

http://community.arm.com/docs/DOC-2607

On the F1 the GPIO is slow, perhaps 4 cycles, it's behind a write buffer. The F1 also exposes the slowness of the FLASH, perhaps a 3 cycle hit per word. The F2/F4 have the ART, which caches 128-bit flash lines, and significantly hides the slowness, a hit to the prefetch port is faster than single cycle RAM. Sounds like a job for a timer/hardware solution.

[ronald23]

Posted on March 25, 2015 at 08:39

Yes, you are right. I did not tell you the complete story.

The application: There is a 3 bit digital code input on the input pins. This makes for 8 different codes. For each one of these codes I have to set a corresponding code to 8 output lines. In addition I need to check whether setting each code is allowed. This depends upon timing. Each code can only be set once in a certain time span. I don't see how this would be possible in 100% hardware, so this is why I chose the software approach. I think it is either an STM32 and handled by software, or an FPGA. I am trying to find out if I can avoid using an FPGA in this application. Come to think of it, there is more to it. - interrupt on all 3 inputs - interrupt latency + enter handler (delay 1) - read inputs to get all 3 bits (delay 2) - Check for conditions/permission (will calculate delay separately) - set outputs (delay 3) I will be able to optimize the software to some degree, but delay 1, 2 and 3 are more or less fixed I assume. My guess is that all this information is somewhere in the STM32 reference manual, but these thing are huge and I am not sure in which section I should look for it. Is ST monitoring this forum, or should I contact them directly? -