search

jamesmunns / postcard-rpc

An RPC layer for postcard based protocols
Apache License 2.0
45 stars 11 forks source link

Support for other transports (SPI, BLE, TCP/IP, ...) #26

Open pperanich opened 3 weeks ago

pperanich commented 3 weeks ago

Thank you for the fantastic work on this library! It significantly reduces the effort to get RPC comms established between a host and embedded device.

Currently, the framework as a whole only supports transport over serial or USB, with the target_server side specifically relying on the embassy-usb driver. I am interested in what it would take to support other transports such as SPI, BLE (using the trouble lib, which abstracts over Bluetooth HCI and is thus more versatile than implementing support for a specific stack like the NRF SoftDevice), or TCP/IP via smoltcp. While I see a clear path to implementing SPI or BLE support on the host_client side, it is unclear how to extend this support to the target_server embedded side. I've loosely been following your blog where it looks like you've been thinking about this on some level already. I hope this issue can serve as a log or discussion place for these implementations.

jamesmunns commented 3 weeks ago

Yep, on the PC side, https://github.com/jamesmunns/postcard-rpc/pull/25 is starting to work towards this, and in the near future I plan to restore "UART + COBS" functionality.

Likely, we will need some kind of similar "Wire" abstraction for the MCU side as well, and I'll need to rework the define_dispatch! macro to be less hardcoded to USB, and instead require you to name some type where T: Wire or something like that.

I'm open to PRs that make this happen, ideally starting with adding back UART+COBS, but also open to a PR that refactors this in a way where supporting two different transports (ideally without a lot of duplicated dispatcher code) is possible.