Hi @Kittu20,
Your question is actually more than one questions:
-
Why choose FreeRTOS vs other RTOSes ?
Answer: Why choose an Arduino, or a Raspberry Pi? Simply because it is actively maintained, which a large user base and has an active support community. -
If everything can be done baremetal, why choose an RTOS at all?
Answer: A baremetal application is fast and efficient, and can be flexible if coded that way. However, most baremetal applications are designed for a specific purpose and lack this flexibility that using a scheduler gives you. I’ll give you a real-world example: After deploying an application, the users want a new feature to be added than wasn’t originally planned. With a baremetal implementation, adding a new task is a big ordeal which can screw up the timing of all other tasks in the system. With FreeRTOS you simply create a new task, assign it a priority and go refill your coffee cup. Therefore with an RTOS it is much easier to achieve maintainability.
Another added benefit of using an RTOS is that having multiple developers work on the same project simultaneously is much easier to achieve, and easier to merge. -
But please, give me a real-world example!
Answer: Assume that you have an action camera with 3 computing units: an application processor, an image processor and a microcontroller for the sensor sub-system and collecting user input from buttons/touchscreen. The microcontroller communicates the two other processors using SPI. Sensor data is gathered using I²C and SPI, based on timer polling and interrupt.
Let’s list all the tasks that the microcontroller has to do:
Task1: Poll battery temperature at 2Hz via I²C and interrupt the application processor in case of overheat condition.
Task2: After the application processor triggers the recording, read gyroscope data at 6.4kHz (interrupt-based) and send it to the image processor with minimal latency for image stabilization.
Task3: (Polling or interrupt-based): Read accelerometer data at 100Hz and buffer it.
Task4: At a low priority, run a portrait/landscape algorithm based on accelerometer data buffer.
Task5: (Interrupt-based) collect user input from buttons and touchscreen and relay it to the application processor.
Now that we think we have collected all the requirement we choose whether or not we go baremetal or RTOS. Implement and test and we are done… until your manager calls you into a meeting saying that image stabilization performance is not good. Instead of sending the data directly to the image processor in real time, he wants you to modify the code so it timestamp the data precisely and sends it to the host instead, so they can run image stabilization in software instead.
It is much easier to partition the tasks, exchange data and events between them, concurrently run low-priority and high-priority taks, and maintain a system using an RTOS than doing it baremetal.
Full disclosure: This is my point of view only, as an embedded developer with 10 years of experience.