What is the difference b/w rtos and embedded system. - VxWorks

This is a discussion on What is the difference b/w rtos and embedded system. - VxWorks ; Can any one tell me about the difeerence ib/w rtos & embedded system....

+ Reply to Thread
Results 1 to 11 of 11

Thread: What is the difference b/w rtos and embedded system.

  1. What is the difference b/w rtos and embedded system.

    Can any one tell me about the difeerence ib/w rtos & embedded system.


  2. Re: What is the difference b/w rtos and embedded system.

    embedded system:
    A system - specific combination of h/w and software -to acheive a
    particular objective or a specified range of objectives.
    There is no timeliness limit.
    That is the environment is not
    strict as for the reaction time of the system.

    Real time system - on the other hand is also A combination of h/w and
    s/w ,typically for a specified objective/range of objectives ,but at
    the same time,its RESPONSE TIMES are to be deterministic and should be
    meeting its deadline.Else the environment or the system might loose
    their integrity!

    cheers-
    kaushal.


  3. Re: What is the difference b/w rtos and embedded system.

    Sounds like a pretty arbitrary distinction there... you can have an
    embedded system that is also a real-time system.


  4. Re: What is the difference b/w rtos and embedded system.

    hi ben,
    can you be more specific with some example(s).

    cheers-
    kaushal.


  5. Re: What is the difference b/w rtos and embedded system.

    Hi Kaushal,

    I guess we're just playing word-games here... like you said, an
    embedded system is basically a catch-all term for any
    hardware/software/mechanical platform that is designed to perform a
    specific, dedicated task. They can be a standalone entity, or they can
    be part of a larger system. A real-time system is, to generalise, a
    system that has some sort of hard or soft timeliness requirement, as
    you also said.

    My Google search for an "embedded system" definition mentioned a car's
    anti-lock braking system, which would be as good an example as any of
    an embedded real-time system. It fits our definition for an embedded
    system, and obviously it has very strict time limits to meet (an ABS
    would be useless if it took even a few seconds to engage).

    So all I was trying to say was that I didn't agree with you when you
    said an embedded system has "no timeliness limit"... I would suggest
    that embedded systems can (and usually do) have time limits to meet,
    and hence they fit the definition for both an embedded and a real-time
    system.

    Ben


  6. Re: What is the difference b/w rtos and embedded system.

    You are comparing 2 things that should not be compared to each other.
    An embedded system may run an RTOS, a best effort OS or no OS. An RTOS
    may run on an "embedded system," a general purpose computing platform,
    or a distributed system. The definition of "embedded system" is
    amorphous for the most part, but the definition of an RTOS is not, at
    least in the hard real-time sense.

    An RTOS is an operating system that guarantees "real-time" response.
    RTOS's may be characterized as hard real-time or soft real-time. A hard
    real-time RTOS typically contains a scheduler that ensures that the
    highest statically allocated priority task that is ready to run, runs.
    Using such a scheduler a designer can apply the theory of
    rate-monotonic-scheduling to ensure that each task never misses a
    deadline.

    A soft real-time RTOS is again an amorphous beast, but is generally
    characterized as a RTOS that contains a scheduler that utilizes a
    scheduling algorithm that provides best effort real-time. These systems
    are used in audio or video applications because loosing a frame or a
    bit of audio is not a big deal (typically).


  7. Re: What is the difference b/w rtos and embedded system.

    Only the systems, applications are soft or hard real-time; but NOT the
    real-time operating system. A RTOS is just a RTOS, nothing else -
    neither soft nor hard. There ARE many hard real-time
    systems/applications often built without a RTOS. Repeat, it's the
    system/applications that are soft or hard real-time, but not the OS.

    VG


  8. Re: What is the difference b/w rtos and embedded system.

    A RTOS contains a scheduler to switch between tasks. That scheduler can
    run any number of algorithms to decide which task to run next. If the
    scheduler contains an algorithm to support Rate-Monotonic scheduling
    then that RTOS is a hard real-time RTOS. It may also have algorithms to
    support soft real-time scheduling. In which case it would be both a
    hard and soft real-time OS.


  9. Re: What is the difference b/w rtos and embedded system.

    On 13 Mar 2006, pfefferz@colorado.edu wrote:
    > A RTOS contains a scheduler to switch between tasks. That scheduler
    > can run any number of algorithms to decide which task to run
    > next. If the scheduler contains an algorithm to support
    > Rate-Monotonic scheduling then that RTOS is a hard real-time
    > RTOS. It may also have algorithms to support soft real-time
    > scheduling. In which case it would be both a hard and soft real-time
    > OS.


    That is not correct. An RM scheduler will allow multiple tasks to run
    in real-time. A priority based scheduler is "real-time" for the
    highest priority task. If you (an RTOS user) can guarantee run-time
    of the highest priority task, then the 2nd highest priority task can
    also be hard real-time, etc. This *IS* hard real-time with the use of
    a watch dog to reset the system.

    Hard real-time could either be defined to provide a hard error like
    the watch dog will provide, or that it is guaranteed that the system
    will perform in all cases in bounded time... I would guess we want
    the later. For either definition the priority scheduler (and wdLib)
    in vxWorks will allow vxUsers to create hard real time systems.

    The giant switch statement (state machine loop) is also hard real time
    if all conditions execute in bounded time. This is a system without
    an OS and is common is some micro controllers (AVR, 8051, PIC, etc).

    If an RM task takes more than its allocated CPU time, it is also not
    "hard real time"; in this case the RM scheduler will be able to flag
    the error, but the system is still not hard real time as it has
    failed. It is up to the RTOS user to make the system hard real time.
    An RTOS can only provide some tools/capabilities to make this
    possible.

    It is impossible for an OS user to make something hard real time if
    all task are pre-emptable for instance. Especially if some tasks are
    not under the control of the OS user and then may require O(N)+ times
    to complete.

    It is very rare to find a system in which all tasks must be hard real
    time. Most RM schedulers allow some tasks to take up any "slop", so
    RMS OS's can also have a combination of hard and non-hard real time
    tasks.

    fwiw,
    Bill Pringlemeir.

    --
    ``C Code. C code run. Run, code, run... PLEASE!!!'' - Barbara Tongue

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  10. Re: What is the difference b/w rtos and embedded system.

    I find issue with much of what you say here.

    In a hard real-time system, every task which has a deadline is a
    real-time task. To be a real-time system every such task identified as
    real-time must run in real-time, not just the first one. An a static
    priority based scheduler supports this for all tasks, if configured
    correctly.

    Introducing a watch-dog concept into the is-a-RTOS-real-time argument
    is inappropriate. A watch-dog is a band-aid, a very useful, necessary
    band-aid, but one none the less.

    In addition, a giant switch statement is not an OS.

    I have the point-of -view that any OS that contains a mechanism to
    support deterministic work, is a real-time OS.

    All tasks are preemptable in a real-time OS. If they weren't the
    processor would sit in a busy loop forever executing one task. When do
    you think the scheduler runs anyway?


  11. Re: What is the difference b/w rtos and embedded system.

    On 15 Mar 2006, pfefferz@colorado.edu wrote:
    > I find issue with much of what you say here.


    Say where? You didn't quote anything ;-).

    > In a hard real-time system, every task which has a deadline is a
    > real-time task. To be a real-time system every such task identified
    > as real-time must run in real-time, not just the first one. An a
    > static priority based scheduler supports this for all tasks, if
    > configured correctly.


    This is true. So why did you say that a rate monotonic scheduler was
    needed for hard real time? The point of what I said in my previous
    post is that if the highest priority task runs in a bounded constant
    time and this time is less than its period, then the second highest
    priority task can also be guaranteed to be hard real time if it also
    runs in a bounded constant time and the time for T1+T2 is less than
    the period for the 2nd task.

    This is the sum of what I had to say and it is mainly to dispute your
    statement that hard real time meant a rate monotonic scheduler.

    > Introducing a watch-dog concept into the is-a-RTOS-real-time
    > argument is inappropriate. A watch-dog is a band-aid, a very useful,
    > necessary band-aid, but one none the less.


    I mentioned watchdog because a rate monotonic scheduler has a
    mechanism to flag when a task has exceeded its allocated CPU use. A
    watchdog can do the same by inspecting that the hard real time task
    collection has run all tasks during the period of interest. Sorry for
    diverting your attention. I didn't mean to imply that a watchdog was
    a substitute for a scheduler.

    > In addition, a giant switch statement is not an OS.


    A giant switch statement (state machine) can be used to delegate CPU
    time in an embedded system. Refer to the subject line for why I
    mentioned this.

    > I have the point-of -view that any OS that contains a mechanism to
    > support deterministic work, is a real-time OS.


    That doesn't seem to support the previous statement that a rate
    monotonic scheduler is needed for a hard real time system.

    > All tasks are preemptable in a real-time OS. If they weren't the
    > processor would sit in a busy loop forever executing one task. When
    > do you think the scheduler runs anyway?


    This is not true. The highest priority task of a priority base
    scheduler is *NOT* pre-emptable. The highest priority task yields the
    CPU explicitly [that is how the scheduler runs]. You just have to
    look at the plethora of question related to the tNet task being
    starved on c.o.v to see that this is true. Ie, my debugger doesn't
    work [because some high priority task is in an infinite loop...]

    Some desktop OS's have a "priority" for some tasks. This is not a
    priority based scheduler, but is more like an "unbalanced round
    robin". Perhaps this is what you are thinking of when you made the
    statement above?

    I should say that a rate monotonic scheduler will make the work of
    making a hard real time much easier. However, it is not a criteria.
    For most systems I have worked on, there is usually only a need for a
    few tasks to run with a hard dead line; so a priority based scheduler
    is fine. However, that might related to my problem domains.

    fwiw,
    Bill Pringlemeir.

    --
    He who does not bellow the truth when he knows the truth makes himself
    the accomplice of liars and forgers. - Charles Peguy

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

+ Reply to Thread