Since esp now callback belong to wifi task, there's no way to make sure anything need to be sent via wifi is successful. All send functions that can be used in esp now callback are done through queue.Whilst this seems to workaround the problem, I don't think this workaround will work in my scenario as the send is now asynchronous via the queue so the calling function doesn't know whether the send has happened or not.
BUG/ Workaround: ESP Mesh and ESP Now interoperability issues
-
- Posts: 68
- Joined: Wed May 16, 2018 12:31 pm
Re: BUG/ Workaround: ESP Mesh and ESP Now interoperability issues
Re: BUG/ Workaround: ESP Mesh and ESP Now interoperability issues
Thanks for getting back to me. Sorry I am not sure I follow your last response. In my example, I am receiving a message via espnow. If I understand correctly, the receive callback will be on the WiFi task (thread?) . I then call the mesh send from the callback - (ie on the same WiFi task). Shouldn't this work ok and this is a bug?
The workaround I have implemented it for me to create my own queue to do this. Are you saying the mesh send actually under the covers adds the message to an internal mesh queue which the mesh task asynchronously does the actual send from? If so, wouldn't that add further weight to my argument that calling the mesh send directly should work?
To add further complications to my setup, I have a coap interface to an end client which calls a "get" which gets to the esp end point via the mesh and the value sent as a response to the coap client. The above would force an asynchronous 'get" for the coap client which doesn't seem to work in observe mode.
Thanks in advance for you help in getting to the bottom of this
Lee.
Ps have raised the bugs on git as suggested although not got any replies yet.
The workaround I have implemented it for me to create my own queue to do this. Are you saying the mesh send actually under the covers adds the message to an internal mesh queue which the mesh task asynchronously does the actual send from? If so, wouldn't that add further weight to my argument that calling the mesh send directly should work?
To add further complications to my setup, I have a coap interface to an end client which calls a "get" which gets to the esp end point via the mesh and the value sent as a response to the coap client. The above would force an asynchronous 'get" for the coap client which doesn't seem to work in observe mode.
Thanks in advance for you help in getting to the bottom of this
Lee.
Ps have raised the bugs on git as suggested although not got any replies yet.
-
- Posts: 68
- Joined: Wed May 16, 2018 12:31 pm
Re: BUG/ Workaround: ESP Mesh and ESP Now interoperability issues
```
The receiving callback function also runs from WiFi task. So, do not do lengthy operations in the callback function. Instead, post necessary data to a queue and handle it from a lower priority task.
```
See [IDF-DOC](https://docs.espressif.com/projects/esp ... p-now-data)
esp_mesh_send could be a block function and it needs both mesh task and wifi task to handle something during sending.
So when you are in esp_now_callback, the wifi task couldn't handle events from other task, this is why esp_mesh_send didn't work.
The receiving callback function also runs from WiFi task. So, do not do lengthy operations in the callback function. Instead, post necessary data to a queue and handle it from a lower priority task.
```
See [IDF-DOC](https://docs.espressif.com/projects/esp ... p-now-data)
esp_mesh_send could be a block function and it needs both mesh task and wifi task to handle something during sending.
So when you are in esp_now_callback, the wifi task couldn't handle events from other task, this is why esp_mesh_send didn't work.
Who is online
Users browsing this forum: No registered users and 30 guests