Could cause hangs on the way into sleep (and enormous power consumption).
Instead of checking for rx packet length (which only changes at completion)
check if we've received preamble bits but haven't yet received a completed
packet interrupt.
notes:
wait to sleep loop problem
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
Can not send yet, busyRx
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
vs normal run
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
radio wait to sleep, txEmpty=0
Starting low level send (id=0x53fe1dd0 Fr0xe5 To0xff, WantAck0, HopLim3 encrypted)
Completed sending (id=0x53fe1dd0 Fr0xe5 To0xff, WantAck0, HopLim3 encrypted)
Hi, I think the problem you were having building for ESP32 was due to
a funny thing. Notice the #define for INTERRUPT_ATTR. That macro expands
to IRAM_ATTR - which is a special flag the ESP32 requires for _any_ code
that is going to be called from an ISR. So that the code is guaranteed
to be in RAM (the ESP32 uses a clever scheme where the FLASH is actually
high speed serial flash and all reads/writes are actually only happening
to a small number of pages in RAM and they have a driver that is constantly
copying blocks they need into that ram. This essentially how VM works
for desktop computers, but in their case they are paging to FLASH.
But for code that runs in an interrupt handler must _always_ be in RAM
because if you took a 'page fault' for that code being missing in RAM they
can't nicely do their clever VM scheme.
So that's all good. The problem was - apparently GCC for the ESP32 has a
a bug when that attribute is applied in the class declaration. So
I moved it out into the cpp file and all seems well now.
Thomas Göttgens