91–100 of 167 posts
> It obsoletes the need for a traditional RTOS with kernel context switching Uh, what does async have to do with hard real-time guarantees?
Earlier quoted context omitted.
> The flip side is that their errata is lengthy Just like security bugs, lengthy errata doesn't mean anything. A popular MCU will have bigger errata sheet because it gets more eyes on it. >documentation from STM is poorly organized and spread out over a zillion different documents The spreading out over multiple documents is good organization. You don't want to combine your datasheet, reference manual and appnotes in…
> 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.
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 kee…
UPDATE: it seems so, using a second executor. There is "embassy_sync" to communicate.
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.
Earlier quoted context omitted.
The README should be corrected then. It is currently making a very false claim.
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.
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?
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
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…
Even data structure libraries, like embassy-sync, all have `try_` methods, which would allow for polling usage outside of async.
There's no mandate to use async - and helping folks that DO see value in it (which is a LOT of folks), isn't "splitting the ecosystem" - it's people doing things the way they like to do it. Embassy still works very hard to support folks who DON'T want to use async, to avoid duplicated work. There's nothing stopping you from preferring to write and maintain your own HALs, I know you have been for a while! But it's not something that people necessarily have to do, even if they aren't interested or don't prefer async!
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
Earlier quoted context omitted.
>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.
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,…
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
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.