Comments on: Question of the Week: When does it make sense to use an RTOS or operating system? http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/ Shedding Light on the Hidden World of Embedded Systems Mon, 28 Jul 2014 16:18:37 -0400 hourly 1 http://wordpress.org/?v=3.0 By: P.N. @LI http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-705 P.N. @LI Mon, 12 Apr 2010 20:01:50 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-705 <p>Re: If time-to-market is critical </p> <p>IF???</p> Re: If time-to-market is critical

IF???

]]> By: E.W. @LI http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-704 E.W. @LI Mon, 12 Apr 2010 17:44:31 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-704 <p>I think previous posts have covered the technical aspects :-)<br /> If the production volumes are low and you use a lot of the device drivers and protocols then it'll tend to be cheaper to use an RTOS.<br /> If the production volumes are high then even though the overheads of an RTOS are low, they can be significant and a roll-your-own can be cheaper, especially if you're not using lots of the device drivers.<br /> If time-to-market is critical ( for you to get there before your competitors), then an RTOS can give you a head start.<br /> As L. X. says, if you want to demonstrate that your system has been developed to a process that conforms to a particular standard, your choices of RTOS are limited. There are a few RTOSs that are designed to be used in military/aerospace/nuclear/automotive applications, but it's more than a rubber-stamping exercise and may require working closely with the RTOS vendor.</p> I think previous posts have covered the technical aspects :-)
If the production volumes are low and you use a lot of the device drivers and protocols then it’ll tend to be cheaper to use an RTOS.
If the production volumes are high then even though the overheads of an RTOS are low, they can be significant and a roll-your-own can be cheaper, especially if you’re not using lots of the device drivers.
If time-to-market is critical ( for you to get there before your competitors), then an RTOS can give you a head start.
As L. X. says, if you want to demonstrate that your system has been developed to a process that conforms to a particular standard, your choices of RTOS are limited. There are a few RTOSs that are designed to be used in military/aerospace/nuclear/automotive applications, but it’s more than a rubber-stamping exercise and may require working closely with the RTOS vendor.

]]> By: D. @EM http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-698 D. @EM Thu, 08 Apr 2010 15:11:28 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-698 <p>I'm working in deep-deep embedded areas (automotive and industrial automation) and would never consider not using an RTOS. </p> <p>There is a class of not-so-well-known RTOSses that have no file-system, multi-tasking in the usual way etc. but is still delivering a reliable task scheduling service and a minimum of HW abstraction.<br /> In the past I've even written such simple RTOSses on my own to ease the subsequent development. </p> <p>RTOS ? Never again without !</p> I’m working in deep-deep embedded areas (automotive and industrial automation) and would never consider not using an RTOS.

There is a class of not-so-well-known RTOSses that have no file-system, multi-tasking in the usual way etc. but is still delivering a reliable task scheduling service and a minimum of HW abstraction.
In the past I’ve even written such simple RTOSses on my own to ease the subsequent development.

RTOS ? Never again without !

]]> By: B.Z. @LI http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-703 B.Z. @LI Mon, 05 Apr 2010 22:17:55 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-703 <p>When a design indicates multiple asynchronous threads or processes rather than simpler synchronous operation, an RTOS kernel is recommended. Even with fairly complex operations, a synchronous system can be easily handled with a coroutine scheduler and can be 100% validated. But when you have an asynchronous situation, a COTS RTOS makes things a lot easier.</p> <p>That's my dividing line -- asynchronous versus synchronous operation.</p> When a design indicates multiple asynchronous threads or processes rather than simpler synchronous operation, an RTOS kernel is recommended. Even with fairly complex operations, a synchronous system can be easily handled with a coroutine scheduler and can be 100% validated. But when you have an asynchronous situation, a COTS RTOS makes things a lot easier.

That’s my dividing line — asynchronous versus synchronous operation.

]]> By: D.A. @LI http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-702 D.A. @LI Mon, 05 Apr 2010 15:41:32 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-702 <p>It might be useful to make a distinction between a real-time "operating system" and a multi-tasking kernel. As Paul pointed out, an RTOS has lots of facilities like file systems, network stacks and so on that can be useful if you need them. But at the heart of any RTOS is a multi-tasking kernel whose primary job is to schedule tasks in response to events.</p> <p>When I was teaching real-time programming seminars a few years back I told my students that if you have two or more asynchronous interrupts in a system, you probably should use a multi-tasking kernel. And remember that the timer tick is one of those interrupts.</p> It might be useful to make a distinction between a real-time “operating system” and a multi-tasking kernel. As Paul pointed out, an RTOS has lots of facilities like file systems, network stacks and so on that can be useful if you need them. But at the heart of any RTOS is a multi-tasking kernel whose primary job is to schedule tasks in response to events.

When I was teaching real-time programming seminars a few years back I told my students that if you have two or more asynchronous interrupts in a system, you probably should use a multi-tasking kernel. And remember that the timer tick is one of those interrupts.

]]> By: L.X. @LI http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-701 L.X. @LI Mon, 05 Apr 2010 06:02:07 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-701 <p>Most of time I will consider using an RTOS in the application as it usually offers a unified hardware abstraction layer and bunch of inter-process(task) communication APIs. Those offerings make applicaiton code more portable and more structure. On the other hand, if it is a very hard realtime application which means any time overhead are not acceptable I will not consider using RTOS. Finally I heard if the product needs to pass SIL(safety integrity level) certification, RTOS is probably not allowed.</p> Most of time I will consider using an RTOS in the application as it usually offers a unified hardware abstraction layer and bunch of inter-process(task) communication APIs. Those offerings make applicaiton code more portable and more structure. On the other hand, if it is a very hard realtime application which means any time overhead are not acceptable I will not consider using RTOS. Finally I heard if the product needs to pass SIL(safety integrity level) certification, RTOS is probably not allowed.

]]> By: P.B. @LI http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-700 P.B. @LI Wed, 31 Mar 2010 23:09:41 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-700 <p>It makes sense to use an RTOS when you require the facilities of an RTOS - file system, protocol stack, scheduler, debug tools, .... If you are building a system that doesn't require input or output, and doesn't execute much code, you probably don't need an RTOS. If you have several developers, and industry standard I/O ports, you probably need an rtos unless you have a very simple application, or you have enough time and money to write the entire product yourself and exhaustively test all the code.</p> <p>But an RTOS gives you future growth, to add capabilities that your customers demand, by just incorporating additional parts of the RTOS : Ethernet port, USB, wireless, web access, touch screen gui, .... an RTOS lets you buy these commodity items and lets you focus on your value add, where your product really differentiates itself from other products. And the RTOS comes tested, so you only have to test and debug your application, not the entire system. </p> <p>And a RTOS allows easy migration to a new processor or hardware, without your software development team having to rewrite everything for the new hardware.</p> <p>I would hate to have to write my own file system, disk drive code when this is a commodity item, and would work with all the disk drives out there. If manufacturing changes hardware due to cost or availability, your software needs to be able to respond without a major software rewrite if you want to be cost competitive in today's environment.</p> It makes sense to use an RTOS when you require the facilities of an RTOS – file system, protocol stack, scheduler, debug tools, …. If you are building a system that doesn’t require input or output, and doesn’t execute much code, you probably don’t need an RTOS. If you have several developers, and industry standard I/O ports, you probably need an rtos unless you have a very simple application, or you have enough time and money to write the entire product yourself and exhaustively test all the code.

But an RTOS gives you future growth, to add capabilities that your customers demand, by just incorporating additional parts of the RTOS : Ethernet port, USB, wireless, web access, touch screen gui, …. an RTOS lets you buy these commodity items and lets you focus on your value add, where your product really differentiates itself from other products. And the RTOS comes tested, so you only have to test and debug your application, not the entire system.

And a RTOS allows easy migration to a new processor or hardware, without your software development team having to rewrite everything for the new hardware.

I would hate to have to write my own file system, disk drive code when this is a commodity item, and would work with all the disk drives out there. If manufacturing changes hardware due to cost or availability, your software needs to be able to respond without a major software rewrite if you want to be cost competitive in today’s environment.

]]> By: P.N. @LI http://www.embeddedinsights.com/channels/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-699 P.N. @LI Wed, 31 Mar 2010 20:55:12 +0000 http://robert.blogs.embeddedinsights.com/2010/03/31/question-of-the-week-when-does-it-make-sense-to-use-an-rtos-or-operating-system/#comment-699 <p>Buying an RTOS gives a big advantage as follows: thousands of design decisions have already been made (for better or worse) and the project does not have to be slowed down to consider each of those decisions. In this day and age, all but the most cost or power constrained projects can afford the runtime overhead associated with at least a small fast kernel.</p> Buying an RTOS gives a big advantage as follows: thousands of design decisions have already been made (for better or worse) and the project does not have to be slowed down to consider each of those decisions. In this day and age, all but the most cost or power constrained projects can afford the runtime overhead associated with at least a small fast kernel.

]]>