Electronic – How to instruct the compiler to use 8 bit bytes instead of 16 bit integers

The interrupt mechanism is described in the ARM Architectural Reference Manual and/or the Technical Reference Manual, both are available at infocenter.arm.com. Then there is some info that you need from the chip vendors datasheet (arm does not make chips they make processor cores that chip vendors buy and use). so unlike the traditional arm with an irq and fiq input the cortex-m3 has a bunch of interrupt inputs and you have to figure out where the vendor wired your interrupt.

The way the cortex-m's work you have an interrupt vector table which includes addresses for the routines for each of the interrupts/exceptions. (described in the ARM ARM and/or ARM TRM) reset happens to be one of those so you already have that implemented, the first four bytes are loaded into the stack pointer then the next four are the address for reset then it goes into exceptions and interrupts which are core specific (the cortex-m3 and cortex-m4 and cortex-m0 dont necessarily have the exact same list and certainly each vendor or model may have different things wired up).

Then of course you have to enable interrupts on the vendor side, the peripheral, perhaps an interrupt controller then on the arm side.

The nice thing about the cortex-m design is that the hardware conforms to the arm calling convention (it preserves registers for you on the stack, etc), you can place the address to a C function right in the vector table, there is no longer a need to wrap your C interrupt handler with assembly or use compiler specific directives to get the compiler to wrap your code for handling interrupts.

I generally recommend that you start by polling your way toward the core, if possible poll the peripheral interrupt status to see if it fired, then enable that status to go on to the next level, poll that, then enable that eventually to the edge of the core where you can usually poll it without enabling it into the core. YMMV, some folks like to just Christmas Tree light it all up at once and see what happens (write the finished code first then debug a bunch of code not knowing where to start looking).

Here's the trick:

• You configure your "extra-low priority interrupt" as normal low pri interrupt: set up the vector, activate the interrupt, all the standard stuff.
• Write the handler procedure at an arbitrary address as usual. Standard interrupt restrictions apply - saving/restoring registers, stack discipline etc. End it with RET, not RETI.
• At the interrupt vector address perform three operations:
  • push lower byte of your handler address
  • push higher byte of your handler address
  • RETI

That way, the interrupt flag is cleared and normal execution is resumed, but not from the address where the interrupt occurred, but from your handler vector. You can perform the rest of the interrupt activity and then just resume the main loop from where it was interrupted by performing a standard RET - the address stored by the interrupt on stack is still there.