This is my first post in the FreeRTOS community!!!
I would like to know, how should be the task structure for an application which consists of UI
touch display, 2 sensors for collecting data, then but obvious processing the data for and getting the required results by performing some calculations on the received data, sharing the data over UART, USB and Ethernet, reading an external RTC and storing and reading data in EEPROM and some basic IO operations.
Currently I have developed the above stated application in stm32F746 where the touchGFX has its own task for the display, USB has its own task and I have created a single task which handles all the remaining processes i.e. reading ADC for sensor inputs, processing the data and then transmitting it over UART, USB and ethernet and reading external RTC and storing and reading data in EEPROM and some GPIO handling as per user inputs.
I am very new to any RTOS and I would like to know how should be the ideal structure for the tasks as I have read and heard that the approach that I have used doesn’t really utilize the full potential of the FreeRTOS and that I should divide the processes into multiple tasks.
Following are certain points regarding my application that may help you guide me more thoroughly :-
Sensors data needs to be collected for certain period of time, upon user request (through UI), the time is user settable.
Storing and reading data is also not a continuous activity and will be required only if user changes some process parameters.
Data is to be transmitted over UART, USB and ethernet after the user set time is completed i.e. again not a continuous process.
RTC is to be read continuously as it displays the time over UI.
GPIO handling is done as per the user input (through UI).
Please guide me accordingly, I am not expecting the code but an approach which should be taken so as to develop applications using RTOS.
Any inputs are highly appreciated.
Thankyou in advance!!!
Tasks are best used to simplify any timing logic needed in a single task, if there’s software I/O that has to be done, it could be put into a task to separate its timings from the main application logic. Waiting on a round trip on a network socket must not block the display from updating.
I would consider the UI application logic to be the “main” task since ultimately the flow of execution is driven by user input. If user input is accepted while performing the other duties such as writing to USB and Ethernet, then those duties should be in their own tasks.
Depending on the latency requirements of the data transmission, it might be possible to do sensor data collection and transmission in the same task. However, submitting sensor data to a FreeRTOS queue can be done from an ISR (as long as the Queue never fills), and may be a good candidate to do so if the sensor has an interrupt signal. Otherwise, submitting sensor data via a FreeRTOS timer is a decent fit as well.
If display updates need to be atomic, then all display operations should be serialized into a task which periodically reads the RTC and also receives state updates from the main UI task.
This will probably create the largest technical hurdle for keeping sensor read timings consistent.
The main design tradeoff will probably be latency in display updates vs consistency of sensor data input and transmission.
If GPIO input can be consumed via ISR or some other non-blocking mechanism, then signalling the main UI task would burn fewer cycles on polling.
GPIO output can probably be done in the UI task depending on use case. If there was a button on the display to toggle a red LED or even strobe it using PWM, it could be done directly within the UI task. But, bit-banging a serial port over GPIO might require its own task.
Thankyou for your guidance, certainly this was something I was expecting from the community.
Yes, currently I am polling sensor data, and it certainly can be done using ISR and yes I am using queues for transmitting the sensor data from main task to the UI.
User Inputs can be also be shifted to interrupts as well.
Will surely try your approach as I find it way better than that I have implemented. Will keep you posted if any queries.