Looking for Design Suggestions for How To Wait for a Response using ESP-Now

Projects Programming
1

Just looking for design ideas/recommendations. I have a project that has one controller ESP32S3 and multiple slave ESP32S3s. Both master and slave have LEDs and 7 segment displays. The state of the LEDs and displays depend on the state of the board. I am using SimpleFSM to keep track of the states and ESP-Now to communicate between the master and the slaves, and a message queue to handle receiving messages.

Some of the communication is just one-way: master to slave and the indicators are in different configurations, and then reset to the "waiting for next human input". However, some of the messages require the master and slave to have the indicators in a certain state until the slave sends a response to the master.

I am trying to figure out how to have the master "wait" for the slave to respond to a certain message before processing the other messages on the queue, so the condition of the indicators is correct.

One example I have seen has two message queues. One for messages that don't require a response, and one for messages that do require a response. The ESP-Now sending task contains the core logic for blocking. It acquires a mutex before sending and waits for the response on the response_queue before releasing the mutex.

Another example uses one message queue and involves the following steps for messages that need a response:

  1. Send a broadcast message to all ESP32S3 slaves to be silent
  2. Send message to the particular ESP32S3 that needs a response
  3. Wait for the response to come in on the one message queue
  4. Send another broadcast message that "normal" communication can resume.

I am curious if others on the list have faced a similar situation and how they solved it. And your opinion between the two approaches described above as to which on is better (however you define better)?

Thanks!

2

You need to have an indication when the message has been received from that device. Is there such an indicator? Second you need to have a millis timer so you can take action when the wait time has expired.

3

ESP Now has a built in send/ack mechanism for messages sent to one peer (not broadcast messages). The ack is for receiving the message, not for correctly processing it. :wink:

It appears that the freeRTOS xQueueReceive has a programmable timer to timeout if nothing is put into the queue within the allotted time.

Perhaps the first method with multiple queues is better.

4

You can always add those capabilities.

5

many protocols like this will retransmit if an ACK in not received within some period of time. Does the library handle this or does your program need to? what happens if an ACK is never received? doesn't there need to be some mechanism from the library to confirm the sender that the message has been received.

and it is common for a response from the receiver to be recognized as an implicit ACK.