Hey group, I recently started a new job where the target is a handheld device with 3 buttons on it and a few other internal interrupts, occurring maybe only every 125ms when it is in a real processing mode, with little processing to do to service the interrupts. The system runs on a low power controller and goes to low power mode whenever possible. It is implemented as a state machine, with a bunch of sub-states, so it is really a single threaded application. This was initially designed and implemented maybe 20 yrs ago, and ported over the years.
But, the exisiting design has an event queue. I do not understand why for such a simple system. The ISRs log the events, the main operating loop queues the events to itself, and then deques and makes calls into the appropriate sub-state machine. I want to lobby to get rid of this queue because the system really cannot process more than one event at a time anyway, and the events are so spread out over time.
I contend that the single threaded application should be permitted to run as far as it can before needed an event, at which point it could simply go into low power mode and wait for an event that concerns it to wake the system. The ISR could log what the event was, if pertinent for that state, and wake the processor to handle it.
Now I have tried this arguement with co-workers already; of course I am new here and this is their baby, and everyone is resistent to change. Removal of the queue would significantly simplify the already simple system. Even state changes, state changes not even caused by events, are queued!
I guess what I am looking for is some documented ammunition for my superiors and co-workers that states when use of queue is desirable and when it is overkill. Any good books journals out there?