81–90 of 167 posts
Another reason why async Rust is great: https://rtic.rs/ "The hardware accelerated Rust RTOS" -- it can use your interrupt controller as a scheduler.
Isnt' that how schedulers always work?
Earlier quoted context omitted.
STM is popular because their lineup is cheap, offers a lot of features, and the documentation is readily available. The flip side is that their errata is lengthy, the Rust HAL is complex to support lots of different designs under the same product names, the documentation from STM is poorly organized and spread out over a zillion different documents, and Mac compatibility needs a gigantic asterisk. You can also get a…
> 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…
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.
> The spreading out over multiple documents is good organization.
No, it's really not. It's things like reading up on a peripheral in the reference manual and then trying to figure out which pins you can use with it. Some vendors will put that in the section with each peripheral, most will include a table within the RM, and STM splits it up into multiple documents — per variant within a family because the families are often loosely related.
None of this stuff is offered up in printed form, they could at least hyperlink it (whether intra- or inter- document).
It's not that surprising really. You've gotta cut costs somewhere.
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.
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…
Supply chain attacks. There are also regulatory requirements to keep track of your tools.
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 would recommend getting a ST nucleo board over raspberry PICO or ESP32. The nucleo boards have integrated SWD programmer which makes flashing easier. You can also use it to debug your code. Try to get one with onboard USB port (like https://www.st.com/en/evaluation-tools/nucleo-f767zi.html ) so that you can build USB projects.
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 is what it is.
Earlier quoted context omitted.
On the flip side, the stm32 firmware hello world from cubeide caused temperature spikes due to spinning. Embassy uses power states efficiently to reduce power draw and temp when nothing is scheduled. It is a huge tangible benefit to use async executors for firmware and I hold the strong belief that it should become the norm for general purpose uC firmware.
There is nothing unique to Async about this: You just put a cortex_m wfi in the main loop, or depending on the STM32 variant, set the sleep or stop bits and related.
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…
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. Yeah, no. From all outward appearances STM stuff is basically rushed to market, fix the bugs later. We're talking basic shit like xyz clock input or watchdog straight up doesn't work. More advanced stuff like one of their USB controllers straight up doesn't enumerate with ARM Mac…
I've yet to see a MCU vendor ship without bugs. At least with ST, the MCU is very cheap.
>USB controllers straight up doesn't enumerate with ARM Macs
I've seen USB devices struggling to enumerate on Mac/IOS devices before. This feels more like an Apple bug to me considering how they work very well on Linux, Windows and Android.
Earlier quoted context omitted.
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. Yeah, no. From all outward appearances STM stuff is basically rushed to market, fix the bugs later. We're talking basic shit like xyz clock input or watchdog straight up doesn't work. More advanced stuff like one of their USB controllers straight up doesn't enumerate with ARM Mac…
>rushed to market, fix the bugs later I've yet to see a MCU vendor ship without bugs. At least with ST, the MCU is very cheap. >USB controllers straight up doesn't enumerate with ARM Macs I've seen USB devices struggling to enumerate on Mac/IOS devices before. This feels more like an Apple bug to me considering how they work very well on Linux, Windows and Android.
I've yet to see a MCU vendor ship without bugs. At least with ST,
the MCU is very cheap.
This feels more like an Apple bug to me considering how they work very
well on Linux, Windows and Android.
Meanwhile I've been using Macs on and off since before USB came around and this is the first USB device I've found that glitches out like that. Given that Apple uses off the shelf USB silicon (TI) and the complaints about STM's older USB FS peripherals I came across I'd fully believe it's an STM problem.
What is entirely STM's fault is that they still market the F7 based devices (ST Link, Nucleo, etc) as being Mac compatible. They've also skipped out on putting that fun little wart into the F7 errata.
Earlier quoted context omitted.
STM is popular because their lineup is cheap, offers a lot of features, and the documentation is readily available. The flip side is that their errata is lengthy, the Rust HAL is complex to support lots of different designs under the same product names, the documentation from STM is poorly organized and spread out over a zillion different documents, and Mac compatibility needs a gigantic asterisk. You can also get a…
> 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…
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.
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.
Raspberry Pi lets you play with GPIO which is a big aspect of embedded (even if it's running Linux instead of FreeRTOS or whatever). If you want to take things a bit closer to bare metal, check out ESP32 boards. Super cheap from China and you can find them with all sorts of cool form factors with lipo battery chargers, screens, etc.
If you want to understand how interacting with peripherals and hardware works, an RP2040 is a good option - it has great documentation and sensible peripherals. Or STM32s have huge numbers of examples in the wild.
Ultimately the biggest difference - the thing you need to learn the most - is peripheral setup. Things like setting up the clock, setting up an I2C or SPI bus, reading and writing bytes from a UART etc. This stuff happens on every computer all the way up to a Raspberry Pi, but the bigger and more powerful the MCU the more it tends to be abstracted away by libraries and middleware.
If you want to truly learn this stuff you have to get low down, strip away all the abstractions and get very familiar with the 1000+ page user manual. Doing that on the simplest microcontroller possible is a benefit, because you're not overwhelmed by complex peripherals and too-many-settings.
I'd also recommend starting with C, rather than trying to mess around with Rust. Rust (and embassy) are great for building apps with very few runtime bugs, but debugging stuff in the Rust async world is a headache, and you've got an abstraction layer sitting between you and the chip.
It's actually really powerful to realise that a peripheral is just 10 memory addresses, and to make it work you just need to define a C struct and point it to the start address. Suddenly you're talking to the peripheral and can configure it. None of that is obvious with layers of middleware and abstractions.