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

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:
> 
> 
> 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 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:
> 
> 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. A system clock timer,
typically 10 or 20mS, looks at all the task tick counters and priority
is established by running a given task once every n clock ticks. The
tick counter runs at interrupt level, while the mainline code just calls
task functions based on the state set at interrupt level. Control
functions include create, suspend resume, delete etc and priority can be
set dynamically while a task is running. Typically, a messaging task is
written as a simple state machine, doing nothing while waiting, then
splitting the remainder of the work into one or more states, depending
on the complexity of the task. For example, a task that rotates a dial
pointer on a graphics screen to a new value updates one count per task
iteration, then exits to allow other tasks access, rather than do the
whole update at once.   

Compared to a fully blown rtos, it's very primitive, but similar
techniques would be applicable to many non time critical projects. Even
for small systems, the need to think of system design in a task oriented
way imposes quite a bit of order on the design process, which is no bad
thing...

Chris


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

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~

Dave <dave@comteck.com> writes:

> 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?

I was wondering that too... You could use any number of shared
variables, limited only by the desire to reduce dependencies.


-- 

John Devereux

dick wrote:
> 
> I treat the ucos as a example to learn RTOS.  I would like to  build
> one from scratch.
> no matter how easy to port a existing os to a new platform, we have to
> hire a low level person, right? while let him/her idle?just keep
> him/her busy.
> 

If the op just needs update rates in the fraction of a second range for
simple application, then an rtos is most likely overkill, unless you are
looking for an excuse and have the project time to get familiar with
someone elses code base. It's much quicker and fairly trivial to write a
simple round robin scheduler entirely in C. 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. Message queues are optional.
Each task then typically becomes a simple state machine, where if there
is no message, the function exits, though tasks don't have to use
messaging. The advantage is almost zero overhead, small footprint, no
need to work out stack space for each task and a simple framework to get
results fast. Such an approach may not have all the bells and whistles
of an rtos, nor be quite so glamorous, but it gets the job done and can
be inherently deterministic. Total code for the scheduler should not be
more than 2 or 3 pages of C using such an approach...

Chris


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

I treat the ucos as a example to learn RTOS.  I would like to  build
one from scratch.
no matter how easy to port a existing os to a new platform, we have to
hire a low level person, right? while let him/her idle?just keep
him/her busy.


Darin Johnson wrote:
> dick wrote:
> > what we need is a job dispatcher and an inter task synchronous
> > mechanism.
> > It is easy to build one from scratch.
>
> But this is essentially what uC/OS II does.  It's a very
> tiny system, with only a couple source files as I
> remember, and then the customer supplies a few processor
> specific routines (context switching and interrupt
> control).
>
> So you could pay the tiny license fee and spend the
> engineer's time porting it to your system, or you could
> write your own from scratch.  It's not a hard job, but it
> will definately take longer than to port uC/OS.  Unless
> you've already got your own OS from a prior product.
> 
> --
> Darin Johnson

dick wrote:
> what we need is a job dispatcher and an inter task synchronous
> mechanism.
> It is easy to build one from scratch.

But this is essentially what uC/OS II does.  It's a very
tiny system, with only a couple source files as I
remember, and then the customer supplies a few processor
specific routines (context switching and interrupt
control).

So you could pay the tiny license fee and spend the
engineer's time porting it to your system, or you could
write your own from scratch.  It's not a hard job, but it
will definately take longer than to port uC/OS.  Unless
you've already got your own OS from a prior product.

--
Darin Johnson