Make wait for ready and send public available

[mr-sven]

I changed wait_mode_ready and wait_packet_sent to public so that it is possible to implement custom recv and send methods. This is required on ESP to give the IDLE task the possibility to feed the watchdog, because the standard recv function is blocking and randomly the watchdog is triggert because the IDLE task hangs.

[almusil]

Hi, thanks you for the PR. I'm just curious, what prevents you from using is_packet_ready and possibly making something similar e.g. is_packet_sent? I'm not sure that exposing those functions would help because they would still block.

[mr-sven]

I'm monitoring the DIO pin for packet ready, so I don't need to query the IrqFlags2 register in a loop. Exposing the wait_mode_ready is good if you set the device manual to receiver mode. You can omit that, but you implemented this functionality and if somebody uses this, he is not required to implement it again. The major problem is, that you looping is_packet_ready without any delay, which blocks FreeRtos from executing any other task.

[almusil]

is_packet_ready is not a loop, it just reads the register and returns whenever it is ready or not. By exposing wait_mode_ready you won't achieve much because this still loops, it has a timeout, but you don't have any control over that timeout. That's why I would suggest to use is_packet_ready instead of the internal function that is not designed to be used outside.

[mr-sven]

The recv is blocking and looping is_packed_ready: https://github.com/almusil/rfm69/blob/bff675b2b7f8d62570fa8a3c7030eff2311474e1/src/rfm.rs#L216 The problem is not caused by wait_mode_ready, I only want to use it in my custom receive function.

[almusil]

I understand the problem however the function wait_mode_ready is for internal use only and will be removed in future versions. You can workaround that by using the read function directly e.g.

rfm.read(Registers::IrqFlags1)? & 0x80) != 0