Replacing existing interrupt handler

[MicroController]

Spoken like someone who does not have more than four decades of experience writing assembly language on literally dozens of processors as a normal part of their day job!

Spoken like someone who missed out on the evolution of optimizing compilers for about the last four decades

[ESP_Sprite]

Spoken like someone who does not have more than four decades of experience writing assembly language on literally dozens of processors as a normal part of their day job!

Spoken like someone who missed out on the evolution of optimizing compilers for about the last four decades

No fighting in the thread please fyi, I think there's merit to both. Compilers have become really smart to the point that there's no use writing entire programs or large chunks of code in assembly, but they still can do the wrong thing at times wrt choosing the optimal path, so it may make sense to manually optimize bits in assembly.

[JimDrew]

No fighting from me. C has its place and certainly compilers are better, but to assume that a compiler can outwit a human who does this sort of work for a living is a bit foolish. I have spent more time than most people here in these forums have been alive disassembling compiled code to re-create it in full assembly to reduce size and increase speed, so I am well aware of the progress compilers have made.

@ESP_Sprite, you might recall the project I discussed with you. I need to reduce the interrupt latency by at least 25ns in order to meet the fastest timing window that a new sensor is requiring. As it stands now, from the time the GPIO pin (mapped to the MCPWM module) changes states until the highInt5 interrupt handler is entered is ~225ns. I need that sub 200ns, preferably 150ns max. I would love to be able to replace whatever mechanism is in place for handling interrupts so I can eliminate even checking of other interrupts. I don't think this is an issue of traversing a list because the latency is the same for NMI as highInt5. I just can't see how it takes 60 instruction cycles to get to the ISR. Our system works great, and we have proved this with thousands of sample units in the field beta test program. We just got thrown this curve ball with a new timing requirement and I am trying to work through it before we go to full scale production (to make sure it can be done). If you happen to know some magical way to reduce this latency, please let me know!

https://github.com/espressif/esp-idf/bl ... rs.S#L1672

This is just the high level routines, not the ROM routines. We don't get to see the ROM routines because they are included as part of the "core" package.

Each vector goes at a predetermined location according to the Xtensa
hardware configuration, which is ensured by its placement in a special
section known to the Xtensa linker support package (LSP). It performs
the minimum necessary before jumping to the handler in the .text section.

https://github.com/espressif/esp-idf/bl ... m.ld#L1406

Yeah, so this is the mystery. This seems to indicate what I was told - the interrupt vector table and entries are built by the compiler and are hard coded during the compile. That "minimum necessary" is the source of my problem. Every CPU I have ever worked with has the ability to map the vector table, typically RAM based, so it can easily be changed and can use fast memory. Those that do have hard coded vectors in code space offer information on how to set that at assemble time.

[MicroController]

As it stands now, from the time the GPIO pin (mapped to the MCPWM module) changes states until the highInt5 interrupt handler is entered is ~225ns.

How do you measure this? I.e. how do you know when the ISR is entered?

[JimDrew]

I am using a logic analyzer to capture the data. I have one input connected to our trigger signal which is going to a ESP32-S3 GPIO pin, and I have code in the highInt5 ISR (no register saves before hand) that toggles a GPIO pin using the specific assembly instruction that the ESP32-S3 has. I have also used the method of setting the register directly as a comparison. With the assembly instruction you can actually toggle the pin state every single cycle with a long string of instructions to set and clear the pin. So, you can toggle at 120MHz this way. This does require that you create an output bundle before hand. I will also say that the slew rate of the ESP32-S3's pin driver is not great. Capturing at a high enough resolution shows that the signal edges are very rounded and you end up really with a sine wave at this speed. A NOP between the instructions gives you a reasonable square wave, and 2 NOPs makes things right. Doing the normal write to GPIO_OUT_W1TS_REG/GPIO_OUT_W1TC_REG (back to back) takes about 60ns to complete compared to just two cycles (2 x 4.1667ns) to set/clear with the dedicated assembly instruction. I think the 60ns is shorter than the normal ESP32, and similar to the ESP32-S2.

I have seen ~225ns to ~320ns documented by several people in the past that have been struggling with the ISR latency, and I can confirm that ~225ns is what I am seeing.

[MicroController]

Ok. Using the dedicated IO is what I would have suggested if you weren't already.
Another unknow is of course the latency of the input signal inside the MCPWM (plus GPIO matrix, if used). Though I don't expect that to add up to 200ns...

[JimDrew]

EVERY interrupt I have tried has the exact same latency... so if I do a GPIO interrupt, MCPWM interrupt, or TIMER0 interrupt, the latency of any of these from the time they trigger to the time the highint5 (or NMI) is entered is ~225ns. So, I don't think the hardware itself (MUX routing) is causing the latency. I believe it is whatever setup is done after the interrupt trigger occurs - like setting up CPU registers and eventually getting to some large jump table (I am guessing)? 60 instruction cycles to do that though is a lot! I would expect the hardware latency to be no more than 10 cycles (most micros are 4 to 9 cycles), and that's it. Maybe there would be some type of pushing of registers (or simple register window rotation, which is free). Until I see the actual ROM code, I have no idea what is going on. If this is all hard coded at compile time, with no way to override it, then I would end up having to go back to a Microchip based solution because at least that works, albeit at nearly 4x the cost.