Closed blazoncek closed 5 months ago
Hi. Initialization seems to be ok. But it seems that you make something with sent buffer just after send. Normally you should wait until library calls the sent callback. Have a look to advancedespenow
example. Here, dataSent
is a callback that runs when last packet has been sent and confirmed (or timed out).
The result of QuickESPNOW.send
does not mean actually that message has been sent but shows if call is ok.
I see a reference to HardwareSerial::write at the end your log. Normally this means that error is produced during a Serial.print statement. I think it is not your case, but be careful to not overload serial buffers. This happens to me when I do verbose debug without filtering. Keep that in mind.
I think it would be useful for simple applications to have a synchronous mode so that send function only returns when espnow internal library calls sent callback. I'll think about it.
Hi. Thanks for the explanation. I did check advancedespnow
several times when writing above code. I didn't think I needed actual callback on dataSent
as I do not need any confirmation or other use for that.
Yes, we need to send (up to) 6 packets (about 1400 bytes) that comprise a full payload. Everything needs to work asynchronously without delaying main loop as it is used for realtime data (calculating LED effects). I have assumed that QuickESPNOW handles such approach (and it seems it does well on ESP32).
BTW HardwareSerial might be a debugging trace.
QuickESPNOW works with a queue to send messages. It has a buffer for 3 messages. There is a process that consumes the queue and actually send messages through esp-now, but only if last packet is confirmed.
So, you can send up to 3 messages in a row without waiting, but if queue is full and you try to send a new message, then the older in the queue is discarded.
You can increase queue depth by tuning ESPNOW_QUEUE_SIZE
into header files. It will consume about 300 bytes for every message.
I'm doing some changes in the library to allow synchronous sending, but, if your timing is critical, I would recommend to control it by yourself so that you may use full queue. With synchronous mode only one packet can be stored.
Hi. I was able to (logically) trace where the problem is (it is twofold).
1) calling delay()
function from within ISR should not happen (assuming espnowTxTask_cb
is called from OS timer interrupt)
2) sending a few messages in quick succession may enter a loop that takes too much time for WDT
Let's say you quickEspNow.send()
4 messages (overflowing queue). First call to espnowTxHandle()
will set readyToSend
to false
until sending of a single packet completes (in tx_cb
) but there are still 2 meesages in queue so it will enter while (!readyToSend) delay(1);
loop which may be enough to trigger WDT as delay()
is not permitted in ISR.
What I would do is break out of espnowTxHandle()
instead of entering while (!readyToSend)
loop and wait for next timer invocation of espnowTxTask_cb()
.
I still need to test my theory and may do a PR if it is correct and you think it worthwhile.
Update: Seems to work well. No more WDT reset.
One more thing.
When the ring buffer is full I would expect (and would be the correct way) for quickEspNow.send()
to fail and not discard last message. That way it would be easy to handle such errors in the application.
First off, thank you for a very versatile library. It makes handling ESP-NOW very easy.
Unfortunately I am seeing "Soft WDT reset" on my ESP8266 installations when sending packets while connected to WiFi network.
My initialisation looks like this:
And for sending packets:
The snippet above deals with oversized packets and works well on ESP32 (also tested on ESP32-C3, but for some reason QuickEspNow will not work at all on ESP32-S2 but that is for another issue). The code above finishes/completes without issue on ESP8266 but a few seconds after it is executed soft watchdog triggers a reset.
I managed to dump crash log using exception decoder and it is attached below. Apparently
espnowTxHandle()
stalls somewhere.Do you have any idea what might be wrong?