Food for thought soon makes for mental indigestion.
-- Nicholas O. Lindan, Cleveland, Ohio Consulting Engineer: Electronics; Informatics; Photonics. Remove spaces etc. to reply: n o lindan at net com dot com psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
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.
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.
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.
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
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
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.
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
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
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 ;).
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.
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.