Why doesn't MPC5554 board requires a RTOS? Does it come with a built-in OS? - embedded

Question

I was looking at reference manual for MPC5554 board, there was no mention of any Operating System(Kernel) used. Applications can be run without the use of any external OS on this board.
I understand RTOS does memory management, task scheduling function,so are these function done by MPC5554's built in firmware?
There are vendor of RTOS for these board, so I wonder in what application would they be needed?
Is RTOS meant to be just another abstraction above the board level implementation?
And if we are putting a RTOS above , wouldn't that conflict with built in OS?

Answer 1

There is no built-in OS - why would you assume that?
Many embedded applications run bare-metal with no OS (RTOS or otherwise), but in any event the choice of RTOS is a developer decision not a board manufacturer's decision.
An RTOS fundamentally provides scheduling, synchronisation, inter-process communication and timing services. Memory management may be provided for devices with an MMU, but that is not a given. A bare-metal application can establish a C run-time environment and boot to main() with no scheduling or IPC etc. In most simple RTOS the system boots to main() where the RTOS is initialised and started, rather than the OS starting `main() as would happen in a GPOS.
A board manufacturer may provide a board support package for one or more a specific RTOS, but equally the BSP (or HAL or driver library) may comprise of bare-metal or RTOS independent device drivers only. Typically it is for the developer to integrate an RTOS, device drivers and middleware (such as filesystems and networking) etc., and these may come from a single or multiple vendors. You have to understand that many (or perhaps most) developers will be designing their own boards around sich a microcontroller rather then using COTS hardware, so there can be no one-size-fits-all solution, and instead embedded development tends to be a more kit-of-parts approach.

Answer 2

Clifford already hit the nail on the head. Depending on the complexity of the task you wish to accomplish, you may want to reconsider what exactly it is you need. If your only interest in an RTOS is based on the "real-time" part, then it may well be easier (and cheaper) to create your own little interrupt-driven bare metal application. Generally speaking, I find that if performance constraints are your main concern, then less abstraction is better.
Based on the way you phrased your question, I'm going to assume that you are looking at an eval board or dev kit with the MPC5554 as its micro, in which case you might already have some basic startup code that does things like setup the memory controller and a few peripherals (most dev kits or IDEs come with some amount of sample code you can reuse).
A simple application might do the following things:
initialize the runtime environment (MMU, INTC, FMPLL)
initialize the peripheral devices you wish to use, ex. ADC, GPIO, SPI etc. (this can get pretty complex if you have any external peripherals that require the EBI)
initialize the eMIOS to generate a timed interrupt with high priority (ie. your main processing task loop)
The way I've seen this typically work is that once all of the above initialization is complete, your main application thread runs into an infinite loop that you can use as a background task to do garbage collection or some non-time-critical fault detection. Then, in the ISR for the timed interrupt you created, you implement a basic scheduler to do your driver-level processing (ex. trigger/read ADC, read/write GPIOs, initiate any IPC transactions etc.). An extremely basic concept might look like this:
void fastTaskISR()
{
static uint8 frameCount = 1;
...
switch(frameCount)
{
case 1:
//Task 1
break;
case 2:
//Task 2
break;
case 3:
//Task 3
break;
case 4:
//Task 4
break;
case 5:
//Task 5
break;
default:
//Default case for robustness. Error.
break;
}
frameCount++;
if(frameCount > 5)
{
frameCount = 1;
}
...
}
Optionally, you can use one of the scheduled tasks to generate a software interrupt which can then be used to run some slower tasks or more complex control logic. Where I work this is a tried and true formula: an eMIOS driven "fast task" (usually between 100us and 1ms period) + a software interrupt driven "normal task" which runs the higher-level control logic, often generated from a Simulink model. Needless to say, we do a lot of reuse of the BSP and driver level code.