allow sending and receiving large packets

[rkreis]

So here's an attempt to implement send/recv for large packets (#18). I tested it with all packet lengths from 1 to 144 bytes, but of course the FIFO threshold, bitrate, SPI clock and latency will have an influence. A few issues remain:

• Looking at my SDR, it seems that some extra bytes are sent, as if packet length is rounded up to a multiple of chunk_size. I haven't investigated this further.
• The interface is different from send/recv because the length byte is automatically included. I think this makes sense because the receive function needs to know it.
• I don't see how to make it work without CrcAutoClearOff.
• wait_while_fifo_exceeds_threshold etc use a crude timeout method to avoid extra delays.
• The interface is rather awkward, with the prefill and chunk_size extra parameters for send_large.
• It's rather complex.

Do you think these can be overcome and we can merge it? With the public register access methods, this could also be nicely implemented in the application code. What are your thoughts?

[rkreis]

I chose not to use with_timeout because the 1ms delay between polls would make FIFO overruns (or underruns) much more likely. I would just like a nicer timeout that's not tied to the SPI data rate and latency, but we don't have a timer we can query, do we?If you're ok with including this, let's get it done as nicely as we can. I'll do some more testing over the next week or so to get the RX as robust as possible. Might even switch over to "unlimited" packet format because it could simplify RX handling - as far as I can tell, the FIFO will always get filled then, and something like a failed CRC check can't get us stuck waiting for FifoThreshold || PayloadReady. Generally, I think the hardware interface is a little awkward there.

[rkreis]

I switched it to a very simple byte-by-byte implementation because I had some reliability issues. This also has a simpler interface. SyncAddressMatch and PayloadReady are not used at all anymore. The reason for requiring the Variable(255) packet format is to disable packet length filtering. With these filters, the length byte is still inserted into the FIFO, even when the rest of the packet is not received. If broadcast is not needed, address filtering could be done using the SyncWord.

Open issues:

• What does recv_large do when the buffer is too small? Because the maximum packet length must be 255, we require a 255 bytes long buffer. We could return an error code, or discard the packet, or truncate it and return the actual length. Right now, it just panics.
• FIFO overrun (RX) and underrun (TX) are not detected. I suspect RX will get stuck in an endless loop, and TX will silently corrupt packet data.
• I should check if there are still extra bytes sent. Using intermediate mode for TX with FifoEmpty exit condition could help if this problem still exists.

[rkreis]

• I added BufferTooSmall and PacketTooLarge error codes. PacketTooLarge makes send_large run without side effects, while BufferTooSmall will discard the packet (even the part that would fit into the buffer). I don't see a use case for returning a partial packet, especially if you can easily make the buffer large enough.
• I changed it to allow zero-length packets. I think the hardware allows this at least for "Unlimited Length Packet Format", but I haven't tested it.
• I also documented that FIFO overruns/underruns are not detected. I don't want to add any guesswork about what might happen because I don't see how that could help anyone.