I am developing an UART protocol to ensure communication between two boards (Master board and Slave board). Slave board includes many sensors and actuators and Master board shall command this board by a set of commands like GET_SENSOR_VALUE and SET_MOTOR_SPEED etc … Many functions shall be executed in my project and a permanent control of sensors values shall be done (Example: Master board shall get temperature value each 5 seconds, it shall get Battery's level each 5 seconds, it shall enable ventilation when temperature is high …). All equipment are connected to Slave board (sensors and actuators) and the main role of Master board is monitoring.
I've been reading some articles about specifications and embedded systems design and figured out that the first thing to do before starting is to choose the kernel: RTOS or GPOS (Bare metal).
My question is: In my case, if I choose RTOS (in Master board), Should I implement my needs as separate tasks/functions?
- temperature_task
- humidity_task
- battery_task
- motor_task
- ventilation_task
If yes, does UART support high speed context switch time? example:
00:00 temperature_task : GET_TEMPERATURE
if temp>threshhold send START_VENTILATION
00:01 battery_task: GET_LEVEL if level < threshhold send TURN_OFF_SYSTEM
00:02 humidity_task: GET_HUMIDITY if level < threshhold send DO_SOMETHING
00:03 temperature_task : GET_TEMPERATURE
if temp>threshhold send START_VENTILATION
00:04 battery_task: GET_LEVEL if level < threshhold send TURN_OFF_SYSTEM
00:05 humidity_task: GET_HUMIDITY if level < threshhold send DO_SOMETHING
Best Answer
Yes, it is generally a GREAT idea to separate functionality in this manner when an RTOS is in system. Great care needs to be taken to ensure mutual exclusion between tasks and shared resources such as common memory or peripherals as to avoid race conditions and unpredictable behavior. A common approach to this problem is by blocking each peripheral behind a "gate-keeper" task that manages the data flow in and out, typically issuing a callback function to the caller when the expected data has been received. Read this article (Chapter 7 goes over this specifically) from the FreeRTOS documentation. That being said, the bare metal approach can be perfectly adequate while having tighter coupling between functional modules of software.