AVR Freaks

Amen. :wink:

+1 to this.

-Deven

PeteAVR pm’ed me about my INTC driver optimisations, and without realising, my reply turned into quite a lengthy rant about AVR32 interrupt handling. This isn’t supposed to start a lengthy discussion about the ASF or flame against the ASF, and I also know that it might be too complicated or overkill. I just thought I’d share, just in case someone else is interested in this as well. Maybe it even offers some interrupt handling insights that the Atmel application notes don’t.

A word of caution first: I’ve been using the ASF 1.7 with my old-ish project. I haven’t used newer ASF versions yet, so I don’t know how much of this still applies nowadays, but your mention of _get_interrupt_handler() leads me to believe that not much changed. Just keep that in mind.

Second note: All my examples are for the AT32UC3A3256, because that’s what I wrote my code for. The INTC should be similar or identical for all other AVR32s.

Now on to the main menu...

The thing is that the INTC has fully configurable interrupt groups. Every group has a priority and its own autovector (see registers IPR0...IPR63). The INTC decides in hardware which group currently is the one with the highest pending interrupt request and delivers the address of its handler (EVBA + autovector) to the CPU. So if the USB group has an interrupt pending, the CPU can jump directly to the USB interrupt handler.

Now while that sounds pretty fast, the INTC driver from the ASF actually discards most of the work the INTC hardware has already done. Instead, it registers interrupt handlers for all interrupts that are identical except for the priority parameter. With this priority parameter, _get_interrupt_handler() goes to query the ICR for the group that caused the interrupt of that priority and then also gets the individual interrupt line inside that group with some error checking.

Now you noticed that the ASF includes figuring out the interrupt line, not only the group. However, some interrupt groups, such as the USB one, only have one line and there’s nothing to figure out. Also, this whole thing is rather slow. While it also includes error checking, that’s only needed either during initial development or if you have careless or inexperienced users who might enable an interrupt source without registering a handler for it first.

So what the ASF does:

* interrupt X triggers * ISR only knows the interrupt priority
* call function (additional overhead)
* use priority to get group
* use group to get line
* check if interrupt source suddenly vanished (rather pointless at this point)
* use line to get C handler
* call the C handler unless it’s NULL
* handle interrupt in C function

For comparison: The ASF ISR’s have 4 assembly instructions and _get_interrupt_handler() compiled with -O3 has 15 instructions. Each periphery bus register access has at least 1 or 2 stall cycles. The function call takes at least 4 cycles. I’d estimate all that to take at least 25 cycles (best case configuration; cycle data from AVR32UC Technical Reference Manual), probably more. At 66 MHz that’s almost 0.4 μs. That’s a lot if you’re trying to catch a byte that flies past via USART in just 5 μs (2 Mbit) and you have to leave ~3 μs for uninterruptible code from other ISRs.

What can be done if there’s only one line in a group:

* interrupt X triggers * ISR for X is called
* handle interrupt in assembler or call C handler

That’s a bit shorter and sounds faster, doesn’t it?

My ISR for the TC0 looks like this:

A single assembly instruction and my C handler is ready to roll. If that isn’t a low latency, I don’t know what is.

Now there are groups that have more than one line, like the PDCA. I have an array in SRAM with function pointers to the individual handlers, all simply created with C code. Structure would be like this:

* interrupt X triggers * ISR for X is called
* get line from group X
* get C handler for line
* call the C handler
* handle interrupt in C function

This is more like what the ASF does, but faster.

My ISR for the PDCA group looks like this:

That’s just 6 assembly instructions for what the ASF does (sans error checking), and as a bonus, you get the PDCA number as a parameter to your C handler because it starts counting from the LSB of IRR3. I have two C handlers for several PDCAs, one for transmit and one for receive. They know what PDCA they’ve been called for by that parameter:

At about 0.1 μs, that’s 0.3 μs saved.

Now there are several interrupt groups that have more than one line, like PDCA, GPIO, EIC and more, so you’d have to write your own small handlers for all groups that you use.

However, if you do that, you can use the same technique for interrupt groups that have only one line but several causes. I use it for USARTs and the USBB. Here’s my USART ISR:

This reads the USART’s CSR (Channel Status Register) and directly jumps to the individual handlers for TXEMPTY, TIMEOUT and whatever. The number parameter in r12 is there so that the called handler can tell which one of the two USARTs that I use it was called for.

Why do I do it like that? Without that CSR counting and handler-table-jumping, I’d have to check all relevant USART status bits in one long if/else if block, which would be rather slow. O(1) instead of O(n) is the way to go. ;-)

The USBB ISR looks similar, but it’s shorter because I know that the UDINT register won’t have any interrupt bits set that I don’t need. I can also prioritise causes with higher numbers (like USB DMA transfers) over ones with lower numbers by counting from the MSB of the register:

I did all this to reduce interrupt handling latencies as much as possible and the gain is about one order of magnitude (~10x). The numbers above sound like it isn't that much, but in practice there can be additional slowdowns due to concurrent access of the various DMA controllers on buses and SRAM, especially during burst accesses. The longer the interrupt handling, the higher the chances to collide with something. I needed this speed-up for my application, but some people might argue that I just should’ve chosen a faster CPU. Brawns over brains and all...

Nothing. Or everything. I threw out all the ASF stuff and wrote my own interrupt handling, as you can see. :D

Pro/Con of my version:
+ faster latencies (up to 0.5 μs, maybe more depending on MCU configuration)
+ usable for individual status bit handlers
+ can pass parameters to interrupt handlers
- needs some AVR32 assembly knowledge
- more complicated to maintain and takes longer to write
- some handlers can’t be changed during runtime
- less error checking, so it can crash if you’re not careful

Pro/Con of the ASF version:
+ doesn’t need any assembly knowledge
+ better to maintain and faster to write
+ all handlers can be changed during runtime (Does anyone actually do that after the init phase?)
+ a bit safer (can still crash easily, though)
- slower latencies
- needs cumbersome and even slower handlers with lots of if/else
- can’t pass parameters to interrupt handlers

Take your pick. I hope this answers your questions. Sorry for the lengthy rant. ;-)

Edit:
- register access delays apply to registers on periphery buses
- added missing interrupt attributes to example handlers
- added note about counting IRR3 LSB first

Edit 2:
- added a forgotten “isn’t”
- added a few missing commas

Yep, this was indeed high quality stuff. Catweax, thank you for sharing.

In my solution the interrupt vector table isn’t placed in RAM either, but with the rest of the code.

Your idea sounds quite interesting and doesn’t need the additional jump from the assembly block to the C function elsewhere, thus saving a bit more time. The hard-coded integer constants and entry points don’t sound very flexible, though. I have a lot of debugging code that I toggle with #ifdef, so the interrupt handlers often significantly change in size. I prefer to call labels and let the linker take care of all the addressing issues for me.

In the end it boils down to speed vs. flexibility, I’d say.

More flexible: ASF > my solution > your solution
Greater speed: your solution > my solution > [the West Siberian plain fits here] > ASF

All my ISRs, like the isr_pdca that I mentioned in my long post, are in one assembly file that starts with a label called “_evba”. Thus, all ISRs are in one rather short continuous block somewhere in the code, usually somewhere at the end. Then I set EVBA to the address of “_evba”. The offsets for the IPR registers are calculated by subtracting “_evba” from the ISR addresses.

I took that idea from the ASF’s exception.x (or exception.S).