Hooks in Base Code
simon at karrak.id.au
Sun Jul 22 11:13:38 CEST 2007
Here is my two cents worth. I also hope what i am saying here is not too
basic and is comprehensible. I program in Forth so my knowledge of C
vocabulary is not fabulous.
On Sat, 2007-07-21 at 12:28 -0400, Clayton Jones wrote:
> I like the ideas presented here, but i have some experience designing
> & building real time & embedded systems so some points to think about:
I too have a long history designing, building and writing code for real
time embedded systems and all my current designs implement a similar
strategy of having Event Generators (usually interupts), an Event
Dispatcher and Event Handlers. IMHO the Event Router should be as simple
and fast as possible. Any complex sorting/ checking of event lists etc
etc should be left to code sitting on the sidelines
> 1) The Event Router should also have some sort of priority mechanism ...
How about a linked list of Event Objects which would contain the Link to
next Event, Event Priority, Event Parameters and Link to a specific
The Event Router would pass execution to the specific Event Handler for
the Event Object at the top of the list. When the specific Event Handler
had finished it would pass control back to the Event Router which would
delete the finished Event Object and move on to the next in the list.
The Event Handler could simply be a list of calls to various code. This
list could be easily edited to change the functionality of the device.
Would have to have a mechanism for handling errors.
Rather than having fixed Event Parameters i would go for a "Parameter
Heap" which would be part of the Event Object. It doesn't need any fixed
format as both the code that generated the event and the Event Handler
know what the parameters are.
To generate a new event one creates a new Event Object with say one of
CreateEventAtTopOfList - Would be used if immediate execution is needed
CreateEventAtBottomOfList - Execute when you have time
CreateEventInMiddleOfList - Insert in execution list, location dependent
on Event Priority
> 2) We have to be careful about race conditions in event notification
> latency and order.
This sequential execution of the Event Objects should reduce the chance
of race conditions but will mean that the Event Handlers will need to
execute expeditiously so as not to hold up the Event handling system.
Other code could sit on the sidelines keeping track of the event list to
make sure nothing is going wrong.
> 3) Finally, we have to keep in mind that this is a small-form factor,
> battery-powered system - we'll always be behind on the power/resource
> curve from our desktops, so we have to be aware of speed and
I couldn't agree more. I have seen a number of engineering projects fail
due to overcomplexity and inattention to low level design resulting in
unacceptably slow response and too much power consumption.
If anyone thinks this is a good idea i will flesh it out more in the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the community