Has this wheel already been invented?

"Michael R. Kesti" <michaelkesti@nospam.net> skrev i meddelandet 
news:47411A28.48133D0F@nospam.net...
> Grant Edwards wrote:
>
> <snip>
>
>>Premptive multitasking has a fatal flaw, especially for small
>>systems: it requires a seperate stack for each task (at least
>>that's how it's always done).  If you've got 10 tasks to run
>>and only 256 bytes of RAM, then suddenly you've got stack
>>overflows.
>
> I suppose, but attempting to execute 10 tasks on a system with only
> 256 bytes of RAM is certainly a fatally flawed design!
>
>

So if you take two programs, and one using pre-emptive multitasking
with 10 tasks in a 64 kB Flash and 16 kB SRAM chip (to get the SRAM) and the
other uses 10 tasks in a cooperative environment, and 4 kFlash and 256 byte 
SRAM,
then the second design is flawed?

I have seen a number of multitasking designs in 4 kB of flash
and the multitasking makes things much easier to program and maintain.

Since power consumption is an issue, you do not want to waste time
on a round robin scheduler.
-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

On Fri, 16 Nov 2007 22:31:06 -0600, Jack Klein <jackklein@spamcop.net>
wrote:

>There are all sorts of preemptive kernels, RTOS's, frameworks, out
>there, open source and commercial.  There are priority-driven
>preemptive systems, time-sliced preemptive systems, and others.
...
>What I need, and I am planning to develop, is a cooperative task
>scheduler to replace the super loop.  Inter task communication, and
>ISR to task communication, will go through a kernel to set event
>flags, timer flags, put messages in queues, etc., and the kernel will
>track which tasks are actually ready because they have pending events.
>
>After any task returns, the scheduler will execute the highest
>priority ready task.

We've been doing it this way for many, many years. We don't use a
priority scheme. The applications include safety-critical medical
equipment and bomb-disposal machinery.

Send me an email address, and I'll ship you a manual. I should
warn you that it's all written in Forth ... because it works.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

On 2007-11-19, Michael R. Kesti <michaelkesti@nospam.net> wrote:
> Grant Edwards wrote:
>
><snip>
>
>>Premptive multitasking has a fatal flaw, especially for small
>>systems: it requires a seperate stack for each task (at least
>>that's how it's always done).  If you've got 10 tasks to run
>>and only 256 bytes of RAM, then suddenly you've got stack
>>overflows.
>
> I suppose, but attempting to execute 10 tasks on a system with only
> 256 bytes of RAM is certainly a fatally flawed design!

Why?

If 256 bytes is enough to run 10 tasks cooperatively, and
you've got 10 independent things to do, then why is doing so a
fatally flawed design?  For some of the cooperative tasking
examples (like protothreads, which does stack unwinding), the
per-thread overhead is only 2-4 bytes. If there are 10
logically independent things going on, why not write it as 10
threads?

-- 
Grant Edwards                   grante             Yow! I feel like I am
                                  at               sharing a ``CORN-DOG''
                               visi.com            with NIKITA KHRUSCHEV ...

Grant Edwards wrote:

>On 2007-11-19, Michael R. Kesti <michaelkesti@nospam.net> wrote:
>> Grant Edwards wrote:
>>
>><snip>
>>
>>>Premptive multitasking has a fatal flaw, especially for small
>>>systems: it requires a seperate stack for each task (at least
>>>that's how it's always done).  If you've got 10 tasks to run
>>>and only 256 bytes of RAM, then suddenly you've got stack
>>>overflows.
>>
>> I suppose, but attempting to execute 10 tasks on a system with only
>> 256 bytes of RAM is certainly a fatally flawed design!
>
>Why?

Because, as you said, stacks will overflow.

>If 256 bytes is enough to run 10 tasks cooperatively, and
>you've got 10 independent things to do, then why is doing so a
>fatally flawed design?  For some of the cooperative tasking
>examples (like protothreads, which does stack unwinding), the
>per-thread overhead is only 2-4 bytes. If there are 10
>logically independent things going on, why not write it as 10
>threads?

Perhaps it would have been more clear if I had said, "Attempting
to execute 10 tasks on a premptive multitasking system with only
256 bytes of RAM is certainly a fatally flawed design!"  I must
have thought that this would be clear from the context of the
discussion.

-- 
========================================================================
          Michael Kesti            |  "And like, one and one don't make
                                   |   two, one and one make one."
    mrkesti at hotmail dot com     |          - The Who, Bargain

In article <47417143.434778421@192.168.0.50>, Stephen Pelc says...
> Send me an email address, and I'll ship you a manual. I should
> warn you that it's all written in Forth ... because it works.

You wrote the manual in Forth? Oh, my poor aching head :)

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

On Nov 18, 11:49 pm, Grant Edwards <gra...@visi.com> wrote:
> On 2007-11-19, Ed Prochak <edproc...@gmail.com> wrote:
>
> > If the system is cooperative, why would there be a  priority scheme?
>
> So when the running task yields, the next one to run is the one
> with the highest priority.
>
> > Cooperative multasking has a fatal flaw, especially for real-time
> > systems. And the flaw is that every task must be aware of the time
> > constraints of the others. IOW, you make what seems to be a simple
> > programming change in task99 and suddenly task100 starts failing to
> > meet its deadline intermittently. This isn't a failure of the
> > superloop, but of the whole cooperative multasking model.
>
> > You might want to check some OS theory before starting your
> > development.
>
> Premptive multitasking has a fatal flaw, especially for small
> systems: it requires a seperate stack for each task (at least
> that's how it's always done).  If you've got 10 tasks to run
> and only 256 bytes of RAM, then suddenly you've got stack
> overflows.
>
> --
> Grant Edwards                   grante             Yow!  Yow! Is my fallout
>                                   at               shelter termite proof?
>                                visi.com

Are you saying a preemptive kernel could not be designed for such a
system? (Hmm. This sounds challenging.  What hardware do you have in
mind? It could be fun to get into a small system again.)

In a system that small, I'd be a little surprised to have that many
independent tasks. But I'd also likely go to a single do-all state
machine implementation. I did not say Preemptive kernels would be good
for all systems, especially on that small a system.

With the price of hardware has low as it is today, what kind of
systems still have these constraints? (Not rhetorical)
  Ed

On Nov 19, 10:31 am, Grant Edwards <gra...@visi.com> wrote:
> On 2007-11-19, Michael R. Kesti <michaelke...@nospam.net> wrote:
>
> > Grant Edwards wrote:
>
> ><snip>
>
> >>Premptive multitasking has a fatal flaw, especially for small
> >>systems: it requires a seperate stack for each task (at least
> >>that's how it's always done).  If you've got 10 tasks to run
> >>and only 256 bytes of RAM, then suddenly you've got stack
> >>overflows.
>
> > I suppose, but attempting to execute 10 tasks on a system with only
> > 256 bytes of RAM is certainly a fatally flawed design!
>
> Why?
>
> If 256 bytes is enough to run 10 tasks cooperatively, and
> you've got 10 independent things to do, then why is doing so a
> fatally flawed design?  For some of the cooperative tasking
> examples (like protothreads, which does stack unwinding), the
> per-thread overhead is only 2-4 bytes. If there are 10
> logically independent things going on, why not write it as 10
> threads?
>
> --
> Grant Edwards                   grante             Yow! I feel like I am
>                                   at               sharing a ``CORN-DOG''
>                                visi.com            with NIKITA KHRUSCHEV ...


Can you give me an example of a modern embedded system you know of
that was
1. price constrained enough to be stuck with only 256bytes RAM.
2. complex enough to need 10 independent tasks

No need to expose proprietary information, but I really would like to
know.

   Ed

On 2007-11-20, Ed Prochak <edprochak@gmail.com> wrote:

> Are you saying a preemptive kernel could not be designed for
> such a system?

It depends on the threading semantics that you want.

> (Hmm. This sounds challenging.  What hardware do you have in
> mind? It could be fun to get into a small system again.)

There are dozens of small processors in families like the
MSP430 that have a few KB of code space and a few hundred bytes
of RAM.

> In a system that small, I'd be a little surprised to have that many
> independent tasks.

10 would be a bit unusual.  3-4 is pretty typical.

> But I'd also likely go to a single do-all state
> machine implementation.

Those are buger-all hard to design, test, and maintain.

> With the price of hardware has low as it is today, what kind of
> systems still have these constraints? (Not rhetorical)

MSP430F20xx, AVR ATtinyxx, etc.

-- 
Grant Edwards                   grante             Yow!  I'm having
                                  at               a tax-deductible
                               visi.com            experience! I need an
                                                   energy crunch!!

On 2007-11-20, Ed Prochak <edprochak@gmail.com> wrote:

>> If 256 bytes is enough to run 10 tasks cooperatively, and
>> you've got 10 independent things to do, then why is doing so a
>> fatally flawed design?  For some of the cooperative tasking
>> examples (like protothreads, which does stack unwinding), the
>> per-thread overhead is only 2-4 bytes. If there are 10
>> logically independent things going on, why not write it as 10
>> threads?
>
> Can you give me an example of a modern embedded system you know of
> that was
>
> 1. price constrained enough to be stuck with only 256bytes RAM.

The ones I work on are board-space constrained and
power-constrained.

> 2. complex enough to need 10 independent tasks

10 was just a hypothetical case. 3-5 is probaby more typical.

> No need to expose proprietary information, but I really would
> like to know.

Battery-operated sensors is one application I'm familiar with.

-- 
Grant Edwards                   grante             Yow!  Yes, Private
                                  at               DOBERMAN!!
                               visi.com            

"Ed Prochak" <edprochak@gmail.com> wrote in message 
news:41808365-59d3-4fe2-ac77-98e726e2a164@b15g2000hsa.googlegroups.com...
>
> If the system is cooperative, why would there be a  priority scheme?

Slightly different use of the term "priority" - here, I mean "more 
time-critical than other tasks". E.g. I may need to check a serial port 
more often than I update the screen.

> Cooperative multasking has a fatal flaw, especially for real-time
> systems. And the flaw is that every task must be aware of the time
> constraints of the others. IOW, you make what seems to be a simple
> programming change in task99 and suddenly task100 starts failing to
> meet its deadline intermittently. This isn't a failure of the
> superloop, but of the whole cooperative multasking model.

Nah. This is basic stuff. For instance in the above, taking what I wrote 
entirely literally could mean that continuous serial port data would 
result in no screen activity. This is easily worked around - either by 
ensuring that the serial port task skips a beat once in a while, or by 
simply observing that serial ports tend to be slow ;).

> You might want to check some OS theory before starting your
> development.

Sure; it's always good to do some research. But also remember the KISS 
principle.

Steve
http://www.fivetrees.com