uCOS-II

On Thu, 13 Jul 2006 22:06:01 +0000, Chris Quayle wrote:

> Dave wrote:
>> 
>> On Thu, 13 Jul 2006 13:13:56 +0000, Chris Quayle wrote:
>> 
>> > Each function or task is
>> > called every n clock ticks to set priority and always runs to
>> > completion. Message based comms with handshake using a single castable
>> > U32 are used to move data between tasks.
>> 
>> Since tasks run to completion, why a single castable U32?  Why not a
>> structure since there should be no coherency issues?
>> 
>>     ~Dave~
> 
> Not quite sure what you mean - Each task has a structure declared within
> the task module that contains control info, entries for Tx and Tx
> message information and current state. It includes a U32 entry for each
> of the send and receive messages - a simple way to get data of any type
> between tasks and has been used to my knowledge on more than one
> commercial real time os - AMX I think was one. 

Why does the message between tasks have to be a U32?  Since the tasks run
to completion, there should be no coherency issues in making the message
three U32s, two floats, and a character string, or any other combination
of types.  And why "castable"?  Surely the two tasks can agree on what the
type of the data contained within the message is?


    ~Dave~

Dave wrote:
> 
> 
> Why does the message between tasks have to be a U32?  Since the tasks run
> to completion, there should be no coherency issues in making the message
> three U32s, two floats, and a character string, or any other combination
> of types.  And why "castable"?  Surely the two tasks can agree on what the
> type of the data contained within the message is?
> 
>     ~Dave~

I doesn't need to be a U32, but it does need to be large enough to
contain any object that you might want to send in a message. As we don't
do 64 bit, a U32 is large enough to contain a pointer, which typically
is what gets passed in a message. I guess a void * would be more
correct, or a union of types, but that's the way it was written. Note
that there are no globals - all data gets around the system via
messaging. As you point out, tasks are written agreeing message
contents. Also, sending tasks block after sending a message until an ack
is received from the destination, so there are no synchronisation
issues. 

To get back on track, I guess the point i'm trying to make is that many
designs can benefit from rtos functionality, but not all the baggage
that comes with a standard rtos. A sort of lightweight middle ground. If
you are working on small systems that need no more than fractions of a
second response time, an rtos with a 10uS context switch time might just
be overkill...

Chris 

-- 
Greenfield Designs Ltd
-----------------------------------------------------------
Embedded Systems & Electronics: Research Design Development
Oxford. England. (44) 1865 750 681

On Fri, 14 Jul 2006 09:26:10 +0000, Chris Quayle wrote:

> I doesn't need to be a U32, but it does need to be large enough to
> contain any object that you might want to send in a message. As we don't
> do 64 bit, a U32 is large enough to contain a pointer, which typically
> is what gets passed in a message. I guess a void * would be more
> correct, or a union of types, but that's the way it was written. Note
> that there are no globals - all data gets around the system via
> messaging. As you point out, tasks are written agreeing message
> contents. Also, sending tasks block after sending a message until an ack
> is received from the destination, so there are no synchronisation
> issues. 

Okay, we're synched.  Ack.    ;-)


    ~Dave~

Dave wrote:
> 
> On Fri, 14 Jul 2006 09:26:10 +0000, Chris Quayle wrote:
> 
> > I doesn't need to be a U32, but it does need to be large enough to
> > contain any object that you might want to send in a message. As we don't
> > do 64 bit, a U32 is large enough to contain a pointer, which typically
> > is what gets passed in a message. I guess a void * would be more
> > correct, or a union of types, but that's the way it was written. Note
> > that there are no globals - all data gets around the system via
> > messaging. As you point out, tasks are written agreeing message
> > contents. Also, sending tasks block after sending a message until an ack
> > is received from the destination, so there are no synchronisation
> > issues.
> 
> Okay, we're synched.  Ack.    ;-)
> 
>     ~Dave~


Right - I always thought the messaging ipc model was the most elegant
:-).

If you are planning to roll your own, Doug Comer's Xinu book is a
classic introduction. Quite old, (~1984) but the sources can still be
found on the web...

Chris


-- 
Greenfield Designs Ltd
-----------------------------------------------------------
Embedded Systems & Electronics: Research Design Development
Oxford. England. (44) 1865 750 681