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
In #26 (comment), a user asked about offering internal interfaces, e.g. the ability to act as a client within the server itself.
My current opinion on this is "no, we shouldn't". I'm leaving this as a tracking issue in case people would like to discuss, or to point them here if they ask how to do this.
This is for a couple of reasons:
First, we would need to EITHER ask the user to pay the cost of ser/de, to allow re-use of the current code, or to use "multiple interface" code discussed in #67; OR we would need to introduce a new path that skips the ser/de parts of the dispatcher. However, if we choose the latter, you could "just" call the blocking or async handler functions directly, if you are able to "manufacture" the context necessary to pass to the functions. spawn handlers are a little more complicated as they are oriented around passing in a Sender, so this isn't a complete solution
Second, my opinion here is that you are better off just writing "normal code" for this, and sharing the resources between your internal tasks and the postcard-rpc server. For example, if you had some SPI sensor, you could wrap it in a mutex, and give one handle to the postcard-rpc server and one to your internal task. Something like:
typeMutexSensor = Mutex<ThreadModeRawMutex,Sensor<Spi>>;staticSPI_SENSOR:StaticCell<MutexSensor> = StaticCell::new();#[embassy_executor::main]asyncfnmain(spawner:Spawner){// ...let sensor:&'static MutexSensor = SPI_SENSOR.init(...);// Set up postcard-rpc serverlet context = Context{ sensor };let dispatcher = MyApp::new(context, spawner.into());letmut server:AppServer = Server::new(
tx_impl,
rx_impl,
pbufs.rx_buf.as_mut_slice(),
dispatcher,
vkk,);// Spawn internal tasks
spawner.must_spawn(my_internal_task(sensor));// ...}// this is a handler for a postcard-rpc endpointasyncfnget_spi_data(ctx:&mutContext,hdr:VarHeader,req:()) -> SensorData{
ctx.sensor.lock().await.read_data().await}// This is an internal task#[embassy_executor::task]asyncfnmy_internal_task(sensor:&'static MutexSensor){loop{Timer::after(Duration::from_millis(100)).await;let reading = sensor.lock().await.read_data().await;// ...}}
The text was updated successfully, but these errors were encountered:
In #26 (comment), a user asked about offering internal interfaces, e.g. the ability to act as a client within the server itself.
My current opinion on this is "no, we shouldn't". I'm leaving this as a tracking issue in case people would like to discuss, or to point them here if they ask how to do this.
This is for a couple of reasons:
First, we would need to EITHER ask the user to pay the cost of ser/de, to allow re-use of the current code, or to use "multiple interface" code discussed in #67; OR we would need to introduce a new path that skips the ser/de parts of the dispatcher. However, if we choose the latter, you could "just" call the
blocking
orasync
handler functions directly, if you are able to "manufacture" the context necessary to pass to the functions.spawn
handlers are a little more complicated as they are oriented around passing in aSender
, so this isn't a complete solutionSecond, my opinion here is that you are better off just writing "normal code" for this, and sharing the resources between your internal tasks and the postcard-rpc server. For example, if you had some SPI sensor, you could wrap it in a mutex, and give one handle to the postcard-rpc server and one to your internal task. Something like:
The text was updated successfully, but these errors were encountered: