When calling receive(...) the buffer is filled like:
| len | addr | payload ............... |
It would be nice if buf[0] was the first byte of the payload as an API user. Perhaps len could be returned, as is common with read functions. It's probably interesting to access addr, if address filtering is set to both self and various broadcast addresses, it could be an ref param just like buffer, rssi, and lqi. Should experiment with multiple reads/transfers or something.
An alternative that I'm not sure if it works, would be to change set_packet_length to take ownership of a buffer, rather than just setting a length. This would set the length according to the buffer and use this buffer in receive. For this to work, there would have to be some lifetime voodoo to guarantee that receive(...) is not called again as long as the buffer is borrowed from the API. The buffer could be wrapped in something with methods for requesting address, length, LQI, and RSSI... but it has to have a known lifetime, I doubt it would work, but who knows. If it works, it has the upside that it would only require one SPI transfer.
When calling
receive(...)the buffer is filled like:It would be nice if
buf[0]was the first byte of the payload as an API user. Perhaps len could be returned, as is common with read functions. It's probably interesting to access addr, if address filtering is set to both self and various broadcast addresses, it could be an ref param just like buffer, rssi, and lqi. Should experiment with multiple reads/transfers or something.An alternative that I'm not sure if it works, would be to change set_packet_length to take ownership of a buffer, rather than just setting a length. This would set the length according to the buffer and use this buffer in receive. For this to work, there would have to be some lifetime voodoo to guarantee that
receive(...)is not called again as long as the buffer is borrowed from the API. The buffer could be wrapped in something with methods for requesting address, length, LQI, and RSSI... but it has to have a known lifetime, I doubt it would work, but who knows. If it works, it has the upside that it would only require one SPI transfer.