SDCC interrupt woes

If anyone else has been trying to figure out why the SDCC 8051 compiler doesn't seem to generate interrupt code that works, the secret is that if the function is defined is a file other than the main program file then a prototype of the interrupt vector function has to be declared in the main program file:

timer.c:

void TimerInterrupt( void) interrupt 3
{
   blah();
}

main.c:

extern void TimerInterrupt( void) interrupt 3;

This causes sdcc to generate an interrupt vector table.

I found this here. It is reassuring to me that a company like Maxim is endorsing this compiler.

Protothreads

I am about to start work on a couple of embedded firmware projects and I just happened to come across protothreads which use a clever C trick to implement pseudo-threading. Each thread uses only two bytes of memory (thats two: the threads do not need a stack) so it should be great on a 8051.

The trick relies on a quirk of C where it is possible for a switch statement to jump to case labels inside control statements like for loops. This code very cleverly uses the line number within the file (i.e. __LINE__) as the target for a later switch jump. Hence to 'resume' a thread the code just uses a switch statement to jump to the place within the function where it last yielded.

This offers the hope of efficient multitasking without loathsome state machines. Nice sequential coding: bliss. Compared to 'real' threads or interrupt service routines, these protothreads should not be too sensitive to obscure bugs as you know where task switching is likely to happen. This means you don't necessarily need mutexes and whatnot scatterred around. I've always been a believer in doing as much as possible in the foreground and as little as possible under interrupts and this technique will make it easier for me to do this.

The only shortcomings of the trick (apart from relying on am obscure quirk of the compiler) are that you cannot use switch statements as your thread is based on a switch statement, there are limitations regarding blocking in subroutines and local variables do not hold their values (which also applies to state machines).

I'm tempted to use the SDCC 8051 compiler as the old version of the Keil compiler we have at work does not run on Windows XP. It remains to be seen whether this trick will work with this compiler: I have no hardware to test it and I cannot get the sdcdb emulator to support serial IO so I could only tell if it worked by setting breakpoints and seeing if they are reached.

Thought: if the thread was within the first 255 lines of the source file, each thread would only need one byte to store it's state.

Peter's Blog - Nodes for firmware

SDCC interrupt woes

Protothreads