Prev: [troll] Fine, so what is a "complete" RTOS?
Next: re-entrant function in Keil-4 RVMDK
From: Paul Keinanen on 30 May 2010 03:04
On Sat, 29 May 2010 19:25:31 GMT, bastian42(a)yahoo.com (42Bastian
Schick) wrote:

>On Sat, 29 May 2010 11:09:32 -0700, Tim Wescott <tim(a)seemywebsite.now>
>wrote:
>
>>I pontificated by saying that a complete RTOS should have both binary
>>and counting semaphores, and someone called me on it by asking just what
>>a "complete" RTOS is.
>>
>>I realized that my definition of a "complete" RTOS is pretty fuzzy --
>>mostly a mismash of every feature that I've ever wanted to use in an
>>RTOS, with none of the features that I didn't want to use.
>
>Actually I think a 'complete' RTOS is in the same category as the
>perfect programming languange: It just does not exist.
>
>It always like this: The hammer needs to fit the nail, else your thumb
>gets hurt.
>
>My problem with above statement of yours is that I am from the message
>passing school. I write/wrote kernels and these do not offer
>semaphores as part of the kernel because I strongly believe that
>_direct_ message passing leads to better designed software.

If in a real time system with critical timing constraints there are
any kind of queues (larger than single or double buffering), this
should alert to check the design in general.

Queues can be used, when it is known that a specific number of events
will occur in burst somewhere within a larger time frame, but even in
this case the number of events must will be well defined and
_enforced_, even if for instance an external device malfunctions and
generates more events than specified.

>
>But in paper-evaluations people ask for semaphores, so we need to
>lenghty explain why my RTOS does not have it :(
>
>
>>And do you think my "minimum necessary" RTOS really includes everything
>>you need? Or do you think that it's just not functional until you can
>>pass messages and have Bertie Bott's Every Flavor Flag and Ethernet and
>>USB and a hard drive and cotton candy on a stick?
>
>I think this is another problem I have with the _new_ embedded
>engineers: They do not know the difference between a PC running
>Windows,Linux or MAC OS (or ...) and an embedded device running an
>RTOS kernel.

One reason for the popularity of Windows (CE) and Linux on embedded
devices is partly the availability of programmers that have at least
some familiarity with the environment.

From my past experience in getting programmers familiar with large
single thread programs to work with multitasking time constrained
applications, during the first month you had to check their work daily
and they become productive after 2-3 months.

The problem with various RTOS kernels is that their concept vary very
much from each other, causing a long period and when porting an
application from one RTOS to an other RTOS may require restructuring
at a high level (often at the task level) design or write heavy
wrappers to simulate the previous RTOS interfaces.

It is no wonder that Linux becomes popular on platforms that can
afford it, even if any of the simpler RTOS products could do the job
as well.

From: Chris H on 30 May 2010 08:48
In message <hts8be$oig$1(a)speranza.aioe.org>, D Yuniskis
<not.going.to.be(a)seen.com> writes
>I see the basic services that an *embedded* OS should support
>to include:
>- memory management
>- CPU management
>- time management

Yes to the above.

>- communications

Probably not. Not all embedded systems are interconnected. The range of
comms types is enormous and AFAIK not covered by any RTOS.... eg LIN,
CAN, PROFIBUS, SPI, RS232 RS485 etc

The only thing embedded systems have in common is they are all
different....
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



From: Vladimir Vassilevsky on 30 May 2010 09:23


Chris H wrote:
> In message <hts8be$oig$1(a)speranza.aioe.org>, D Yuniskis
> <not.going.to.be(a)seen.com> writes
>
>>I see the basic services that an *embedded* OS should support
>>to include:
>>- memory management
>>- CPU management
>>- time management
>
>
> Yes to the above.

A C/C++ compiler should provide built-in interrupt safe functions to
create and switch contexts. Everything else you do yourself or use
libraries of your preference.

VLV
From: D Yuniskis on 30 May 2010 13:37
Hi Chris,

Chris H wrote:
> In message <hts8be$oig$1(a)speranza.aioe.org>, D Yuniskis
> <not.going.to.be(a)seen.com> writes
>> I see the basic services that an *embedded* OS should support
>> to include:
>> - memory management
>> - CPU management
>> - time management
>
> Yes to the above.
>
>> - communications
>
> Probably not. Not all embedded systems are interconnected. The range of
> comms types is enormous and AFAIK not covered by any RTOS.... eg LIN,
> CAN, PROFIBUS, SPI, RS232 RS485 etc

Communications applies to intertask exchange of data, not
talking through a *driver* to a bit of hardware.

I.e., consider the case of separate, protected address
spaces. How can task A talk to task B if the OS doesn't
get involved (to bridge the protection domains)?

Whether you are using shared memory, message queues, mailboxes,
etc. they all fall in the scope of the OS to implement.

> The only thing embedded systems have in common is they are all
> different....
From: David Brown on 30 May 2010 15:26
Vladimir Vassilevsky wrote:
>
>
> Chris H wrote:
>> In message <hts8be$oig$1(a)speranza.aioe.org>, D Yuniskis
>> <not.going.to.be(a)seen.com> writes
>>
>>> I see the basic services that an *embedded* OS should support
>>> to include:
>>> - memory management
>>> - CPU management
>>> - time management
>>
>>
>> Yes to the above.
>
> A C/C++ compiler should provide built-in interrupt safe functions to
> create and switch contexts. Everything else you do yourself or use
> libraries of your preference.
>

That would be /very/ nice.

It's not quite enough, though. It should also provide an atomic
compare-and-swap instruction (or built-in function, if the cpu does not
have a CAS instruction). That would let you build atomic accesses,
semaphores, mutexes, etc., as a standard C library. Memory barrier and
interrupt enable, disable, save and restore built-ins would also be
useful - these normally have to be done using inline assembly.


First  |  Prev  | 
Pages: 1 2
Prev: [troll] Fine, so what is a "complete" RTOS?
Next: re-entrant function in Keil-4 RVMDK