Openthread: [spinel] consider updating SPI framing protocol to allow for fragmentation

[darconeous]

The current SPI protocol works pretty well, but it falls short in one key respect: the slave needs to buffer the entire outbound and inbound frames, which means that nominally there is a lot of wasted RAM.

Fragmentation of larger frames (say, >256 bytes) would allow for much smaller buffers to be used, significantly improving SPI memory usage.

I believe this can be implemented with a light-weight fragmentation layer on top of the existing framing protocol. Then this protocol could be easily applied to UART/HDLC-lite connections as well.

[krlo]

Great idea, but please define fragmentation for frames >255 bytes, NOT 256 as often counter register for SPI peripheral is one byte.

[darconeous]

Here is a quick straw-man fragmentation protocol (assumes a reliable frame transport under the hood):

• Fragment frames are limited to a size of 256 bytes. (Actual limit is TBD. Should this be smaller?)
• The first byte is a header byte, leaving a maximum of 255 bytes of data per fragment.
• The least significant bit of the header byte is the "more fragments pending" bit (FLAG_MORE_FRAG_PEND). All other bits are reserved and set to zero.
• Fragmented frames are sent sequentially with the last fragment of the super frame having FLAG_MORE_FRAG_PEND cleared.
• Fragments can be less than 255 bytes long.

[darconeous]

Alternatively, we could re-purpose one of the bits in the SPI header byte. But then we lose our layered approach (not that big of a deal)