uCOS-II

John B wrote:
> ziggy scrobe on the papyrus:
>
> > I may be late to this party, but was wondering if uCOS is still free?
> > Read about it on the rabbit pages, and also was reading about it
> > being open, but after going to the 'main site' to get more details
> > before i go out and buy the book, it only looks commercial now.
> >
> > If it is now a commercial product, any one have recommendations for a
> > really small free RTkernel that would mate well to a z80 and rabbit
> > 2000?  ( perhaps even a 8051, but i know thats a stretch due to the
> > radically different architecture ).
> >
> > The 'target' will be doing simple monitoring of sensors and changing
> > of remote parameters from a serial port based human interface ( i.e.,
> > palm pilot ) so i dont need anything fancy, but didn't want to 'do it
> > myself'.
>
> Have a look here:
>
>  http://www.pumpkininc.com/
>
> Salvo is free, but it seems to work on just about everything except the
> Rabbit.
>
> --
> John B

Actually Salvo is a commercial product. You can try a limited version
for free, but once you produce a product the license fees kick in.

If you like the cooperative task switching approach Salvo uses and
don't need all the bells and whistles, take a look at csRtos
(www.circuitcellar.com/avr2004/DA3650.html). Cooperative task switching
means you are responsible for task latency, but you don't need seperate
stack space for each task. That's helpful on a micro with very little
RAM.

csRtos is freeware. There are currently versions available for Atmel
AVRs and Microchip PICs. If you're interested in porting it to the
8051, and your C compiler supports setjmp and longjmp I have a version
that should be pretty simple to convert.

Mark

"ziggy" <ziggy@fakedaddress.com> wrote in message 
news:ziggy-A94856.16052709072006@news.isp.giganews.com...
> In article <4hd4vnF1qlk4eU1@individual.net>,
> "tim \(back at home\)" <tim_back_home2006@yahoo.co.uk> wrote:
>
>> "ziggy" <ziggy@fakedaddress.com> wrote in message
>> news:ziggy-30EA58.15121009072006@news.isp.giganews.com...
>> >I may be late to this party, but was wondering if uCOS is still free?
>>
>> Only for personal use.
>>
>> There's a fee for commercial use, but it isn't
>> particularly large.
>>
>> tim
>>
>> -
>> > Read about it on the rabbit pages, and also was reading about it being
>> > open, but after going to the 'main site' to get more details before i 
>> > go
>> > out and buy the book, it only looks commercial now.
>> >
>> > If it is now a commercial product, any one have recommendations for a
>> > really small free RTkernel that would mate well to a z80 and rabbit
>> > 2000?  ( perhaps even a 8051, but i know thats a stretch due to the
>> > radically different architecture ).
>> >
>> > The 'target' will be doing simple monitoring of sensors and changing of
>> > remote parameters from a serial port based human interface ( i.e., palm
>> > pilot ) so i dont need anything fancy, but didn't want to 'do it 
>> > myself'.
>
> If this ever became a commercial product the fee wouldn't be a problem
> as it would just be passed to the customer.  How do you 'register' to
> get the nocomm copy? or do i just need to go buy the book?  I guess 40
> bucks isnt much to waste if i don't like his code...

I haven't checked back to the mucos site recentley but last
time I did it was an honesty system, just like it is with any
source code supplied OS that sells via "license per product".

Once you have the source, there's nothing to stop you using
the code for.a  product that isn't the originally registered one.

But (genrally) a corporate isn't going to do this, the amount
of money is too small in relation to the total development
spend to take the risk of being caught.   Note that you often
don't have to pay until you are some way into the development,
so it is possible (and legal) to use OS <whatever> on a trial
basis at no cost (other than the engineer's learning curve that is)
until you have a product you are sure you want to ship

tim

Greetings,

FreeRTOS.org can provide you with a very small OS. I have managed to
boil it down to less than 3K5 using GCC 4.1.1 and an ARM7 uC.

/RaceMouse

ziggy wrote:
> I may be late to this party, but was wondering if uCOS is still free? 
> Read about it on the rabbit pages, and also was reading about it being 
> open, but after going to the 'main site' to get more details before i go 
> out and buy the book, it only looks commercial now.
> 
> If it is now a commercial product, any one have recommendations for a 
> really small free RTkernel that would mate well to a z80 and rabbit 
> 2000?  ( perhaps even a 8051, but i know thats a stretch due to the 
> radically different architecture ).
> 
> The 'target' will be doing simple monitoring of sensors and changing of 
> remote parameters from a serial port based human interface ( i.e., palm 
> pilot ) so i dont need anything fancy, but didn't want to 'do it myself'.

I do not think I really need a RTOS. a full blown OS will just wast
your time to get familiar with it.

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

usually the engineering manager do not understand the low level
programming and want to find a commercial RTOS.



ziggy wrote:
> I may be late to this party, but was wondering if uCOS is still free?
> Read about it on the rabbit pages, and also was reading about it being
> open, but after going to the 'main site' to get more details before i go
> out and buy the book, it only looks commercial now.
>
> If it is now a commercial product, any one have recommendations for a
> really small free RTkernel that would mate well to a z80 and rabbit
> 2000?  ( perhaps even a 8051, but i know thats a stretch due to the
> radically different architecture ).
>
> The 'target' will be doing simple monitoring of sensors and changing of
> remote parameters from a serial port based human interface ( i.e., palm
> pilot ) so i dont need anything fancy, but didn't want to 'do it myself'.

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

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

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

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