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

131–140 of 167 posts

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

#131

Post by baby_souffle »

ghotli wrote: post #43
hannesfur wrote: post #7

I am a big fan of the embassy project and it’s a great example of why async Rust is so great: Because this is possible. It works without a heap, is a really low cost abstraction and you can do stuff concurrently on a single core chip (where you can’t just spawn a new “thread”) and you don’t have the complexity of an RTOS. I believe there is a great future for embassy ahead and it’s so great how far the team has come.…

If you had to pick a MCU to try this out on, do you have a preference for a devkit to test this with?

Nordic nrf series of chips are ubiquitous, cheap, really well documented and have very good support for the Bluetooth side of things in embassy.

If you don't need any of the wireless radio stuff, I think the raspberry pi microcontroller family is also ridiculously well supported in rust and it's possible to get one of the newer raspberry pi microcontroller is complete with ethernet and several megs of flash for not even 10 bucks.

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

#132

Post by inferiorhuman »

NooneAtAll3 wrote: post #118
inferiorhuman wrote: post #85

Earlier quoted context omitted.

Of note neither the debugger nor user USB port on that board work with ARM Macs (guess how I found that out). You can connect it to a hub as a workaround but that may lead to data corruption (per the errata). Also worth noting that the discrete STLink V3 dongles also use the F7 for USB stuff. Also also worth noting that not all of the Embassy examples are set up to work with Nucleo boards. It's an odd choice but it i…

...how the heck did Apple break a USB port of all the things?

Considering the USB errata for the F7, I assume they didn't.

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

#134

Post by vacuity »

the__alchemist wrote: post #32
bschwindHN wrote: post #21

Earlier quoted context omitted.

In my experience, most of embassy's HALs support blocking variants as well. I don't quite understand the opposition to async in this context though. Embassy's executor is quite nice. You get to write much more straightforward linear code, and it's more battery efficient because the CPU core goes to sleep at await points. The various hardware interrupts then wake up the core and notify the executor to continue making…

My general 2c on this, in context with my observations in rust embedded: I think you are overestimating the difficulty of doing these tasks without Async. I point out again, that the Async vs blocking meme, while widespread, is not accurate. There is nothing about Async that makes it more battery efficient than non Async code. Hardware interrupts, sleep, or non-blocking operations are neither unique to Async, nor dif…

Rust's async is reminiscent of state machines, which are universal. The issues with the experience come from accidental complexity, in the language or the library ecosystem.

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

#135

Post by ecalifornica »

idan wrote: post #51
ghotli wrote: post #43

Earlier quoted context omitted.

If you had to pick a MCU to try this out on, do you have a preference for a devkit to test this with?

Also espressif RISC V mcu's like the ESP32-C3 and -C6 are fantastic. Some Nordic MCUs are easy too, specifically nrf52840. Have fun!

I'll second this, Embassy on the ESP32-c6 is great.

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

#136

Post by bjackman »

carlkcarlk wrote: post #123

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…

This isn't just useful for high-level application logic! (If I'm catching your drift from "the compiler writes the state machines for you).

I used to write extremely low-lebel NIC firmware that was basically a big bundle of state machines. Rust wasn't ready back then but I was desperate for something like coroutines/async. I think it would have been incredibly valuable.

(There are tricks to do coroutines in C but I think they're too hacky. Also, back then we believed that RTOS threads with their own stack were too expensive, in retrospect I'm not sure we ever entirely proved that).

I may be naïve in this case but I think it would also have been super useful for the high level protocol stuff. Like: 802.11 association flows. If we could have just spun up a Tokio task for each peer, I feel the code would have been an order of magnitude smaller and simpler.

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

#137

Post by progbits »

yonatan8070 wrote: post #100
progbits wrote: post #96

Earlier quoted context omitted.

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.

You've got boards like the Seeed Studio Xiao with an RP2040, that board is absolutely tiny!

The 2040/2350 ones don't have wireless radio.

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

#138

Post by unnamedd »

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.

It is a little bit complicated to start and understand how the series ESP-S* works, but as soon you do, everything gets better. It does have Wi-Fi and Bluetooth capabilities and also can be very small. A good example are the Adafruit Qt Py series. I am currently working with the Adafruit Qt Py (ESP-S2) and I am in love to that board. This one, doesn’t have Bluetooth, but the S3 does.

Because of the Xtensa, you need to use a special fork of Rust maintained by Espressif, but worth a try.

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

#139

Post by uxp100 »

superblas wrote: post #33
devilsdata wrote: post #27

Earlier quoted context omitted.

I don't think a regular Raspberry Pi counts as embedded, although from Embassy's documentation, there is a version of embassy for the Rapberry Pi Microcontroller. https://docs.embassy.dev/embassy-rp/git/rp2040/index.html https://www.raspberrypi.com/documentation/microcontrollers/

I think you’re aware of this already but for everyone else: There’s different kinds of embedded. What traditionally was referred to as embedded is microcontrollers (e.g., 32-bit ARM Cortex M devices like the STM32 or an NXP IMX106x chip ). A configuration for a Cortex-M7 chip (that some may consider on the high end of traditional embedded) is a 600MHz clock, 1MB of RAM, and 4MB of flash memory. These run either bare…

I don’t think that is exactly accurate. But you know, like close enough, describes all my work. Just pointing out that something like an industrial system running win ce on PowerPC or x86 has been within the definition of embedded for a long time. Embedded Java was/is a thing. Both extremely non-central examples, but what’s new is how cheap the hardware is, embedded has always included more sophisticated OS’ and more than micros.

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

#140

Post by a456463 »

adastra22 wrote: post #107
kahlonel wrote: post #91

Earlier quoted context omitted.

99% people in this thread have no idea what you mean. And that’s the reason projects like these make it to frontpage every other day and have hundreds of upvotes/comments.

And you are downvoted for understanding the issue, of course.

Yup! Which is also the reason why I distrust projects like these in general: bold claims when there is nothing to be backed up with. What else is hiding behind such bold claims?
Post reply on HN