I’m working on a FreeRTOS project that has a BLE module and an LED driver. A mobile data sends data to an ESP32 microcontroller and I receive it on the BLE task. I need to send this data to the LED driver task without using global variables. I know we can use queues for this, but the LED driver task also wakes up when I send notifications from another task. Is it okay to send the queue from the BLE task, and then send the notification for the LED driver task? The LED task will wake up from the notification and read the queue at this moment. Am I on the right track or is there another approach to do this?
That could be possible but it’s usually better to have 1 event input for a task.
If the data being sent to the LED task are e.g. just on/off flags for the LEDs you also could use task notifications as event group for all LEDs.
See RTOS task notifications - FreeRTOS™
Or use a queue for the LED task if the data is more complex.
Hi @hs2 , thanks for the reply.
What do you mean by “1 event input for a task”? Do tasks respond to a single event only?
The LED task at this moment just needs to know 2 int values, so I use the queue for it. The problem is that I know in the future it’s going to grow and it will need to act according to different events. The notification value works perfectly for receiving those events, but not for the int values
If you are waiting on a queue, your task is in the blocked state and will be blocked until something is written to the queue or your timeout expires.
If you are using a queue to send the data, you dont need a task notification to wake up the other task; it’ll be made ready if its waiting on a queue that gets data.
Note that if you are blocked in xQueueReceive, a task notification will not unblock you (task notification would wake up from xTaskNotifyWait).
The point is that a task can only wait for or block on a single synchronization event or mechanism. Combining multiple of them ie. notifications and a queue usually causes problems. Hence it’s easier to use just 1 of them. In your case and as mentioned by @archigup a queue seems best suited because you have to signal a maybe growing data set and not just single bits.