Comment by jpgvm
1 day ago
I'm loving Embassy.
Coming from a lot of bare metal C and FreeRTOS it finally feels like embedded is getting a toolchain that is actually modern and better.
Some of that isn't just Embassy but the surrounding ecosystem, some highlights:
* probe-rs w/cargo run integration
* defmt logging (combined with probe-rs and rtt it's very nice)
* embedded_hal (and in my case stm32-rs)
I have also tried RTIC but I decided to keep going with Embassy because I like the async ergonomics more and the few times it's been a downside/missing functionality (no existing async driver for specific peripherals basically) it wasn't to hard to implement what I needed.
I was surprised it just works out of the box on OS X also, generally speaking I would always end up having to use Linux to develop for embedded. Being able to compile on fast Apple M hardware and then run immediately with zero friction is awesome.
It took a little bit to get my head around how to share access to peripherals etc but once I did it's been great and it's nice to know that locking semantics are essentially enforced at compile time so it's actually not possible to have 2 things stomping over the same bus etc which can sometimes be a very hard bug to track down when working with big and fast SOCs.
Other really big aspect Embassy has been good for is really high quality USB and networking stacks. I am using both the USB stack (for PLDM over USB) and Ethernet w/the TCP stack in embassy_net and both have been flawless.
Only real downsides I can think of are it can sometimes be hard to onboard folk that are used to copy/paste from vendor examples and sometimes communicating and debugging with vendors themselves when they aren't familar and won't engage unless you can reproduce on the vendor HAL.
So overall really happy with it and I highly recommend trying it out especially if you are in the STM ecosphere.
>it finally feels like embedded is getting a toolchain that is actually modern and better
Last time i tried embassy, it pulled over 100 dependencies just to build a blinky. Its great for hobbyist programming but i doubt its going to be used in any industrial application any time soon.
In all seriousness, why is that a problem? Surely for embedded, the size and hardware usage of the resultant binary is what matters, not the size/number of tools used to build it? I get that a lot of people worry about supply chain attacks right now (and that's fine, everyone should be thinking about how to mitigate that problem/reduce it) - but going back to a world where code re-use is significantly less usable isn't likely to magically make everything better, that has trade-offs too - particularly if (as plenty of people clearly do) they want a modern dev experience for embedded hardware.
>why is that a problem
Supply chain attacks. There are also regulatory requirements to keep track of your tools.
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, Renault and some Chinese brands already ship cars with Rust embedded components in non safety critical path.
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 that sonair [0] is actually using Rust in the safety critical path. Toyota Woven [1] is for now just using it in infotainment and non-safety applications.
I am closely monitoring the space, as I am currently evaluating to use Rust and potentially embassy for a safety-critical embedded product myself. I hope to this way also contribute to safety-critical Rust usage. If anyone has further information or just wants to exchange ideas, I'd be super happy to! [0] https://www.sonair.com/journal/leading-the-way-for-safety-ce... [1] https://filtra.io/rust/interviews/woven-by-toyota-nov-25
1 reply →
A lot of those dependencies are from the same project, though. It's just split into multiple crate so you don't need to pull in one mega-lump of code for everything.
(Also, I am currently using it for an industrial application)
Can it use multiple cores, eg on the ESP32? It doesn't so say on the landing page.
UPDATE: it seems so, using a second executor. There is "embassy_sync" to communicate.
Absolutely. I'm using it on RP2040, and it's actually superfun to have real low-level code working in parallel.
In my case, one CPU is doing the CAN-based communication and the device control loop, and the other core is providing the IP-based interface with SNMP-based monitoring.