Live data from Hacker News

Embassy: Modern embedded framework, using Rust and async

github.com

161–167 of 167 posts

Re: Embassy: Modern embedded framework, using Rust and async

#161
post #146

Earlier quoted context omitted.

A way to implement coroutines in C is via protothreads. I admit that they are a bit hacky - but you can get quite far with them. I used them to implement an Esterel/Blech like environment: https://github.com/frameworklabs/proto_activities

Protothreads are amazing, but really expose you to a lot of subtle bugs. I would not recommend them for any new projects if something like async rust or an RTOS are options.

Yeah this was exactly my conclusion at the time. It's a cool trick but I just don't think I wanna write a serious system in a special half-language like that.

Re: Embassy: Modern embedded framework, using Rust and async

#162
post #158

Earlier quoted context omitted.

I'd be happy to hear some of the differences if you don't mind. Both Embassy and FreeRTOS are often used to organize the various tasks you want to perform in an embedded context so I think it's fair to compare them. I know their implementations and behaviors can be quite different, but I'd like to hear more about what makes this an apples to oranges comparison.

Show me how time slicing or deadline scheduling would work with multiple priorities (InterruptExecutor's) involved. Show me how a task in an InterruptExecutor would priority boost a task of a lower priority, switch to it, then switch back to free up a locked resource. I don't see how these things are feasible in Embassy. There's a large number of things that the cooperative scheduler can't do. Maybe you don't need th…

With an NVIC you essentially have a context switching realtime scheduler in hardware. With appropriate configuration of it you can achieve all things you mention here (though I don't know if embassy has a mechanism for priority inheritance in its current primitives for this kind of thing).

Re: Embassy: Modern embedded framework, using Rust and async

#163

Earlier quoted context omitted.

What I'm seeing is an Embassy dev giving hard evidence of how this can be used for real-time tasks ironically proving that the weirdly upset people, who are claiming no one here knows what they are talking about, are in fact the ones who don't know what they are talking about.

Hey: for this particular thread, the example claim in question is It obsoletes the need for a traditional RTOS , which isn't true. See elsewhere in this comments section as well, there are several good examples.

And you can see plenty of discussions where people claim this but there are plenty of counters from others. I personally think you'd be hard pressed to come up with a situation which an RTOS could do and embassy-rs's approach would be fundamentally incapable of (at least on reasonably modern microcontrollers: as I've been banging on about in other comments: an NVIC is a really useful piece of hardware).

Re: Embassy: Modern embedded framework, using Rust and async

#164
post #158

Earlier quoted context omitted.

Show me how time slicing or deadline scheduling would work with multiple priorities (InterruptExecutor's) involved. Show me how a task in an InterruptExecutor would priority boost a task of a lower priority, switch to it, then switch back to free up a locked resource. I don't see how these things are feasible in Embassy. There's a large number of things that the cooperative scheduler can't do. Maybe you don't need th…

With an NVIC you essentially have a context switching realtime scheduler in hardware. With appropriate configuration of it you can achieve all things you mention here (though I don't know if embassy has a mechanism for priority inheritance in its current primitives for this kind of thing).

How would time slicing work?

Re: Embassy: Modern embedded framework, using Rust and async

#165

Earlier quoted context omitted.

mac’s too?

“All CPUs” would probably be 99.9999% accurate. It’s just one of those fundamental functions you want in a processor. Whether it’s exposed in the OS is a different matter.

AMD doesn't have it. I just confirmed by grepping through dmesg and journalctl -b, the only time it appears is due to UPS driver notifications (unrelated).

Re: Embassy: Modern embedded framework, using Rust and async

#166
post #108

Earlier quoted context omitted.

Yes, but those are done in software

There's generally at least one watchdog device available in most PCs delivered in last decade, but it's not always utilized. Essentially at one point an intel southbridge integrated a basic watchdog on all models, and it started to just... be included. So these days you can find a variation on the TCO timer watchdog in most PCs, even if the exact implementation varies so we now have a bunch of drivers for the differe…

Linux doesn't see one on my Ryzen 5600X desktop at least. My Intel Skylake Thinkpad does seem to have two though (iTCO as well as INT3F0D, not sure what that is, but if I interpret the files under /sys correctly it belongs to the LPC/eSPI controller PCIe device, while the TCO watchdog is found under the SMBus PCIe device).

In both cases they do have software watchdogs (NMI based) which relies on a hardware timer triggering an NMI in the kernel. But that relies on the NMI handler still working, which is not as good as a real HW watchdog.

Re: Embassy: Modern embedded framework, using Rust and async

#167
post #108

Earlier quoted context omitted.

There's generally at least one watchdog device available in most PCs delivered in last decade, but it's not always utilized. Essentially at one point an intel southbridge integrated a basic watchdog on all models, and it started to just... be included. So these days you can find a variation on the TCO timer watchdog in most PCs, even if the exact implementation varies so we now have a bunch of drivers for the differe…

Linux doesn't see one on my Ryzen 5600X desktop at least. My Intel Skylake Thinkpad does seem to have two though (iTCO as well as INT3F0D, not sure what that is, but if I interpret the files under /sys correctly it belongs to the LPC/eSPI controller PCIe device, while the TCO watchdog is found under the SMBus PCIe device). In both cases they do have software watchdogs (NMI based) which relies on a hardware timer trig…

Apparently it depends to a little bit on how the motherboard is designed, theoretically SP5100 watchdog which is part of the CPU logic in recent ryzens, apparently, is supposed to be enabled if the motherboard is designed with IPMI in mind.

For whatever reason, it's enabled on my laptop despite it obviously not having IPMI support :)

Post reply on HN