Question of the Week: When does it make sense to use an RTOS or operating system?

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 !

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 !

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.

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.

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.

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.

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.

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.

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.

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.