Mostly working receive implementation

[linguini1]

Summary

This PR introduces the logic to receive packets on the RN2483. Currently, the implementation works by putting the radio into an infinite receive mode and then waiting for an incoming packet. When the packet is received, it is converted from the ASCII hex representation into binary and put in the user's buffer.

The read function indicates EOL by returning 0 bytes. The way this is performed is by setting a receive flag to true within the device structure. If the read function is called when f_pos is greater than 0 but receive is set to false, we can be sure that a packet was returned from the last read call and now return 0 to indicate EOF (or end of packet).

This receive flag is also good for if a packet is received which is larger than the user buffer. If the receive flag is true, we should just start reading from the UART buffer as if there's a packet there and we've already received the radio_rx header. This logic hasn't been implemented yet.

Impact

One step closer to a completed driver. Also enables testing transmit code between NuttX devices.

Testing

I transmitted my callsign from the COTS Pictail board and tried using cat /dev/rn2483 to receive on the NuttX device (Pico W). I was able to receive my call sign multiple times in a row.

I noticed that if I boot NuttX after starting the transmitter, the radio device driver fails to receive all the time. I haven't resolved this yet or investigated why.

[linguini1]

I also accidentally auto-formatted the file so the diff is huge because my settings are different from Justin's. We'll fix that before we merge to upstream.

[JustinDMorrison]

Is the sizeof(response) - 1 to account for the radio not using the null terminating character?

[linguini1]

Exactly, this way the response buffer will always contain a null terminator, which allows us to safely use strstr.

[JustinDMorrison]

What is the significant of the number 4294967245?

[linguini1]

This is the amount of seconds that the MAC layer is paused for. In the datasheet it actually says it should return 4294967295, but I checked our old code and it seems we've always had it as 4294967245. It's also what the radio responds with so 🤷

[linguini1]

This could probably be a #define though to be less of a magic number and give it a name.

[JustinDMorrison]

Just a sidenote, we should figure out a solution for the formatting as it makes reading what actually changed in these pulls much harder.

[linguini1]

I agree; we could put a clang-format configuration option in, but the problem is that I have not found a format configuration that matches the NuttX style guide. The best solution is just to disable formatting I think and do it by hand. Kinda sucks so other solutions welcome.

[JustinDMorrison]

Besides the questions I had, looks good to me. This would have taken me much longer to write so it was a good idea for you to do it. Also, we really should decide on formatting.