RTOS experience

Question

I have been working as an embedded software engineer on mostly 8 bit micro-controller firmware and desktop/mobile applications development for the past five years.

My work on a WinCE project (in which I got introduced to .NET CF) was short lived. I did use core APIs for interrupt processing, peripheral communication, etc...but again, not exactly a pure RTOS environment. In order to get together more solid experience for growing more in the embedded field, I want to work more with RTOSes.

Will buying an evaluation board with an RTOS and putting together a project at home be regarded as a good experience or will an online course be more useful? I am just not clear as to what will be regarded as good experience. Any suggestions or directions will greatly help me. I have a passion for the field but just a need a point in the right direction.

Answer 1

Fundamentally, the only real difference between an RTOS and a "none"-RTOS is the fact that the scheduler is deterministic. Other than that the only distinguishing factor is that fact they they tend to be super light weight or striped down to the basic facilities, scheduling, semaphores, message passing, ect. Embedded development is less about knowing how to use the OS and more about figuring out how to meet certain constraints such as execution time, memory usage, data coherence and meeting specific deadline. Another important area is peripheral integration or board support which tends to be rather difficult and often requires someone with hardware experience. If you really want embedded experience then you need to solve an embedded problem. An evaluation board would be useful particularly if it has a TEC or some other sort of ethernet device because streaming different types of media(audio or video) over an IP network is a common embedded problem.

Answer 2

Do not buy an evaluation board with an RTOS and put together a project at home - just for CV credit. Only do it if you have a development board project you are burning to do.

You can get RTOS experience and be paid for it as you learn, if you bring enough to the table that the new company needs. In my case I had a track record in assembler. It sounds like you have that too. The first real RTOS was a proprietary one written in ADA and 1750A, so there was no way any new hire would have had specific experience in it. The second one was pSOS, and really that company was more interested in general C coding skill than that I knew what a semaphore was.

The trouble with most development boards is that there is a huge turn around time for trivial changes, so code development and learning on them is a slow process.

If you want to boost your experience in real time programming, get involved in either audio or video real time linux code. Your RTOS is linux. It will be a faster learning process and you'll be able to point to your code being in actual use.

Answer 3

FreeRTOS is a good way to get started -- as the name implies, it is an open-source cross-platform RTOS supporting over two dozen architectures. The core of the kernel is small, comprising only three C files.

Answer 4

It really depends on what you mean when you say "RTOS". There are "hard" real-time constraints on some systems (e.g. engine or flight controls) and there are "sotf(er)" real-time constraints where timing matters, but is not mission or life critical.

See the answers to my question here. It might give you some ideas for the second option (softer).

In the end, we opted for embedded Linux as the operating system and it worked out very well.