Marshall,

You really are trying to tackle this in a way that have a number if big problems.

1) The amount of generated machine code to support your fancy table driven method will be horrendous.

2) Code of this type has a very nasty habit of breaking whenever certain types of local variables and calling arguments are optimized by the compiler or linker. Some compilers may be more susceptible to these problems than others. Keil is known to expose difficulties in how it attempts to optimize local memory usage via tool assigned overlaying.

3) Indirect calls through tables are generally not analyzable by the compiler or linker in the optimization phases of the build and almost always end up creating problems with register and local memory resource allocations.

You would be far far better off setting up your timer interrupt to have a state variable that counts 0 -> 9 -> 0 to 9. Then code a switch statement inside the timer ISR for each case of the state variable. Within the case blocks directly call the various types of subroutines unique to each case. You may also be advised to toss most if not all of the calling arguments to these subroutines such that they are all void func(void); type routines. Use global variables for critical states that are managed within these subroutines.

I have coded 8051 for maaaaaaaaaaaany years and can relate many examples of practical experience that has led to using techniques like I suggest above. There have also been a number of times that my work has veered off to other architectures that supported a nice standard stack environment that lent itself beautifully to C style coding. I would get into the habit of making "elegant" and more "complex" code similar in ilk to the kind of things that you are trying to use. Then I come back to an 8051 type project and let these habits dribble into my 8051 code. It is always a painful re-discovery that it is necessary to go back to writing much more simply architected code for the 8051.

Michael Karas