Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embassy: Modern embedded framework, using Rust and async

github.com

Post reply on HN
Print view View original

121–130 of 167 posts

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

#121

Post by cat-whisperer »

5d41402abc4b wrote: post #71
VorpalWay wrote: post #70

Earlier quoted context omitted.

A watchdog is a piece of hardware that will automatically restart the chip if it detects the code as being stuck. The way it detects this is that you have to poke a register of the watchdog every so often, and if the register hasn't been poked for a certain timeout (usually configurable), the chip is restarted. Watchdogs exist on MCUs but also on some "proper" computers. The Raspberry Pi has one for example.

>Watchdogs exist on MCUs but also on some "proper" computers All modern computers have watchdog. You can check your logs `journalctl -b | grep watchdog` https://access.redhat.com/articles/7129255

mac’s too?

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

#122

Post by k__ »

devlolz wrote: post #115
k__ wrote: post #114

I was pretty stoked to find this a month ago. Sadly, I bought an nRF54L15 board to start my embedded journey, which isn't 100% supported yet :/ Now I have to wait. I'm not gonna go back to C :D

What parts are you missing? (I'm working on the nrf54l support so just curious to know what is blocking you).

Last time I checked, I couldn't get my dmic running. Something about PDM being missing.

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

#123

Post by carlkcarlk »

I’ve been enjoying Embassy most at the application pattern layer: long-lived device tasks that hide timing and coordination behind a small, typed async API. For example:

loop { let btn = ir.wait_for_press().await; // use btn }

Meanwhile the compiler builds the state machine for you.

I think this style is an emergent property of async + no-std that hasn’t really been collected or named yet. A lot of discussion focuses on HALs, bring-up, or executors, but less on how people structure applications once those pieces are in place.

Brad Gibson and I talked about some of these ideas in this (free) article on how Embassy shines on embedded devices: https://medium.com/@carlmkadie/how-rust-embassy-shine-on-emb...

I’ve also started an open repo to experiment with and document these patterns: https://github.com/carlkcarlk/device-kit

Would love links to other repos that use Embassy at this higher, application-oriented level.

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

#124

Post by throwup238 »

cat-whisperer wrote: post #121
5d41402abc4b wrote: post #71

Earlier quoted context omitted.

>Watchdogs exist on MCUs but also on some "proper" computers All modern computers have watchdog. You can check your logs `journalctl -b | grep watchdog` https://access.redhat.com/articles/7129255

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.

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

#125

Post by ericwood »

sgt wrote: post #94

My only question is - is this tinker friendly? C is tinker friendly, it's not all about correctness and so on. Not that I mind correctness, but I want to play with this and maybe do some minor hobby projects with limited cognitive load. Otherwise I'd just do FreeRTOS, which is also a good option.

Yes and no, and the answer will depend a little bit on your background. It's Rust, and the learning curve around that still exists. The HAL does a very good job at papering over some annoying details, e.g. if you're working on STM32s you'll be able to get things working without having to dig into the monstrous clock trees and timer peripherals. I found one of the biggest learning curves to be dealing with shared mutable state; embassy offers lots of primitives and tools for dealing with this that are more approachable than you'd encounter with a vanilla embedded Rust project, but there's a little bit of a time investment to learn them and you'll find yourself reading a lot of example code.

Once you get the basics, though, it's very productive and I've found it surprisingly easy to write building blocks I can reuse across a wide range of hardware projects and MCUs!

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

#126

Post by u8080 »

5d41402abc4b wrote: post #92
u8080 wrote: post #89

Earlier quoted context omitted.

> lengthy errata doesn't mean anything In STM32G0 for example, there is "SPIv1" peripheral which has very critical implementation bugs which can get SPI to completely stuck until reset by RCC. There is very brief mention in STM errata about this, I had to dig up forums and dance up with SWD around this.

Which G0 part is this? Can you point me to one of these forum posts?

Sorry, I was digging on that too much time ago and haven't saved any links. AFAIR, there is permanent busy state in certain conditions when functioning in SPI slave mode, unablility to reset TXFIFO/RXFIFO and some edge case with DMA and TXE/BSY when DMA failed and you don't know how many bytes are in RxFIFO.

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

#127

Post by the__alchemist »

progbits wrote: post #96
vablings wrote: post #48

Earlier quoted context omitted.

RP2040 is really great experience. You can get a debug probe (either buy or make yourself with another RP2040) I cant tell you how awesome it is with minimal setup to get - Full print logging - Option to attach a debugger - cargo r will just flash your code and reset the RP2040

I wish they had smaller modules with wifi (pico w is too large for many of my usecases). That's the only reason I keep using ESP-C*. It's getting better but the esp-rs tooling has a lot of very rough edges.

Same. Non-Espressif manufacturers have been sleeping on Wi-Fi capability. Nordic now has a chip, but I haven't tried it. I have been using an Esp running Esp-Hosted, connected to the main MCU over SPI.

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

#128

Post by DetroitThrow »

fried-gluttony wrote: post #99
sp0ck wrote: post #75

Earlier quoted context omitted.

It's already in use at least it automotive. If you are not working with safety critical systems (ADAS type) Rust and to some extent embassy is already in the wild. Companies like ETAS ( https://www.etas.com/ww/en/ ) or Ferrous ( https://ferrous-systems.com ) are working to certify Rust and some crates (embassy is there) to be used with safety critical components. It's not question if but when it will be used. Volvo,…

Do you have any (soft) evidences, that actually embassy is used in safety-critical applications? I think that is quite more difficult to qualify the whole of embassy with the HAL, executor and the other components used. Ferrous is just the qualified toolchain incl. core std. and some other libraries. Additionally a question is how well it integrates e.g. with ARM self-test libraries for the platform safety. I know th…

A handful of companies participated in this. It seems they all are working already with it or working towards it: https://rustfoundation.org/media/announcing-the-safety-criti...

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

#129

Post by pflanze »

adastra22 wrote: post #106
apitman wrote: post #61

Earlier quoted context omitted.

The claim is you can get embedded concurrency without an OS. Do you disagree? I prefer C for embedded but must admit that's pretty compelling.

The claim is it "obsoletes the need for a traditional RTOS with kernel context switching." I don't think the authors understand what an RTOS is, because it has very little to do with concurrency. It is about providing hard guarantees about execution timing of interrupt events. E.g. you need to poll an input port every 20ms, or something like that, because that's when the signal will be on the wire. Not "Please wait a…

> So AFAICT Embassy doesn't do this at all?

I haven't used Embassy, but the README mentions "Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities so that higher priority tasks preempt lower priority ones" and links to an example that shows how a higher priority task runs even though a lower priority one runs a long time job (does not yield), thus understanding and infrastructure seems to be there.

So, Embassy may in its entirety replace an RTOS / be one, but it's not the async mechanism that can provide the RT part (and I guess you're right to point out the dangerous sentence as it could mislead people to use only async and believe it's RT).

OTOH the sentence would be right if it were something like "async multitasking is an alternative to preemptive multitasking, and can replace the use of a preemptive OS if real-time guarantees are not needed (note that Embassy separately allows running multiple executors to allow to pre-empt tasks running in lower-priority executors)". They should probably also describe what the reason for not needing per-task stack size tuning is.

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

#130

Post by dirbaio »

adastra22 wrote: post #24

> It obsoletes the need for a traditional RTOS with kernel context switching Uh, what does async have to do with hard real-time guarantees?

(Embassy dev here)

You can get preemptive scheduling of async tasks with InterruptExecutor. You create one executor for each priority level, then spawn the tasks in the right one. The latency of the executor and the compiler-generated async state machines is predictable, so you can use Embassy for hard real-time work. See example: https://github.com/embassy-rs/embassy/blob/main/examples/nrf...

Additionally the executor has support for scheduling tasks by priority or deadline within a single priority level. (in latest git, will be in next crates.io release)

Post reply on HN