I worked on a system that has a huge collection of subrouines that were linked together in the following ways.

1) There are a series of subroutines that paint the screen context. Some of these paint the whole screen while others just paint a context sensitive portion of the screen.

2) There are a whole set of key response routines that deal with the processing for each key response in all contexts of the menu system.

3) My system has just six keys that drive the menu system consisting of UP, DOWN, LEFT, RIGHT, ENTER, and ESCAPE. There are six global variables that were declared as function pointers to void func(void) type subroutines. These are set to point to the current processing routine for each key.

4) At each level of the menu system the key response routines will call the short display routines to make appropriate LCD image changes and then may change one or more of the six function pointers to suit the new context.

5) Keypad scanning, debounce, and repeat controls are done as triggered through a timer interrupt function. Any detected key codes are placed into a circular queue.

6) The main loop of the program had a primary duty of looking for keys in the key queue. Any found would be processed by calling the appropriate key response routine indirectly through its corresponding function pointer.

7) Certain menu things that needed to flash or delay were handled via two software timers. The above mentioned timer interrupt (10 millisecond interrupt rate) would manage these timers as down counters. If either was a non-zero value it would be decremented. At the time of decrement if one of these timers went to zero then another corresponding function pointer would be called. These dispatched to response routines that work almost exactly like the key pad response routines. (It turns out that for some menu functions the timer function pointer would actually point to a key response routine).

8) Any of the keypad or timer function pointers that were not in use at a particular time or in a particular context were set to point to a SYSTEM_NULL type routine that simply was a subroutine with an immediate return. This was used as opposed to NULL values for the function pointers becasue it saves having to check the function pointer for a non-zero value every time it was used as a dispatch to a function.

9) The menu display routines maintained a global variable that is called the "screen state variable" This basically indicates which menu screen was active.

10) Serial I/O on two different UART ports is managed by having the physical I/O uncoupled from the mainline code through a set of circular queues. This takes a Tx and Rx queue for each port. The serial interrupts handled the data flow on the UART by reading and writing these queues.

11) Another job of the mainline program was to call two separate state machines, one for each UART. One state machine decoded packets of data received on the UART0 that would result in screen value displays of certain numerical values. If the "screen state variable" had an appropriate value then the state machine would call to display the value from the packet. The other state machine had the job of managing a master to slave protocol communication to some other equipment. The commands on this UART were generally initiated by key stroke actions in one of the key response routines. The key response routine would actually queue the command in a circular buffer that held a small of command structure data. The state machine would de-queue these and format serial I/O packets and send them out. The state controls also included managing the reply packets from the commands. Timeouts for replys were managed by a third software countdown timer. Reply packets often resulted in display changes and there was a provision for a function pointer that could be invoked from the reply packet state machine. At reply decode time this function pointer is called to perform a screen context function that operates exactly analogous to either a key response or a software timer function pointer call.

Now while this system sounds complex it is in actuality quite easy to use. First off it fits very well to the 8052 architecture because the stack usage is essentially flat. Traversal down into a menu tree is not preserved in a stack context. A second advantage is that the system uses very little internal internal RAM. All of the queues mentioned are maintained in XRAM that is built on-board the processor with the queue index pointers stored in the internal fast RAM. Lastly a large FLASH space microcontroller allowed for ample space to store the healthy sized collection of subroutines that performed all the functions I mentioned above. Many many of these subroutines are extremely short and do only a small amount of processing. On the other hand some of the routines would do a fair amount of processing, especially if they interacted with the serial I/O packet queueing system.

Another aspect I found nice about this system was the relative ease I found it to document a design and then render that design into code. It is also surprisingly easy to patch in new functonality as the product requirements change. However, seat of the pants coding to make changes does not work well. Instead the changes need to be first made to the menu system flow documentation and then the coding becomes easy. A project partner also was able to write a very simple program on a PC to mimic the functions of the LCD unit of the target product. The same code that managed the target 8052 type product could be compiled using a Borland or Microsoft C compiler and the user menu system would then run on the PC. This cross-target system even used two or the PC comm ports in place of the 8052 UARTS to permit connection to the ancillary equipment so that VERY realistic menus and keypad interaction could be run on the PC. It turns out that the PC implementation was most useful for showing the user interface of the product to potential users to get "satisfaction level feedback" and "please change that feedback". The PC implementation also was invaluable in capturing screen shots of the graphic LCD images for the users manual for the product.

Michael Karas