61–70 of 167 posts
Earlier quoted context omitted.
It doesn't have anything to do with it. It's some nice syntax over cooperative multitasking.
The README should be corrected then. It is currently making a very false claim.
I prefer C for embedded but must admit that's pretty compelling.
This is at the center of a friction point in embedded rust: most of the OSS ecosystem has shifted to this framework, and as a result, is incompatible with, or is high friction if you don't want to make your firmware and control flow Async. This is notable because Rust embedded is nascent and small, so I think splitting the ecosystem along with Async is not ideal. It's also confused some people new to embedded: I regu…
I think it's interesting because they seem to have built some vaguely pretty decent interfaces and drivers. Before that there were some attempts to make a rust embedded HAL but I think they were a bit too basic and didn't seem to get much traction. Also async interfaces are probably the most generic, because you can hook them up to superloops, single-threaded applications, and threaded code relatively easily (at leas…
IMO one of the big reasons Arduino stayed firmly hobbyist tier is because
it was almost entirely stuck in a single-threaded blocking mindset and'
everything kind of fell apart as soon as you had to do two things at once.
Conversely Embassy suffers from being immature with some traits that haven't really been fleshed out sufficiently.
Also check out Ariel OS ( https://ariel-os.org ), which is built on top of Embassy.
Earlier quoted context omitted.
Here's a good technical writeup on latency and jitter (latency standard deviation) for interrupts when it comes to Embassy, FreeRTOS, and RTIC: https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown Obviously if you're working on something truly hard real-time you probably wouldn't be reaching for these tools to begin with, but for the average embedded project it seems you will enjoy quite good latency and jitt…
I've read this, and frankly its comparing apples to oranges. These are not the same things though naively they may appear the same.
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.
Probably off topic, but what's the best way to get started with embedded development? I've been a web developer for over a decade, but I'd really love to try something much lower level, and I'm currently making my way through the Rust book. I've got a Raspberry Pi on the way, but I assume that's not truly embedded development.
I was in the same situation. I've been programming high-level languages for decades now and wanted to get my hands on embedded. I've got friends in my local hackerspace and while you can teach yourself programming those chips, it's good to know whom to ask when you get stuck. You can find a hackerspace near you here: https://wiki.hackerspaces.org/Hackerspaces
I've been programming C and Rust on Wokwi. I even simulates electronic components and stuff like switch-bounce-effects. It's very easy and can be used free. You can even use a local IDE like VSCode(ium) and. I've used it with one project and it speed up my project a lot. https://wokwi.com/
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.
Earlier quoted context omitted.
> superloops I’ve been doing async non-blocking code for decades, but this is the first time I e seen that word used? I’m assume you’re meaning something like one big ass select!() or is this something else? > IMO one of the big reasons Arduino stayed firmly hobbyist tier is because it was almost entirely stuck in a single-threaded blocking mindset and everything kind of fell apart as soon as you had to do two things…
Superloop is common terminology in the firmware space. They are cruder than a giant-state-machine-like case statements(but may use still them for control flow). They usually involve many non-nested if statements for handling events, and you usually check for every event one by one on every iteration of the loop. They are an abstraction and organizational nightmare once an application gets complex enough and is ideall…
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.…
never understood what a watchdog is tho...
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.…
I agree. the type safety that it brings to the HAL. it's a like cushion for people entering this space. never understood what a watchdog is tho...
Watchdogs exist on MCUs but also on some "proper" computers. The Raspberry Pi has one for example.