I don't use an RTOS because...

"Elder Costa" wrote

Food for thought soon makes for mental indigestion.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
 Click to see the full signature
Reply to
Nicholas O. Lindan
Loading thread data ...

There is a way to influence what gets discussed in a newsgroup that works well, and another way that has never worked no matter how many people have tried it.

What works: Posting articles on the topic you wish to see discussed, and participating in the resulting discussion. Using killfiles and filters so that you don't see the posts that you dislike.

What doesn't work: Complaining about how terrible all those other posters are for not posting what you want them to post.

Reply to
Guy Macon

I refer you to 'Patterns for Time Triggered Embedded Systems' by Prof. Michael J. Pont.

Ian

--
Ian Bell
Reply to
Ian Bell

And let's be clear about this, an event loop can be a RTOS. My comment was aimed solely at pre-emptive ones.

Ian

--
Ian Bell
Reply to
Ian Bell

I beg to differ. The Imagecraft AVR compiler for instance produces direct code for 8 and 16 bit operations, but calls lib routines when you use longs.

Meindert

Reply to
Meindert Sprang

And what about malloc/free ?! It is commonly used as many discussion here show.

-

An how small is small ? Todays embedded systems range from a 6-pin PIC up to many-megabytes telecom routers.

As for the RTOS I maintain we say all below 4K RAM is too small for _our_ RTOS (dynamic, message passing).

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

In my field we call 6-pin PICs "Supercomputers" because they have so much more capabilities than what we use...

Reply to
Guy Macon
[... C Library Functions ...]

You roll your own memcpy, but pull in sprintf for simple string formatting? Permit me to shake my head in amazement...

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

memcpy = frequently used function, large data moves, hand-optimization->speed optimization.

The drive for a hand-rolled sprintf is totally different; the goal being to reduce memory footprint. If the compiler provides a cutdown version of the function, it can make sense to use it.

Reply to
larwe

Out of curiosity, what are _you_ using, 1-bit serial CPUs (no joke, they exist).

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
 Click to see the full signature
Reply to
42Bastian Schick

There is actually a kernel which allows a DO-178B level A part to coexist with less critical parts. This is done through time and memory partitionning.

formatting link

Reply to
Lanarcam

That's stretching the common definition of RTOS.

Just look at the commercial RTOS selection and tell me how many of them are not preemptive.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

I assume that the facts contained go beyond the scope of an 8051. Given the subject (8051) and $100 price tag at Amazon, I'll probably pass.

Will you please summarize a key point or two wrt reduced reliability when using a pre-emptive system?

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

May I have a go?

First, an analogy. In digital logic design, it's well understood that synchronous design is a) more reliable and b) easier than asynchronous logic. Properly done, all you have to worry about is one set of parameters (setup time between clock edges). With async design, the possible fault scenarios are endless.

To my mind, a pre-emptive system is analagous to asynchronous logic. There is an immediate lack of determinism (a task can be interrupted at any time [1]). By contrast, a cooperative multitasker is essentially synchronous and offers far fewer failure mechanisms - all you have to worry about is relinquishing control sufficiently often.

([1] Yes, I realise that normal hardware interrupts do the same, but these are generally rather easier to deal with. I also realise there are mechanisms for protecting sensitive areas of code from interruption.)

Like many here, I do both hardware and software. As I've said a few times, I find it odd that the lessons we've learned in hardware (synchnonism, decomposition and partitioning/modularity) are taking so long to propagate into software design.

Having said that, pre-emptive systems have their place too - e.g. desktop systems with oodles of memory running diverse & unrelated programs at the same time. At the embedded coalface, I'd argue that a co-operative system, while requiring a higher degree of design-time discipline, offers a smaller footprint (no need for context-switching memory), hence lower cost, and enhanced reliability. For me, that last word (reliability) is what it's all about.

CHOON! ;)

Steve

formatting link

Reply to
Steve at fivetrees

The first assumption is that this analogy is reasonable. Individual parts of the system in a synchronous electronics design are asynchronous with respect to one another until they need to synchronize. Indeed, synchronous components are composed of asynchronous gates.

Within a preemptive system, it is necessary to synchronize the asynchronous components.

Yes, it is necessary to proceed methodically, just as it is with hardware, but it is still achievable.

Indeed, digital hardware has become a success because of standardization and modularization of interfaces that includes logic levels, buses, and careful timing specifications.

A similar technique *can* be applied with software, however, the "types" of "parameters" across the interfaces are much more complex, and representing the timing aspects is not something that is captured by common programming languages.

Again, the solution is a consistent methodology that goes beyond the current typical practice of software engineering.

However, that certainly does not mean that such discipline does not exist, and that pre-emptive systems are inherently less reliable.

Of course having a notion of "sufficiently often" spread across a system that is sufficiently complex *is* the problem with this approach. To achieve modularity (as in a digital hardware system,) components must be unaware of one another beyond their interfaces.

I agree with this observation that software engineering as it is commonly practiced is having a difficult time learning these lessons. It does, however, require the practitioners to move beyond the procedural (superficially simple) aspects of software engineering. Practitioners must understand the requirements for creating software components that are independent well specified with respect to time as well as parameter-type and protocol.

This same need, due to program diversity, exists in many medium to larger scalle embedded systems.

I certainly agree that there is a time and place for every technique. Using a pre-emptive scheduler is not the answer for every application. Keep it as simple as possible ...

Pardon my ignorance but ... what is a choon?

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

Heh ;). It's a deliberate mispronunciation of "TUNE", commonly used to express approval of a particular piece of music (in this case, "Already Gone"). But possibly not within this newsgroup ;).

Steve

formatting link

Reply to
Steve at fivetrees

Which is what?

Probably none but who said this discussion was limited to commercial RTOSs?

Ian

--
Ian Bell
Reply to
Ian Bell

OK:

Critical code sections Testability Determinism

Ian

Ian

--
Ian Bell
Reply to
Ian Bell

I believe this fits PumpkinInc's Salvo. But perhaps Andrew will address this, himself.

Jon

Reply to
Jonathan Kirwan

Indeed. If you avoid edge triggered devices and devices with memory, you can even do a fully asynchronous design and "sync" it by simply waiting X amount of time between changing the input and looking at the output. Sometimes nature does that for you; the inputs are from a human and the human looks at an indicator at the output, not caring that the LED that just came on actually went on and off a few dozen times in the millisecond before settling down. Mechanical switch inputs and relay driver outputs are the same way - the relay ignores the fast-moving garbage.

Reply to
Guy Macon

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.