have a go at using postcard+cobs+crc32 for message encoding

[alsuren]

Postcard already supports COBS out of the box, and crc32 doesn't seem too difficult:

https://github.com/jamesmunns/postcard/pull/17#issuecomment-692815999

• [x] #6 Define a Command enum for all commands that are part of the protocol
• [x] #6 Define serialisation for Command, and use it in hovercontrol
• [x] #7 Make a no_std way to serialize Command and use it in hoverkite-firmware
• [ ] #11 Define deserialisation for Command and use it in hoverkite-firmware
  • [x] Consider the shape of https://blog.tonari.no/rust-simple-hardware-project (protocol requirements seem very similar to ours).
  • [ ] #14 ~Try making the deserialization impl embedded_hal::serial::Read<Command> for CommandReader rather than impl CommandReader.~ causes ownership problems because everything passes around Hoverkite as a block rather than just the required fields. Might need a re-think later on.
• [x] #20 Think about the reverse path:
  • [x] Define [Secondary]CurrentPosition structs + ser + deser.
  • [x] Define [Secondary]LogMessage structs + ser + deser (this might be a bit ugly. Would it be easier to split the different messages into some kind of enum?).
  • [x] Some kind of enum that represents all of the things that hovercontrol might receive on the serial port, and deserialization for this enum.
• [ ] Draw a diagram of the network topology, and add it to the repo.
• [ ] Switch serialization to use serde + postcard + ...
  • [ ] Is it possible to deserialise from impl Read and assert that the correct number of bytes have been read? (see https://github.com/hoverkite/hoverkite/pull/11/files#r625999117 )
  • [ ] Is there a streaming deserialisation framework that doesn't need a contiguous buffer, to save us an extra copy?
• [ ] Delete custom serialisation and deserialisation code

[qwandor]

You can use gd32f1x0_hal::crc::Crc for the CRC, though it could do with some documentation.