RPC improvements

[pranav12321]

what

1. Checksums

• there's some context here
• a [Transport wrapper in the style of the multiplexed I/O transport wrapper](TODO: link) is probably the way to go for something like this, signaling error when there's a checksum mismatch and otherwise peeling the checksum off of the packet

2. Step function counter

• (I think this is about message numbering for use in the context of deduplicating received messages; if so there's a little context in this ramble)
• @pranav12321 please correct me if this is actually about other stuff

3. Stress tests and error handling

• it's a bit dated but the basic idea described here still seems like what we'd want; a host-side RPC setup with some transport middleware that introduces different kinds of errors: bit-flips, timeouts, dropped bits/bytes (which we'd then drive with random RPC messages while expecting the ultimate in-order list of sent request messages/received request messages and sent response messages/received response messages to correspond exactly)

4. DMA HAL traits and UART break line feature

• there's much we've written about using DMA for the transport layer: there's the initial braindump, there's notes from Slack in 2021 (copied here so we don't lose them, please excuse the formatting), and probably lots of other stuff I've forgotten about
• the best resource at this point is probably Pranav's prototypes in the embedded-experiment repo: 1, 2, 3, 4, 5
• https://crates.io/crates/embedded-dma
• Right now the DMA impl just uses a custom trait based off an embeddedicon tutorial. But would be nice to keep consistent with the HAL traits we use. Specifically the task is to make an embedded-dma impl of bbqueue. Also figure out and fix release optimization issues that the TM4C impl currently gives

5. Potential support for wireless communication Sub GHZ bandwidth

• To create transport trait implementations for AT command interface (could be used for a variety of physical layer schemes Sub GHZ, Bluetooth, 4G LTE… Vague but should explore more (potentially higher layers of OSI too)

steps

• [[ steps ]]

where

branch: N/A, this is a tracking issue

open questions

[rrbutani]

@pranav12321 just to be sure: by step counter you mean a sliding window-esque message numbering scheme (probably something closer to stop-and-wait ARQ since we never have more than two messages in flight) that lets us safely retry non-idempotent messages on error?

[rrbutani]

I think this is a good list of RPC related stuff we'd want to explore in the future!

All of 1-4 seem like well-scoped self contained tasks that would be great candidates for issues/PRs of their own (that can be tracked by this issue) when work begins on these tasks.

5 does seem like it should have it's own issue though; I'm a little fuzzy on what exactly it entails but that's okay.

[rrbutani]

@pranav12321 I've filled in some context on the original issue message; please feel free to edit/add to it