ESP32 Forum

Hi ESP32ers,

Recently I got some small problem about "Inter-task Communication".
The test set is: If I trigger a button (one of five). I need to track this event in one task, put message like the new state of the button, the number of the button and timestamp of this event as payload, and pass this payload to other tasks. The event queue has solve my problem pretty well. But if I'd like to have multiple receivers - say I'd like to display these infos by my "display_task", then write it down on a sd card by my "sdcard_task", then send it to thingspeak through my "internet_task". I think "EventGroups" and "Queues" are only part of the story.
I've solve this problem somehow by "chaining" these tasks through separately defined queues together.

Task1 ---- (task1_to_task2_queue)--->Task2---(task2_to_task3_queue)--->Task3 ...

For just one single event, I'd have to init TASK_SUM_NUM-1 queues in order to chaining them together (sync). It is a huge wast of memory and very error prone. Any suggestion on this point?

(This is a duplicated question which I asked pcbreflux in youtube comment session. He homebrewed a whole lot cool tutorials. Highly respect!)

Option 1: Do 3 different queues. This will use more memory, but will ensure parallel push of data.
Options 2: Use 3 different binary semaphore "takes", and have each task retrieve the payload upon a successful "take".

Hi Hassan,

Thanks for your "Binary Semaphore" suggestion.
Right now I just leave the solution in my code as I made before. Don't have much time to make that part more beautiful. But I do think some better solutions on this topic.

The Flow-char of my Idea:
https://flic.kr/p/215JzVf
(are you serious? I can't post a picture on this forum?)

The main Idea is like the flow-char shown. I deployed only one queue and a eventGroup for this job.

1. (st.1) Firstly, the btn_task will try to look up the "btn event buffer", see what's in there. If there is something happened, then I will mutate the global variable "btnEvent" with all the information from the "btn event buffer"

• (st.2) Then, "btn_task" task mutate the first bit of eventGroup, which is the blocking bit for "led_task".

• (st.3) So the led_task will access the value of variable "btnEvent", and do what it should be done.

• (st.4) then at last led_task trigger the second bit of eventGroup.

• (st.5) then the samething happend for "sd_card"

• ... ...

• (st.9) When bit 9 of eventGroup get flipped, which is blocking "btn_task". Then the loop "btn_task" get going and start from the very beginning

I'm still not have the chance to implement this idea at all. But I believe it will works, and for a very complex system, should be a good practice to do so, for smaller footprint and better syncronization.

This may be not good idea, but did you think about freeRTOS notifications? It has less footprint in ram usage.
Let say you have task which is blocked until button is pushed. That task can keep pointers to all tasks you want to receive message about this event. Now, when button is pushed you can send notification to every task that needs it.

GFast, if I understand your description correctly you'll end up with a system that essentially is sequential, rather than parallell. To keep your system parallell, you really should consider using separate queues if you can afford the memory usage.

chegewara wrote:This may be not good idea, but did you think about freeRTOS notifications? It has less footprint in ram usage.
Let say you have task which is blocked until button is pushed. That task can keep pointers to all tasks you want to receive message about this event. Now, when button is pushed you can send notification to every task that needs it.

Hi chegewara,

Thanks for your suggestions!

I've saw pcbreflux told in his tutorial, that on ESP32 plattform the FreeRTOS Notification is still not implementated.
This is the video: ESP32 #20: FreeRTOS - Inter-task Communication - Queues

But later on I did found a Example Implementation in his Repository and I checked out, it works as it should (magic...).

Just write down these text to thank you for the suggestion, and document what I've figured out for the new comers potencially who have the same question later.

permal wrote:GFast, if I understand your description correctly you'll end up with a system that essentially is sequential, rather than parallell. To keep your system parallell, you really should consider using separate queues if you can afford the memory usage.

Hi permal,

Thanks for your suggestion.

I will think over which is the best practice for my current project. If I understand correctly, "parallell" means "better performance". But the performace boost should based on realbility first. (Just for fun)

As some one from Arduino World, its hard to image a system works on two core parallelly. Just give me more time.

cheers

Su

permal wrote:GFast, if I understand your description correctly you'll end up with a system that essentially is sequential, rather than parallell. To keep your system parallell, you really should consider using separate queues if you can afford the memory usage.

Hi permal,

Thanks for your suggestion.

I will think over which is the best practice for my current project. If I understand correctly, "parallell" means "better performance". But the performace boost should based on realbility first. (Just for fun)

As some one comes from Arduino World, its hard to image a system works on two core parallelly. Just give me more time.

cheers

Su