<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.14.3">
</HEAD>
<BODY>
Hi,<BR>
<BR>
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.<BR>
<BR>
On Sat, 2007-07-21 at 12:28 -0400, Clayton Jones wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
<FONT COLOR="#000000">I like the ideas presented here, but i have some experience designing</FONT><BR>
<FONT COLOR="#000000">& building real time & embedded systems so some points to think about:</FONT><BR>
</BLOCKQUOTE>
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
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">1) The Event Router should also have some sort of priority mechanism</FONT> ...
</PRE>
</BLOCKQUOTE>
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 Event Handler. <BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
To generate a new event one creates a new Event Object with say one of three functions<BR>
CreateEventAtTopOfList - Would be used if immediate execution is needed<BR>
CreateEventAtBottomOfList - Execute when you have time<BR>
CreateEventInMiddleOfList - Insert in execution list, location dependent on Event Priority<BR>
<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">2) We have to be careful about race conditions in event notification</FONT>
<FONT COLOR="#000000">latency and order.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
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.<BR>
<BR>
Other code could sit on the sidelines keeping track of the event list to make sure nothing is going wrong.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">3) Finally, we have to keep in mind that this is a small-form factor,</FONT>
<FONT COLOR="#000000">battery-powered system - we'll always be behind on the power/resource</FONT>
<FONT COLOR="#000000">curve from our desktops, so we have to be aware of speed and</FONT>
<FONT COLOR="#000000">resources.</FONT>
</PRE>
</BLOCKQUOTE>
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.<BR>
<BR>
If anyone thinks this is a good idea i will flesh it out more in the wiki.<BR>
<BR>
Regards<BR>
Simon Matthews<BR>
<BR>
</BODY>
</HTML>