If I want to use FreeRTOS tasks and queues but also the ESP-NETIF WiFi support, do I need to have an ESP event loop callback that just forwards the ESP (event loop) events to the FreeRTOS queue for the task I have created?
I don't see any way to register a FreeRTOS queue as the recipient of WiFi event - did I miss this or is my suggestion about the correct way to go?
Thanks.
WiFi, FreeRTOS task and event loops
-
- Posts: 28
- Joined: Thu Nov 03, 2022 1:57 pm
Re: WiFi, FreeRTOS task and event loops
I suspect the answer to my question is not use FreeRTOS task and queues directly but to use the ESP event loop library and create multiple event loops, which seems to create tasks and queues "under the covers". So you get the ESP event loops that much ESP code expects but the tasks and queues that spread work nicely across a more complex project.
-
- Posts: 1708
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: WiFi, FreeRTOS task and event loops
From what I have seen so far, the event loops aren't much of a thing in most applications, i.e. most never actively use them besides initialitzing one for the WiFi stack.
The IDF itself uses the (default) event loop in some places, and it may also benefit some other use cases, but generally I think that 'native' queues &c. are a 'better' way to communicate between components because, as you noticed, they often integrate better into the code structure/flow. Event loops/handlers may be beneficial if you can/want to directly react to an event, i.e. inside the handler callback; no need for extra tasks for those small, infrequent jobs in this case.
If you look at the UART driver for example, you'll notice that it doesn't use the event loop but (optionally) provides a queue from which you can consume its events. So this pattern is not too unusual either.
The IDF itself uses the (default) event loop in some places, and it may also benefit some other use cases, but generally I think that 'native' queues &c. are a 'better' way to communicate between components because, as you noticed, they often integrate better into the code structure/flow. Event loops/handlers may be beneficial if you can/want to directly react to an event, i.e. inside the handler callback; no need for extra tasks for those small, infrequent jobs in this case.
If you look at the UART driver for example, you'll notice that it doesn't use the event loop but (optionally) provides a queue from which you can consume its events. So this pattern is not too unusual either.
Who is online
Users browsing this forum: Majestic-12 [Bot] and 80 guests