Rtos Design

Hi folk,
       We were designing an RTOS for a general 8 bit microcontroller. 
We have designed a round robin schedular.

But i have question about the stack on 8051.

My doubt is, we have our kernel (data, code) and also applications
(data and code)

Now we need to allocate seperate memory areas for the kernel and the
application. How do we take care of the security in 8051.

And also how do we give the stack area for each task in the
application.
Is if a good idea to give around 40 bytes for each task (IDATA
memory). And when a new task is scheduled, save the current task 40
bytes in external memory and reload the new tasks 40 bytes from
external memory to IDATA. Somehow i dont like this idea, but are there
any other ways to save the context of a task.

Also how to achieve atomic operations in 8051.. (disable interrupts
????)

thanks 

pachu

pachu wrote:

>        We were designing an RTOS for a general 8 bit microcontroller. 
> We have designed a round robin schedular.
> 
> But i have question about the stack on 8051.
> 
> My doubt is, we have our kernel (data, code) and also applications
> (data and code)
> 
> Now we need to allocate seperate memory areas for the kernel and the
> application. How do we take care of the security in 8051.

What do you want to secure?  An 8051 has no memory protection or memory 
mapping, although some enhanced models may have something like this. 
The 8051 is a bad choice for an RTOS, in my opinion, although Pumpkin, 
Inc. implements the Salvo OS on the 8051.  I believe it is a cooperative 
scheduler.

> And also how do we give the stack area for each task in the
> application.
> Is if a good idea to give around 40 bytes for each task (IDATA
> memory). And when a new task is scheduled, save the current task 40
> bytes in external memory and reload the new tasks 40 bytes from
> external memory to IDATA. Somehow i dont like this idea, but are there
> any other ways to save the context of a task.

That's the basic problem with multi-tasking an 8051: the stack is in a 
small memory area.  Yes, you would need to swap out the stack area to 
XDATA, which would become a large part of the task switching overhead.

> Also how to achieve atomic operations in 8051.. (disable interrupts
> ????)

Disabling interrupts is the easiest way and works for very short 
sections of code.  You can implement semaphores, etc., for longer 
periods of exclusive access.

Thad

>Now we need to allocate seperate memory areas for the kernel and the
>application. How do we take care of the security in 8051.

There is no security on the 8051 as there is on desktop and larger systems. The
8051 has no separate User Mode that limits applications from executing
instructions that could cause security problems. There is no memory management
unit to protect kernel memory from applications. There really is no User Mode,
only Kernel Mode.

>And when a new task is scheduled, save the current task 40
>bytes in external memory and reload the new tasks 40 bytes from
>external memory to IDATA. Somehow i dont like this idea, but are there
>any other ways to save the context of a task.

The sane way is to just have a fixed number of tasks and allocate the stacks in
available RAM. Moving the stack back and forth from external memory is
certainly feasible but in the world of 8-bit microcontrollers, you really
should set limits. You might spend so much time moving tasks in and out of
external memory that you wind up doing little real work and missing those Real
Time events that the RTOS is trying to keep track of.

>Also how to achieve atomic operations in 8051.. (disable interrupts?)

Yes. Disable them for as short a time as possible.

> pachu wrote:
> 
>>        We were designing an RTOS for a general 8 bit microcontroller. 
>> We have designed a round robin schedular.
>>
>> But i have question about the stack on 8051.
>>
>> My doubt is, we have our kernel (data, code) and also applications
>> (data and code)
>>
>> Now we need to allocate seperate memory areas for the kernel and the
>> application. How do we take care of the security in 8051.
> 
>> And also how do we give the stack area for each task in the
>> application.
>> Is if a good idea to give around 40 bytes for each task (IDATA
>> memory). And when a new task is scheduled, save the current task 40
>> bytes in external memory and reload the new tasks 40 bytes from
>> external memory to IDATA. Somehow i dont like this idea, but are there
>> any other ways to save the context of a task.
> 
>> Also how to achieve atomic operations in 8051.. (disable interrupts
>> ????)
> 

Here is a completely different viewpoint.  An 8051 is so short of 
resources that creating a general purpose RTOS for it is bound to 
result in serious compromises.  With processors such as these, where 
real time operations are required, in most cases the application is 
relatively simple/understood so it is preferable to code the 
application directly, using RTOS principles, rather than employ a 
ready made general purpose RTOS.

Ian

In article <c985418f.0409040742.58fe3a0d@posting.google.com>, pachu_um@hotmail.com (pachu) wrote:
>Hi folk,
>       We were designing an RTOS for a general 8 bit microcontroller. 
>We have designed a round robin schedular.

There are a bunch of 8051 RTOSes already being sold. Why not purchase one of 
those?

> Hi folk,
>        We were designing an RTOS for a general 8 bit microcontroller. 
> We have designed a round robin schedular.

Source code for 8051 RTOS here.  Why not use this?

http://www.FreeRTOS.org

Why use RTOS on 8051?

On 4 Sep 2004 08:42:36 -0700, pachu_um@hotmail.com (pachu) wrote:

>Hi folk,
>       We were designing an RTOS for a general 8 bit microcontroller. 
>We have designed a round robin schedular.
>
>But i have question about the stack on 8051.
>
>My doubt is, we have our kernel (data, code) and also applications
>(data and code)
>
>Now we need to allocate seperate memory areas for the kernel and the
>application. How do we take care of the security in 8051.
>
>And also how do we give the stack area for each task in the
>application.
>Is if a good idea to give around 40 bytes for each task (IDATA
>memory). And when a new task is scheduled, save the current task 40
>bytes in external memory and reload the new tasks 40 bytes from
>external memory to IDATA. Somehow i dont like this idea, but are there
>any other ways to save the context of a task.
>
>Also how to achieve atomic operations in 8051.. (disable interrupts
>????)

Given the limited resources of an 8051, I would think that 40 bytes
per task stack is a bit generous. Perhaps stack profiling should be
performed to get a more precise idea of individual task stack usage.
You could probably do a lot of this evaluation using a simulator.

Atomic operations? --- with a micro like this you can't help but keep
it simple. Disabling interrupts may be one way, but also enforcing
restrictive interfaces to global variables.

With low-end micros, one has to weigh up the cost benefit of using a
RTOS (or simple scheduler) against the depth of functionality. 

Ken.

+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

Thad Smith <thad@ionsky.com> wrote in message news:<4139ef82$1_2@omega.dimensional.com>...
> pachu wrote:
> 
> >        We were designing an RTOS for a general 8 bit microcontroller. 
> > We have designed a round robin schedular.
> > 
> > But i have question about the stack on 8051.
> > 
> > My doubt is, we have our kernel (data, code) and also applications
> > (data and code)
> > 
> > Now we need to allocate seperate memory areas for the kernel and the
> > application. How do we take care of the security in 8051.
> 
> What do you want to secure?  An 8051 has no memory protection or memory 
> mapping, although some enhanced models may have something like this. 
> The 8051 is a bad choice for an RTOS, in my opinion, although Pumpkin, 
> Inc. implements the Salvo OS on the 8051.  I believe it is a cooperative 
> scheduler.
> 

No the algorithm for the schedular is not an issue right
now(cooperative or round robin or priority).......the problem is,
allocating the stack area for each task.

How do we go about allocating the stack for each task....say we have a
very few tasks running, say 4 or max 6. how do we allocate the stack
for  each task.

Now the kernel needs to have some space to run, and the tasks
too....how to see that only the tasks stack is swaped out/in  to/from
an external memory.

We are stuck with reentrant functions stack too.....keil says it
allocates seperate stack for reentrant functions and variable length
arguments.

How do we go about this. 

> > And also how do we give the stack area for each task in the
> > application.
> > Is if a good idea to give around 40 bytes for each task (IDATA
> > memory). And when a new task is scheduled, save the current task 40
> > bytes in external memory and reload the new tasks 40 bytes from
> > external memory to IDATA. Somehow i dont like this idea, but are there
> > any other ways to save the context of a task.
> 
> That's the basic problem with multi-tasking an 8051: the stack is in a 
> small memory area.  Yes, you would need to swap out the stack area to 
> XDATA, which would become a large part of the task switching overhead.
> 
> > Also how to achieve atomic operations in 8051.. (disable interrupts
> > ????)
> 
> Disabling interrupts is the easiest way and works for very short 
> sections of code.  You can implement semaphores, etc., for longer 
> periods of exclusive access.
> 
> Thad

pachu <pachu_um@hotmail.com> wrote:
> Hi folk,
>        We were designing an RTOS for a general 8 bit microcontroller. 

And you're sure you know what you're doing?  To be perfectly frank,
that doesn't really appear to be the case.

[...]

> Now we need to allocate seperate memory areas for the kernel and the
> application. 

Not for a multi-tasking system suitable for this kind of processor,
you don't.

> How do we take care of the security in 8051.

You don't.  This is strictly a "people entering here will be assumed
to know what they're doing" field of work.  Security is taken care of
by writing the code carefully, not by some magic trickery performed by
the hardware.

Michael J. Pont's book "Patterns for Time-Triggered Embedded Systems"
might prove helpful to rid of some of your ill-founded assumptions.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

pachu <pachu_um@hotmail.com> wrote:

> No the algorithm for the schedular is not an issue right
> now(cooperative or round robin or priority).......the problem is,
> allocating the stack area for each task.

You have no idea.  The type of scheduler very much is the issue here,
because if you chose the appropriate clase of scheduling method for
this target platform, you wouldn't need any per-task stacks to begin
with.

The need for stack switching is a property of pre-emptive scheduling,
which simply isn't an appropriate scheduling technique for a classic
8051.

You can do it on some extended variants, though.  E.g. I'm working on
the DS80C390, whose 1KiB "internal XRAM" can be set up as 4
independent stacks quite nicely, each of them still being larger than
a classic 8051's stack.  But then, a '390 in 24 bit contiguous mode is
far from what people will think of hearing you speak of just "8051",
without further specification, so it's actually outside the stated
scope of your RTOS design.

And since you mentioned Keil tools already: even setting aside whether
an RTOS is a useful idea on an 8051 to begin with, it evades me why
would want to design your own RTOS instead of using existing ones,
including Keil's own RTX51.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.