Has this wheel already been invented?

"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
news:fhrj5c$mfo$2@aioe.org...
>
> Since power consumption is an issue, you do not want to waste time
> on a round robin scheduler.

!!!!

What a strange thing to say.

A preemptive multitasker has *far* more baggage than a roundrobin. All 
that task-saving and restoring...

Steve
http://www.fivetrees.com 

"Ed Prochak" <edprochak@gmail.com> wrote in message 
news:b139d63c-0b45-49dc-aed4-17f3248fad28@o6g2000hsd.googlegroups.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.)

My response to that is not that it can't be done; more than cooperative 
is actually a better way to design (unless it's a multi-user 
programmable system, or, as another poster has noted, the dynamics of 
the team make the programming partitioning simpler and the entire team 
can't be depended on maintain the kind of discipline needed to make 
cooperative work properly).

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

I'm a *huge* fan of state machines in such cases. And - it also depends 
what you mean by "tasks". There are *always* multiple tasks: maintain 
the serial port, maintain time, maintain the LCD, maintain the keypad 
etc etc... By "better" above I mean that handling these synchronously 
means you avoid all sorts of asynchronous nonsense that is the bane of 
all preemptive OSs. The system is more robust, reliable, and bugs (can 
be) far fewer. (Digital hardware engineers will tell you in great detail 
why synchronous design is the only way to fly ;).)

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

Plenty. I've worked on control/measurement instrumentation products 
where, even these days, we have to make everything fit in 256 bytes 
(including the stack). And yes, we're working to a tight budget, as 
these are high-volume products where a difference in the CPU cost of a 
few pence affects the bottom line significantly.

Steve
http://www.fivetrees.com

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

> If the system is cooperative, why would there be a  priority scheme?

The two are orthogonal.

Co-operative refers to when a context switch occurs.

Priority refers to how one decides which thread to switch to
when multiple threads are runnable.

The two concepts are somewhat orthogonal.  One addresses the
question of when to leave the current thread.  The other
addresses the question of which thread to go to.

-- 
Grant Edwards                   grante             Yow! WHOA!!  Ken and Barbie
                                  at               are having TOO MUCH FUN!!
                               visi.com            It must be the NEGATIVE
                                                   IONS!!

"Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> skrev i meddelandet 
news:waSdnd9ELZBX89nanZ2dnUVZ8qminZ2d@pipex.net...
> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
> news:fhrj5c$mfo$2@aioe.org...
>>
>> Since power consumption is an issue, you do not want to waste time
>> on a round robin scheduler.
>
> !!!!
>
> What a strange thing to say.
>
> A preemptive multitasker has *far* more baggage than a roundrobin. All 
> that task-saving and restoring...
>
> Steve
> http://www.fivetrees.com


Your comment is totally irrelevant, since I was not comparing
round-robin vs preemptive multitasking.


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

"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
news:fi281j$tea$1@aioe.org...
> "Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> skrev i meddelandet 
> news:waSdnd9ELZBX89nanZ2dnUVZ8qminZ2d@pipex.net...
>> "Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
>> news:fhrj5c$mfo$2@aioe.org...
>>>
>>> Since power consumption is an issue, you do not want to waste time
>>> on a round robin scheduler.
>>
>> !!!!
>>
>> What a strange thing to say.
>>
>> A preemptive multitasker has *far* more baggage than a roundrobin. 
>> All that task-saving and restoring...
>>
>
> Your comment is totally irrelevant, since I was not comparing
> round-robin vs preemptive multitasking.

I stand by my response. Please explain how a round-robin can "waste 
time" and hence waste power. Also please explain what you *were* 
explaining ;).

Steve
http://www.fivetrees.com 

On Nov 20, 2:16 am, Grant Edwards <gra...@visi.com> wrote:
> On 2007-11-20, Ed Prochak <edproc...@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.

That is more in line with what I have seen. So that quarter K of RAM
 is getting a little more room, relatively speaking.
>
> > No need to expose proprietary information, but I really would
> > like to know.
>
> Battery-operated sensors is one application I'm familiar with.

I'm trying to list the tasks for this, but it is late and I may not be
thinking clearly.
1. the sensor monitor records the actual readings. May have to
periodically reset some registers or timers
2. the host communicator (might be two tasks) deals with the comm
hardware and data link. Comm might be periodic, or random (e.g. sensor
results sent to host when a host connects, like a wireless water
meter, or RFID tag)
3 a data filter? generates moving averages, trend analysis or other
application specific calculations.

I cannot think of any other independent tasks. And the three I
described would form a pipeline, so should be easy to code. In this
system, I would agree though that a generic preemptive scheduler would
be overkill. I might still implement some specialized preemptive
scheduler, basically a special state machine like I said earlier. I
have found cooperative models too inflexible. And the weight of
preemption does not have to be heavy.

  Thanks for the friendly discussion BTW.
   Ed.

On Nov 21, 12:43 pm, "Steve at fivetrees"
<st...@NOSPAMTAfivetrees.com> wrote:
> "Ed Prochak" <edproc...@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 ;).

So you actually are supporting my observation, that you would have to
put delays or skips in one task (the serial port comm) to allow
another task (screen updater) to work properly. With a decently
designed preemptive system, the scheduler works it out based on the
load at runtime.
>
> > 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.

That is what I am saying, in many cases a preemptive kernal can make
the design much simpler by decoupling the tasks. And the overhead is
no onerous. At one place I worked, there was a contractor tasked with
implementing the software on a small daughter processor of our system.
He came in with a superloop design. I was able to show him how the OS
kernal we had would consume fewer CPU cycles than his superloop for
the same task load.  With the advantage of interrupt driven I/O versus
polling, it was a easy win for the preemptive kernal. And the tasks
became simpler too.


So, if you want to toss quotes, I cannot pass up the familiar
those who ignore the past are condemned to repeat it.   8^)

But more to engineering tastes, my College Chemistry Proffessor always
said:
if it works, use it!

So if it works, I'm not going to complain. I'm just pointing out a
possibly better option.

   Ed

On Nov 21, 12:45 pm, "Steve at fivetrees"
<st...@NOSPAMTAfivetrees.com> wrote:
> "Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote in message
>
> news:fhrj5c$mfo$2@aioe.org...
>
>
>
> > Since power consumption is an issue, you do not want to waste time
> > on a round robin scheduler.
>
> !!!!
>
> What a strange thing to say.
>
> A preemptive multitasker has *far* more baggage than a roundrobin. All
> that task-saving and restoring...

Only when there is work to do (and I do not agree it is MORE baggage,
as you know).
What happens in Round Robin when the system is idle? You essentially
have a busy loop.
A preemptive scheduler starts the null task which executes a halt
instruction. The entire CPU goes idle until the next interrupt (likely
the clock). Sure beats a busy wait loop.

  ed

On Nov 21, 12:53 pm, "Steve at fivetrees"
<st...@NOSPAMTAfivetrees.com> wrote:
> "Ed Prochak" <edproc...@gmail.com> wrote in message
>
> news:b139d63c-0b45-49dc-aed4-17f3248fad28@o6g2000hsd.googlegroups.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.)
>
> My response to that is not that it can't be done; more than cooperative
> is actually a better way to design (unless it's a multi-user
> programmable system, or, as another poster has noted, the dynamics of
> the team make the programming partitioning simpler and the entire team
> can't be depended on maintain the kind of discipline needed to make
> cooperative work properly).

Ah, you have done real systems development, excellent.
>
> > 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.
>
> I'm a *huge* fan of state machines in such cases. And - it also depends
> what you mean by "tasks". There are *always* multiple tasks: maintain
> the serial port, maintain time, maintain the LCD, maintain the keypad
> etc etc... By "better" above I mean that handling these synchronously
> means you avoid all sorts of asynchronous nonsense that is the bane of
> all preemptive OSs. The system is more robust, reliable, and bugs (can
> be) far fewer. (Digital hardware engineers will tell you in great detail
> why synchronous design is the only way to fly ;).)

Funny, I  don't think of those as tasks but you are right. In a
generic kernal, they do occupy a place in a task control structure.
(they might be interrupt level tasks or drivers, but tasks just the
same). Good point.

>
> > With the price of hardware has low as it is today, what kind of
> > systems still have these constraints? (Not rhetorical)
>
> Plenty. I've worked on control/measurement instrumentation products
> where, even these days, we have to make everything fit in 256 bytes
> (including the stack). And yes, we're working to a tight budget, as
> these are high-volume products where a difference in the CPU cost of a
> few pence affects the bottom line significantly.

Interesting. That is one area of embedded I haven't really worked in.
The smallest control/measurement apps I have any experience with is on
PLCs (Programmable Logic Controllers). They have become more
commoditized since I worked on them, but I think they still have much
more RAM than your products.

 About the smallest device I can remember working on was a comm
daughterboard for a motor controller. Even that device had a few K of
RAM (the comm buffer was exactly 1K). That was the device where I saw
how the super loop could be very painful. The architecture requires
the tasks to be limited to a max X CPU cycles. So every code change
required counting cycles. If you went beyond X, you split the code
into more task segments. (I had to program on it. I could not change
the architecture, since it was a purchased product.) Tha thing was a
real PITA. I am sure your designs are not like that one. (I'm sincere
here.)

Later,
   Ed

On Nov 22, 7:47 am, Ed Prochak <edproc...@gmail.com> wrote:

> A preemptive scheduler starts the null task which executes a halt
> instruction. The entire CPU goes idle until the next interrupt (likely
> the clock). Sure beats a busy wait loop.
>

A wait loop could also check if there's nothing to be done, and
execute a halt instruction to wait for the next interrupt.