Call for Experimentation

[jamesmunns]

This is a call to the kind of people that write connected systems in Rust to try out Ergot between now and the middle of September.

ergot is a messaging library, built on postcard, that I am building to make it easier to have structured communication between tasks, threads, processes, and/or devices of any size, from desktops/servers down to embedded systems. It is certainly not ready for load bearing production use yet, but it won't get there without help, and that's what I'm asking for.

I am willing to call in any favors I can to get you to:

• Read the docs, and tell me if they make sense, or what questions you are left wondering, or if there's a missing gap
• Try the demos, and tell me if they were useful, or what they need to be better
• Open a discussion for any feedback you have, or capture things you think are important for Ergot to do
• Open a Pull Request to improve the docs, improve a demo, or add a feature you want!

I have four weeks of relatively free time, and I intend to use it getting Ergot as usable as possible for as many people as possible. This means I need people to look at it, evaluate it, contribute to it, and give me feedback on what is needed to make it usable.

I'm also streaming on YouTube at the start/end of every Monday/Wednesday/Friday (10:30 and 20:00 CEST), if you want to come and chat live!

[jamesmunns]

Done! #77

[jamesmunns]

Field report: Can we support a fully blocking use case? - I think theoretically yes, but practically today, not yet. We'd need to make sure we have polling APIs, and potentially blocking (using CondVar instead of WaitQueue?) methods.

[jamesmunns]

Field report, I should take these nice diagrams and find a home for them in docs.

[zach-planet-nine]

Howdy! I have a use case for small two-way messages from microcontroller to phone/tablet/desktop. I've been using BLE for this, but would love handing the responsibility of writing responsible code for that to someone else. Gonna dive into the docs tomorrow, but if you feel like this should work on at the very least an esp32 <-> iPhone via Tauri, I should be giving it a go soon.

[jamesmunns]

I'm not certain how it would make the most sense to do ergot-over-ble, but if there's a reasonable way to transfer decent sized frames (32-512 bytes?), or some kind of bidirectional stream of bytes, we can probably make things work!

[SamCastelain]

For BLE there would be two main options, both limited to a MTU of 185 if you are considering iOS.

1. Do the classical "implement a UART over a BLE service". See Nordic UART Service for an example. This works but it isn't really following what GATT was made for.

2. Use a custom L2CAP channel. These are meant for raw byte streams. But as far as I know you would need to get a random channel ID everytime for it and then expose that channel ID over a GATT service so the other side knows what to use. Terminology might not be completely correct here, it's been a while since I looked it up.

You will for all options also be stuck with the Connection Interval concept of BLE. You can only start a transfer every connection interval. So this has a direct effect on latency. In general you can assume 15ms is the lowest you can achieve if you have phones in the mix. But the phone is free to pick a higher a value and you can't do anything about it.

[zach-planet-nine]

You will for all options also be stuck with the Connection Interval concept of BLE.

Thanks for the responses! This is what I'm trying to avoid (I think), and admittedly wireless networking isn't my bailiwick, so I'm a bit behind you guys. I would prefer simply routing messages to known devices on a network rather than dealing with BLE for the whole thing. From the docs it seems that's pretty trivially doable so long as everything's on the same network, so maybe ble just handles getting a new microcontroller onto the network in the first place.

I've read the docs and I think I've more or less got what's going on, but what I'm missing is how discoverability works. Like if I have an endpoint named "foo" and another named "bar," how do foo and bar know about each other?

[HaoboGu]

I read the docs and try to integrate ergot to my project. I found that the eusb demo is a little bit complex and I'm having trouble to understand it, there are some questions I have now:

1. Are the run_tx and run_rx like the background task like usb_device.run()?
2. There are many tasks, pingserver, yeeter, press_listener, led_server, button_worker, I don't really understand which one should I use for a simple PC-request-MCU-response pattern.
3. I use USB for other purposes too, so I have to use STORAGE.init_without_build. This function seems lacking some initialization code of ergot.
4. How can I request from PC? Is https://github.com/jamesmunns/ergot/blob/main/demos/std/ergot-nusb-router/src/main.rs the demo? But the PC side code seems lacking code for press_listener, led_server, button_worker task?
5. For a single endpoint, for example, echoserver, I have to spawn at least 4 tasks(usb, tx, rx, echoserver), am I right? Because I have generics on everything, I have to use join/select for this, which increases the executor's workload when there are many tasks joined. Is this the simples version of an echo server?

join4(
        async {
            // USB task
            usb_device.run()
        },
        async {
            // Rx task
            rxvr.run(RX_BUF.take(), kit::USB_FS_MAX_PACKET_SIZE)
        },
        async {
            // Tx task
            kit::tx_worker::<D, 4096, AtomicCoord>(
                &mut tx_impl,
                OUTQ.framed_consumer(),
                kit::DEFAULT_TIMEOUT_MS_PER_FRAME,
                kit::USB_FS_MAX_PACKET_SIZE,
            )
        },
        async {
            // Echo task
            use core::pin::pin;
            let socket = STACK.stack_bounded_endpoint_server::<EchoEndpoint, 4>(Some("echoserver"));
            let socket = pin!(socket);
            let mut hdl = socket.attach();
            loop {
                let _ = hdl.serve(async |input_num| {
                    // Echo after 1ms
                    embassy_time::Timer::after_millis(1).await;
                    input_num
                });
            }
        },
    );

7. How to add the context of the message processing? Is there an example?

Those questions are from the first 2-hour try from a noob, so forgive me if it's dumb. Thanks for your work on this, I am looking forward to use ergot in the future :D

[jamesmunns]

I'll go over this on the stream at 10:30 CEST today (about 3h from now).

thanks for giving this a try!

[jamesmunns]

Hey @HaoboGu, I spent some time talking about this here: https://youtu.be/lAj68vx8uFc?t=963 - I'll write up some of the responses in a bit!

[jamesmunns]

Issue for the missing USB setup items: #82

[HaoboGu]

Thanks a lot! I'll check later

[jamesmunns]

Questions (see https://bsky.app/profile/jonaskruckenberg.de/post/3lwpx3g7jek24):

• What is the plan for using ergot with mnemos?
• How could other OSs (like k23) use Ergot?

My answer (so far):

Hey! So, the answer is "I'm not sure yet", but I DO want to use ergot to replace the service API currently used by mnemos.

There's likely a couple things needed before that is possible tho, one is "sessionful sockets": docs, which can be used for connections + exclusive access

But, for mnemos, I do want to allow:

• Kernel to Userspace comms, basically using an io_uring-like bidirectional stream as a "network link", then using ergot interfaces across the barrier
• Userspace to Userspace comms, using the kernel as a "router"
• Interdevice comms as well!

One thing that gets funky is that a network interface with service discovery is actually simultaneously a great thing and a terrible thing for a kernel interface: we're definitely going to need a concept of a "firewall" or some kind of access control, but that's true for any kernel.

[krokosik]

I would very much welcome a documentation section for the overhead that ergot introduces vs for example using raw TCP/UDP frames. We use several devices that stream data and throughput is of utmost importance to us and a clear explanation in the docs would help us evaluate the adoption of it vs for example using our own code of having messages that are simply a C array with a message type byte + packet length and raw data afterwards.