Has this wheel already been invented?

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
 Click to see the full signature
Reply to
Ulf Samuelsson
Loading thread data ...

...

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
 Click to see the full signature
Reply to
Stephen Pelc

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''
 Click to see the full signature
Reply to
Grant Edwards

Because, as you said, stacks will overflow.

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
 Click to see the full signature
Reply to
Michael R. Kesti

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

Robert

--
Posted via a free Usenet account from http://www.teranews.com
Reply to
Robert Adsett

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

Reply to
Ed Prochak

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

Reply to
Ed Prochak

It depends on the threading semantics that you want.

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.

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

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

MSP430F20xx, AVR ATtinyxx, etc.

--
Grant Edwards                   grante             Yow!  I'm having
                                  at               a tax-deductible
 Click to see the full signature
Reply to
Grant Edwards

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

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

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

--
Grant Edwards                   grante             Yow!  Yes, Private
                                  at               DOBERMAN!!
 Click to see the full signature
Reply to
Grant Edwards

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.

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

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

Steve

formatting link

Reply to
Steve at fivetrees

!!!!

What a strange thing to say.

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

Steve

formatting link

Reply to
Steve at fivetrees

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

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

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

formatting link

Reply to
Steve at fivetrees

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!!
 Click to see the full signature
Reply to
Grant Edwards

"Steve at fivetrees" skrev i meddelandet news: snipped-for-privacy@pipex.net...

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

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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

formatting link

Reply to
Steve at fivetrees

That is more in line with what I have seen. So that quarter K of RAM is getting a little more room, relatively speaking.

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.

Reply to
Ed Prochak

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.

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

Reply to
Ed Prochak

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

Reply to
Ed Prochak

Ah, you have done real systems development, excellent.

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.

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

Reply to
Ed Prochak

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

Reply to
Arlet

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.