[En-Nut-Discussion] Re: AW: AW: Ethernut Docu Improvements

[Ralph Mason]

Oliver Schulz wrote:

>Hi Ralph,
>
>I had a look to your code yesterday evening and started to implement your features to Nut/OS. 
>
>In my opinion it is a smarter way to add exactly one message queue to each thread (directly in NUTTHREADINFO). So every thread has its own message queue and there is no need to define some global message queues.
>In my first implementation the memory for the message queue is allocated just in time. Means, if a thread doesn't use the message queue, only the space for one pointer (2bytes) is wasted.
>  
>
What if you want more than one que per thread?   Is there good reason to 
impose an arbitrary limit? 

My implementation doesn't use any memory if you don't use any message 
ques.  Also the developer knows what que size they require so allocating 
a que doesn't seem like a hardship to me.   And it seems its generaly a 
one que to 3-5 threads average runs in my code.

I built it with a few requirements in mind.

1. IPC separate tasks need to be able to tell other tasks of an event.  
Eg a keyboard handler tells a ui thread about key presses

2. Brodcast events (eg a powerdown message)

3. So a thread could wait on multiple events (I thought for a long time 
about implementing a wait on multiple events, but it alway seemed too 
much overhead), with Kill thread if you want to wait on 3 events you can 
spawn three threads that just wait on an event and post to a que when 
they get that event then kill themselves.

4. Support for heirachial state machines (see www.quantum-leaps.com), 
this is why timers and oneshots are important.

>Today I got your new versions of the files. These message timers are also very interessing, but on >the first look, it seems that your implementation is very complicated.

I think timers like these are pretty useful in NutOS.  They serailze timers into the thread model.  I don't think there is much complication there.  This is a feature of the que I use alot.


>ut anyway, after the next official release of Nut/OS 3.4 (which must come today, I think), I would like to work with you together about this topic. This weekend I commit my files into CVS and we can discuss about it... 
>

Sounds like a plan.  Attached is a cleaned up version with documentation 
(a little) and Nutized function names.

When I changed the function names I updated one of our applications  
(about 100k of code) , it is a very very well used bit of code in that app.

Ralph


-------------- next part --------------
A non-text attachment was scrubbed...
Name: messageq.zip
Type: application/octet-stream
Size: 2909 bytes
Desc: not available
URL: <http://lists.egnite.de/pipermail/en-nut-discussion/attachments/20040131/2fff1f27/attachment-0001.obj>