Selecting RTOS, is it an important decision for your project? The answer is definitely: YES!!!

Many projects have become very successful as they did choose from their requirements the best RTOS, others have failed just because they did choose the ”wrong” RTOS. Buying an RTOS today also means that you buy a development environment like editor (can easily be replaced), compiler, debugger and other tools. They are as important as the RTOS itself and its functionality.

Do you really need an RTOS?
Do you have deadlines in your project? And then I mean deadlines in the product, not in the project. Is it necessary that some part of your application must fulfill specific timing requirements? And do you need to have a multi-tasking application? Do you need a deterministic OS? If your answers are yes to these questions then you need an RTOS. If you answer no to some of these questions, but you need a small (memory footprint) OS, and you need sophisticated development tools, then you should also consider to use an RTOS instead of another OS.

Which tools do you need?
As I mentioned above the tools are as important as the RTOS itself. A good RTOS and bad tools and vice versa is a bad combination. Good tools can save much more money than they cost to buy. Good tools will speed up your development cycle and make it easier to test and maintain your product. So which tools do you need? Depends of course on the size of your company, size of project, size of application and experience. What you always need is:

• Editor
• Compiler, assembler, linker
• Debugger

But you should probably also buy:

• Version control system
• Source code management tool
• Profilers
• Simulator (if not included in the debugger)
• Requirement Management tool
• Code coverage measurement tool
• Statical analyze tool
• And maybe some HW tools like ICE, logical analyzer etc

Saving money by not buying tools may be the most ”stupid” decision that you could make. Many times the cost for a software tool is less than the cost of one man week, and many times you may save man months in extra costs of work.

Scheduling Mechanism
It is also important that you decide which scheduling mechanism that you need. For more details see article about Scheduling.

RTOS Functionality
This is what most engineer focus on when they are going to select RTOS. I agree it is important. But please first make sure that you know what you really need. And that means that you have to do the architectural design of your software application before you can select RTOS. You need to know exactly which functionality that you need, how it should works, timings for RTOS calls etc. Too many projects select RTOS before they do their architectural design, and that means that their design will be influenced by their choice of RTOS instead of vice versa.

When should you select RTOS?
Simple answer: As late as possible! So what does that mean? When you start your project, you can start to look into the market for different software and hardware products that you may need. After that you can do your design, split the functionality between HW and SW. Continue to do detailed design to get to know what you really need.

Then it is time to select:

• Hardware
• CPU
• Boards etc
• Software
• RTOS
• Tools etc

Selecting RTOS
What is important and what is not important?

Important is:

• Functionality that you really need (as I said above, make your architectural design before selecting RTOS)
• Tools that helps you in developing and testing your product (Evaluate)
• Support (Ask for references)
• Documentation (Evaluate)
• Training classes (Ask for references)
• Support of device drivers and BSPs (but do not buy a bad RTOS just because they have a BSP for your board)
• Get assistance if you do not have enough knowledge (cheaper than buying wrong RTOS)

Not important is:

• Odd functionality that no one needs and uses
• Tools that have a nice GUI but does not work