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

From: Roberto Waltman (usenet_at_rwaltman.net)
Date: 01/15/05 

Date: Sat, 15 Jan 2005 16:10:00 -0500

>> I've used them extensively. They're great when you're working on
>> projects that need more than one software engineer, and in an
>> environment where you're using a lot of library code.
>
>That is an interesting comment. I have never heard an RTOS having
>properties that make multi-person development easier. It is mot clear from
>the post but did you mean an RTOS in general or a pre-mptive one in
>particular?

>Ian

I agree with Tim - Any OS, not necessarily an RTOS. For the same
reasons that another poster recommended using multiple processors:
Divide and conquer.

Splitting a large application into separate processes that communicate
with each other using a limited and well specified set of functions,
(I do not mean that it as in "C" functions) makes it simpler to
develop them, to assign them to separate teams, to test and verify
them in isolation, etc.

Of course you can do the same without an OS. But having one generally
provides most, (at least some) of the common layer as OS calls, IPC
mechanism, etc. Many projects that need more functionality than what
is provided by the bare OS would add it in a way that still looks as
common OS functions. (Like a message passing library for IPC, etc)

As others pointed out, there are embedded systems and there are
embedded systems. I probably would not make any sense to use an RTOS
in, let's say, a TV remote controller. But the kind of systems I am
currently working on, (32bit processors, 128-256 Mbyte RAM - all used
up - multiple hardware interfaces to the external world and other
system components, support for multiple communication protocols, 20+
people development teams, etc.) would be much more difficult to
develop without the foundations provided by an OS.

Roberto Waltman.

[ Please reply to the group,
  return address is invalid ]

Relevant Pages

  • Re: How ordinary embedded differs from RTOS code?
    ... Many "ordinary" embedded systems use RTOSs; I assume you mean what's the difference with using an RTOS vs. not. ... With an RTOS you can assign each of these to an RTOS task; without you usually write a task loop that does everything in one context. ... It may do so after checking flags, etc., or the task functions may check the flags themselves. ...
    (comp.arch.embedded)
  • Re: Thread Pre-Emption Question . . .
    ... The suggestion is to queue up data for the signaling to this thread and allow a 2nd or multiple threads to process the queue. ... The example code is a MULTIPLE WRITER, SINGLE READER design, and the READER/WRITER logic is fine. ... know what is happening during a time when your threadaren't running - if you think about this, then it will become clear why Windows is not a RTOS and why your task, unless it is a debugging / tuning process, is not possible without OS / hardware support. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: When A Embedded System Need An OS
    ... It is just like asm or a higher language like c. ... timer flags. ... An RTOS provides better and more flexible ways to schedule your tasks ... I recommend you to read the following books about Embedded Systems: ...
    (comp.arch.embedded)
  • Re: So... What are the alternatives? Was: I dont use an RTOS because...
    ... Roberto Waltman wrote: ... > I agree with Tim - Any OS, not necessarily an RTOS. ... there are embedded systems and there are ... Tim Wescott ...
    (comp.arch.embedded)
  • Re: Startup code
    ... >> No, in embedded systems, startup code should be restricted to setting up ... >> stack pointers etc., initialising or clearing variables, setting up the ... >If you use an rtos you need to initialize the rtos structures ...
    (comp.arch.embedded)