You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would be nice to have "host_server" and "target_client" libraries of postcard-rpc. So the MCU would be the one initiating the request to the PC and the PC would answer the rpc calls. Everything else would be the same.
I asked @jamesmunns via Matrix regarding this, here are his responses:
So: postcard doesn't have code for this yet. The protocol has nothing special that forces it to be the orientation it is, that's just how I normally set it up.
I'm very open to having "host_server" and "target_client" libraries: at least the latter I will also want for MCU-to-MCU comms, but I don't have any plan to build it right now.
I also asked about whether there are some big roadblocks in the way, and James responded with:
nah, there's sort of practical limitations maybe, depending on what route you go:
honestly the host_client code might be possible to just support with alloc, you might be better off with a different channel (tokio channel is used, could be cfg'd to something else), but it's really not THAT heavy, though I'm not sure how much "slack" you have wrt RAM usage on your current app
if you want to make a much lighter client that can only support one "in-flight" request at a time, that'd probably make it much easier to handle no_std, but would be more "novel" work
for the PC server, it'd probably be pretty easy to make a dispatcher that takes like HashMap<Endpoint, fn() -> Box<dyn Future<Output = Result<Vec, Something>>>, as a dispatcher
I'm currently a bit on a tight schedule with my current client, so I opted for implementing my own very simple rpc logic on top of postcard for now, as this was just quicker to do. But I'll probably revisit this postcard-rpc as soon as our rpc interface grows larger...
The text was updated successfully, but these errors were encountered:
Also noting that by adding a "target client" library, this would unlock MCU-to-MCU comms. I continue to be very interested in adding this, but haven't needed it, so haven't taken time to design it.
I'm very open to PRs or sponsorship if folks are interested in making this happen :)
Note that the changes between v0.7 and v0.10 makes it possible to have a host_server (there is a test_channels implementation that runs on the host for testing, using a tokio channel as the "wire").
I don't have a target_client implementation yet, but I am open to implementations of this still.
I would be nice to have "host_server" and "target_client" libraries of postcard-rpc. So the MCU would be the one initiating the request to the PC and the PC would answer the rpc calls. Everything else would be the same.
I asked @jamesmunns via Matrix regarding this, here are his responses:
I also asked about whether there are some big roadblocks in the way, and James responded with:
I'm currently a bit on a tight schedule with my current client, so I opted for implementing my own very simple rpc logic on top of postcard for now, as this was just quicker to do. But I'll probably revisit this postcard-rpc as soon as our rpc interface grows larger...
The text was updated successfully, but these errors were encountered: