AVR Freaks

If this is where you are starting out then you are starting in a nice place!

Take some time to write some C programmes and then step through them in the simulator. You will see how the C and assembler relate to each other. This is a really valuable skill when working with uCs.

...just like any other processor... :wink:

As this is posted in the GCC forum can we assume avr-gcc is being used? If so then why not examine the mechanism for yourself. Just build a short C program:

If you build that for mega16 (say) then you can check the datasheet and see that the timer 0 overflow vector is the 9th vector after the reset jump. So now look at the .lss file that was created:

So at location 0: you can see there is a "jmp 0x54". That is the reset jump and takes execution to the first instructions after this vector table where code finally goes on to "call main".

At location 24: you can see that our use of ISR() has lead to a "jmp __vector_9" being created and the code for that is at location 0x72.

In passing note what the compiler has done with all the other interrupt vectors for which we didn't provide ISR(). They all have a "jmp __bad_interrupt" and that code is located at address 0x68. It's worth just having a quick look at that:

So the code called __bad_interrupt() actually just has a "jmp 0". This is explained in the "Catch all" section of the user manual:

http://www.nongnu.org/avr-libc/u...

It is the reason why, if you enable an interrupt source and don't provide an ISR() for it then when the event occurs it does a "jmp 0" and the AVR looks like it reset.

Anyway back to our ISR(). We saw that simply by writing:

this lead to vector 9 being directed to code at 0x72:

This shows that in addition to the code that sets PORTB to 0x55 there's a little more "overhead" generated. In this case it's pointless but, as yet, the compiler isn't smart enough to recognise that so it generates it anyway. It preserves R1 and later ensures that it holds 0 (internally the compiler calls this __zero_reg__ and uses it whenever a value of 0 is required). It also preserves R0 then uses the same register to read in and preserve SREG. At the end it unwinds all these things and ends with RETI. As the interrupting process that selected vector 9 in the first place will have pushed the PC value of the next opcode in main() before it jumped then this RETI will both restore that value to PC and also set the I bit in SREG back to one (like SEI) because another part of the vector jumping mechanism was that I was cleared to zero (like CLI) before the "jmp __vector_9" was performed.

And that's pretty much all there is to it though you may be interested to learn how the ISR() line we wrote became a target for vector 9. If you look at the header file for mega16 (the one I built for) you will see:

So the line:

really says:

What's more the definition of _VECTOR is in sfr_defs.h and consists of:

so the line actually says:

If you want to see the full expansion then interrupt.h also has:

So the line really looks as follows to the C compiler:

That is creating a void/void function called __vector_9 but the additional attribute stuff is what says "this is not a normal function but requires all that extra stuff to save R0/R1/SREG and must end in a RETI not a RET".

Finally, the way the entry down at 24: turns a default "jmp __bad_interrupt" into a "jmp __vector_9" uses a technique called "weak linking" but I won't try to explain that now as it's probably too complex at this stage.

It's also quite tricky to do in C. By default the linker adds a "C Run Time" (CRT) to the start of all C programs you write. This includes the reset jump, that full vector table (with all entries defaulting to "jmp __bad_interupt"), initialisation code and so on. Because there is a full vector table if you start trying to locate a code sequence at the __vector_9 location (for example) you will get all kinds of dire warnings about "your section .newvectors overlays .text at location 0x0024" or whatever.

What you'd have to do is build with -nostartfiles which means the first .s or .c file you include in the link would locate at 0x0000 and there'd be no CRT. So you'd have to arrange for a jmp at the reset vector (to avoid the rest of the interrupt table), your code at 0x0024 (or whatever), a replacement for the CRT and so on.

Not worth doing unless you are REALLY pressed and have to get something to happen as soon as an interrupt even occurs. Otherwise accept the indirection of that additional JMP at the vector location and use the CRT mechanism.