I don't use an RTOS because... - Page 8

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

Compare all this with the development of multi-programming OSs in
the first place.  In the beginning there was batch, and the program
owned the machine.  Then came time sharing, which was developed to
let the program assume it owned the machine, because program
development was much easier in such circumstances, and divorced
from the actions of other programs (at least it was hoped).  If we
had to think about disk access, write and read queues, terminal
buffers and interrupts in every useful utility, we would never get
anywhere.

Similarly the embedded OS comes in once there are several programs,
pronounced processes, that have to be coordinated.  Adding RT to
that means that we can predict the limits of service delays.  The
more complex the overall system, the more the isolation effects of
an RTOS will help.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

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

Ian
--
Ian Bell

Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

CHOON! ;)

Steve
http://www.fivetrees.com



Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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


Quoted text here. Click to load it

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

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

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
http://www.fivetrees.com



Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

Thank you. I feel ... enlightened ;-)
Or at least not as ignorant.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...


Quoted text here. Click to load it

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.



Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

OK:

Critical code sections
Testability
Determinism

Ian

Ian
--
Ian Bell

Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

Very helpful.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it
small
tasks
see
alternatives to
not
are

is not
than
requirements
other
be. This
every
into
the
with

before
small

Distributing the problem over more processors simplifies each
controller, but you still have to make the total system work. It seems
your just moving the complexity somewhere else (interface
specification) and not really making the total system any less complex.


Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

I have to agree with this sentiment. Yes, distributing over
multiple processors forces the interface design issue. However,
were the team to take the same care with interfaces between
threads on the same processor, the same gain can be achieved
with the benefit of not needing communications protocols
and parsing (one addresss space.)


--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

You obviously haven't considered the same system from two different design
strategies the way I have. I can assure you that, in a system whose
requirements specification is very complex, there is a great deal of
benefit in the multiple processor approach.

When I was developing a very large robotic system I explored the "whatif"
of using a multitude of processors instead of a dual processor system. I
used a Fault Tree Analysis software package that performed the probablistic
failure rate for the total system. The dual processor approach used to take
a very long time to calculate its probabilistic failure rate due to the
common mode calculations that were required. With the greater number of
processors, distributed amongst specific functions and using a decent
interface technique, the time to calculate the probable failure rate took
much less time (1 day instead of 5 days).

Knowing this from that work, I have looked at the whole system architecture
aspect for multiple processor systems. A processor per actuator, a group
controller and central controller multi-layer system always seems to
simplify the whole system and, although the functionality of the whole
still seems to be complicated, the understandability of the total system is
very much eased. By using multiple simple processors, the overall system
functionality is factored into much simpler sub-functions that are easier
to fully understand, easier to test for compliance and easier to maintain.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it
seems
complex.
design
"whatif"
Quoted text here. Click to load it
system. I
probablistic
to take
the
of

took
architecture
group
whole
system is
system
easier
maintain.

I guess I don't understand why you couldn't create "virtual processors"
(tasks) within a single processor using the same protocol/interface as
your multiple processor system. The virtual processors would have the
same functionality as your multiple simple processors and you have
removed the high failure rate physical connections. Also the practical
matters of a system upgrade (multiple downloads, tracking software
version compatibilty between processors), large development toolsets
required(if using different types of processors), obsolescence
headaches, multiple environmental issues, complex test simulations are
also big negatives. Now I have worked with/designed distributed systems
but they were distributed because a single processor couldn't handle
the throughput or a chuck of the problem was already solved by someone
else and I could buy it off the shelf. If a single processor can do it
all its a no brainer for me which architecture to choose. However, like
you said, if you do go with a distributed system, it helps to make one
processor very smart and all the others very very dumb (dictatorship is
a good model to follow).


Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it
It
of
used
to
number
decent
rate
a
to
are


Ah! Another post to comp.arch.embedded!  Let's see what this
one has to say... (opens post, whistling a happy tune)


              **********
 WHAT THE.....**BAM!!!**
              **********
 
(SFX: sound of parts falling off of a recently-crashed automobile.)

...

Honest, officer, I was cruising along at the speed limit
when I ran into this giant block of text right in the
middle of the newsgroup! No paragraphs, no whitespace,
just a dense square block of text...

Yes, I tried to stop, but the information superhighway was
slippery.  Someone had filled the road with this huge greasy
sheet of quoted text full of random ">>>" and ">" an ">>"
strings.  I think I saw a .sig in there as well.

No, I didn't get the license number of the fellow who spilled
the toxic post, but I remember that he was driving this old
SUV - maybe a joep? - that was making an annoying "www...www...
www...www...www..." sound, and on the side of it I saw the
words "http://groups.google.com " spray painted over a quite
attractive but faded "DejaNews" sign.

Officer, Please catch him before he kills another thread!




--
Guy Macon <http://www.guymacon.com/

 : ) : ) : ) : ) : ) : ) : ) : ) : )


Re: So... What are the alternatives? Was: I don't use an RTOS because...

What's your point after this totaly useless post?

Re: So... What are the alternatives? Was: I don't use an RTOS because...


Quoted text here. Click to load it

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.



Re: So... What are the alternatives? Was: I don't use an RTOS because...

Quoted text here. Click to load it

Overall system resilience can be achieved much easier despite the number of
physical connections. I also indicated that the system would have been (at
minimum) a dual processor system in anycase. One system for control, the
other system running a permit to operate. Even so, with the calculations
performed on the system integrity, I favoured the many processors design
because it was easier to prove that it met the integrity requirements. This
was due to a lack of common mode issues between the various tasks that
would have plagued the development within a single (or just two)
processor(s).

Quoted text here. Click to load it

Not really that much of a problem for the kind of systems I deal with
(mostly Robotic or Automation for Nuclear Energy and Transportation
Systems). I have one development environment and a code library that I can
use on a wide range of processors (we are talking real re-use here). Also
note that many of my systems have no need for upgrade over time as they are
specified for specific tasks over long periods of expected operation. I can
build the same type of nodes with several different processors and its
functionality would be exactly the same in each case.

Quoted text here. Click to load it

I expect that you could also find a considerable difference in costs
between the two approaches.

To run the sort of control I deal with at the Integrity Levels demanded of
my systems you would probably consider processors with high MIPS ratings,
high dollar per chip, masses of fast memory and some RTOS that you do not
have the code for. With a requirement for 100% coverage testing you would
be tied up for ages to prove your system is safe.

I, on the other hand, count how many actuators there are, note what type
they are and can see my way to using simple cheap microcontrollers that are
fully committed to really looking after the needs of the actuator in
meeting the demands of the system. Occassionally I may use two processors
per actutor (one for control and one for comms). All such nodes also
perform some limited data-logging (for diagnostic purposes) and have a
range of self checking features that signal the nodes health status up to
the group controller. I have all the source code for my systems and I can
provide full certification for it. Testing the individual nodes is quite
simple and once installed the system will usually operate for its required
lifetime (25 years+) without hidden faults (actually, to date only one of
my systems has been installed long enough to reach decommissioning early in
its 26th year - the others are still going strong with the longest lived
current system now in its 20th year - no upgrade having been necessary).

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: So... What are the alternatives? Was: I don't use an RTOS because...


(Cconcerning multiple processor designs)

Quoted text here. Click to load it

Like everything else, it depends. :)  When I was working on toys
that shipped 100,000 unit per day, a penny per unit was huge.
When I worked on a multi-million dollar DVD-RAM production line,
the cost of the computers was two orders of magnitude lower
than the cost of the programming.


Re: So... What are the alternatives? Was: I don't use an RTOS because...
Quoted text here. Click to load it

I think the right (if one can state there is a "right" anyway) solution
is highly system dependent. I used to favour one processor designs
because of (hardware) simplicity.  It was a "let the software guys
solve" attitude even though I also did software. After some (several :-)
  ) years undergoing the pains of such an approach and after attending
some of Jack Ganssle's lectures I was struck by the perception of how
fool I was by chosing it (because it's quite obvious when one gives it
some thought). Just to cite an example I have a design in which a rotary
encoder is handled by the main processor. Putting a small
microcontroller there would make things much easier and reliable. The
main processor handles (proprietary) serial communication with some
acquisition modules. Another low end microcontroller would do the magic
and release the main processor for more apropriate duties, not to
mention would make the software design much easier. These are simple
examples.

I have seen this multiprocessor approach proposal more often lately. I
am not sure if that is because I am paying more attention to the subject
or just because of a paradigm change though.

I am in the process of designing a new architecture for new products and
that is the reason why I posted this questions. The posts so far have
been very interesting and enlightening. One thing at least is clear to
me right now: there is not a "one fits all" solution for the problem.

Regards.

Elder.

Site Timeline