The need to move on from Bare-metal to RTOS
Curious to know, how one decides if their project needs to move on from Bare-metal to using an RTOS? then from RTOS to using Embedded Linux? @MCU, MPU & Kits @Software Integration
20 Replies
First business then technical
@Umesh Lokhande I've bookmarked this topic in reddit that debates the need for RTOS against baremetal. Thought it may provide some pointers.
If I can bring a product in market fast using bare metal version 1 and build a cashflow would prefer that way
RTOS is only required if we have time critical function else state machine approach works great.
Linux based application again is required when you have a roadmap. Like android bsp for automotive applications
I recently got a code base to review and then found Interrupt interrupt-driven architecture could handle the situation. It's just a simple task to read sensor data using FreeRTOS. Now it is a question of fixing the code as it is or just using interrupt and finish it
Interrupt
Interesting post, thank's for sharing!
well then I've to convince them why I'm doing so...
Yess
Is the RTOS managing any connectivity?
yes, it uses serial UART to communicate. I managed to do this with UART interrupt and then used the NVIC controller to set priority
Got it. @Aditya thakekar are you suggesting that he handle interrupts w/o an OS? Is that possible? I thought the need for interrupts alone mandated the use of an OS..
No I meant just use state machine approach for now
Isn't it about system design? Depending on how fast certain processes should run.
- Baremetal: ultra low size firmware, power optimisation, when you want to use only required functions/APIs as part of your software. Lot of customization room.
- RTOS: there are several processes running and no unexpected compromise for any, need to schedule the processes and prioritize or even set a read/write frequency for the processes(example: you have a BMS communicating through CAN with the vehicle controller, onboard sensors measuring voltages and currents, LED status indicator trail and so on)
- Linux OS: Quite a different game. when you need to run your own system controller, needing PC type features with networking, build processes etc.
FreeRTOS shouldn't harm given INTERRUPT_PRIORITY to it. But the point is not having the RTOS would do the same as well.
Agree, to keep things minimal, the priority groups and sub-priority of NVIC controller found very useful
My view if your embedded board have microprocessor,then go for embedded Linux.If it is having microcontroller go for rtos.very rarely nowadays baremetal programming is done.It also depends on the application
i agree .. the clear you are with your application the easier it will be for you to select ...
A very basic question should be asked before finalzing bare-metal vs RTOS, are things needs to be prioritized? If yes then RTOS is must. e.g. what should be done when the code is busy glowing LEDs but high temperature interrupt is risen by sensor? If it is ok to complete LED work before you can handle sensor then bare-metal might be enough, if not then go for RTOS because it will help to preempt low priority task and jump to high priority task.
however, nowdays all the vendors(ST, NXP etc) provide their SDKs which rarely have support/example for bare-metals, so using what they support well(RTOS) helps to complete the product development timely.
Times have changed, products have become smarter and complex, I think number of new products using bare-metal environment professionally would be almost negligible compared to products which uses RTOS.