>One way to avoid this is to prevent the command from being written to history. Bash has a configuration variable named HISTCONTROL, which when set to include ignorespace prevents commands prefixed with whitespace from being saved in history.
This one is nice too, it has an enclosure. You could use this for a smart home dashboard. Be careful with the boards with two USB ports, they will backfeed power.
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.
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 is what it is.
>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.
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.
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)
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.
Sorry, I was digging on that too much time ago and haven't saved any links.
AFAIR, there is permanent busy state in certain conditions when functioning in SPI slave mode, unablility to reset TXFIFO/RXFIFO and some edge case with DMA and TXE/BSY when DMA failed and you don't know how many bytes are in RxFIFO.
Someone's in the Embassy matrix channel currently trying to figure out why the SPI driver is preventing the USB peripheral from enumerating on their G0…
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 Macs — still not in the errata or marketing materials BTW although the workaround may end up beating you with some other bugs. Or the one family that they had to completely rework the USB peripheral while subtly changing the part numbers. Or yeah no.
> 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.
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.
Moving the goalposts much? You went from "lengthy errata doesn't mean anything" to "at least it's cheap", which was my point entirely. The STM32 lineup is cheap with a bunch of features, has readily available documentation, and that appeals to a lot of people.
This feels more like an Apple bug to me considering how they work very
well on Linux, Windows and Android.
Yep, that's the typical STM fanboi response and part of why I'm not so gung ho on STM products. It just feels… cultish and obnoxious.
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.
I sympathize to some extent but really if popular products work for everybody else but not Mac, that sure seems like Apple ought to make it work even if technically it's not their fault, and I note that you've offered no evidence either way on whose fault this is.
Apple's products being shit in some ways isn't even a weird outlier, the company knows its loyal fans have nowhere else to go.
There's generally at least one watchdog device available in most PCs delivered in last decade, but it's not always utilized. Essentially at one point an intel southbridge integrated a basic watchdog on all models, and it started to just... be included.
So these days you can find a variation on the TCO timer watchdog in most PCs, even if the exact implementation varies so we now have a bunch of drivers for the different variants.
Linux doesn't see one on my Ryzen 5600X desktop at least. My Intel Skylake Thinkpad does seem to have two though (iTCO as well as INT3F0D, not sure what that is, but if I interpret the files under /sys correctly it belongs to the LPC/eSPI controller PCIe device, while the TCO watchdog is found under the SMBus PCIe device).
In both cases they do have software watchdogs (NMI based) which relies on a hardware timer triggering an NMI in the kernel. But that relies on the NMI handler still working, which is not as good as a real HW watchdog.
Apparently it depends to a little bit on how the motherboard is designed, theoretically SP5100 watchdog which is part of the CPU logic in recent ryzens, apparently, is supposed to be enabled if the motherboard is designed with IPMI in mind.
For whatever reason, it's enabled on my laptop despite it obviously not having IPMI support :)
“All CPUs” would probably be 99.9999% accurate. It’s just one of those fundamental functions you want in a processor. Whether it’s exposed in the OS is a different matter.
AMD doesn't have it. I just confirmed by grepping through dmesg and journalctl -b, the only time it appears is due to UPS driver notifications (unrelated).
“Look at a day when you are supremely satisfied at the end. It's not a day when you lounge around doing nothing; it's a day you've had everything to do and you've done it.”
Margaret Thatcher
(To which a clever friend of mine retorted: Because you know you can do nothing the next day)
I really like that one, but look at it in reverse - when faced with a task and wondering whether to do it now or postpone it to tomorrow, ask yourself "When faced with it tomorrow, am I as likely to postpone it again?" if so, I strive to explicitly choose one of the following:
1. Accept that it's just not important to me and consciously abandon it (perhaps with a quick WONTFIX update/handling, if needed).
2. Accepting that it is important and I'm as likely to keep postponing it, roll up my sleeves and do it now.
3. Accepting that it is important, but now is not a good time to tackle it, postpone it, but try to set things up such that I won't postpone it again. This includes blocking off dedicated time in my calendar for the new time, making sure I have the tools/prerequisites I'd need then, and if possible figuring out a motivational hack to prevent myself from postponing it again.
It's still hard, and I'm constantly learning what works for me and what doesn't, but I like that I'm making these choices more mindfully.
If you prepend your command with a space, it will not be added to your shell history.
reply