They're also very easy to target with Rust, I like them for that reason.

Can confirm!

Just the other day I decided to try out these instructions to blink an LED: https://jonathanklimt.de/electronics/programming/embedded-ru...

Took about 10 minutes to get an LED blinking, about half of which was just figuring out what (C language) USB libraries I needed to install to get the "cargo flash" command to compile. I used to do a lot of microprocessor development in C and ASM. This is the easiest experience I've ever had in getting one up and running with fully open source tooling (many microprocessor vendors do have quite good closed-source tooling).

While I haven't actually done a real project yet, the hardware abstraction libraries look much safer to use than any of the C/ASM toolkits I've used. The reason being, the API's are designed to leverage Rust's borrow checker and other safety features to make sure errors in use and configuration of the hardware are caught at compile time.

Also worth reading: https://rust-embedded.github.io/book/

Isn't that the case for virtually all embedded ARM chips?

No. If you look at an STM32 manual, they can be > 1k pages as you need that much information including the errata to truly use a part. MCUs with < 100 page manuals will rely on YOU finding the bugs and working around them.

Even with STM32, there are some peripherals that can be difficult to use without careful reference to the application notes, errata, and/or ST's sample code. The I2C peripheral on the STM32F1 is a prime example -- if you don't read/write certain registers in precisely the right order, the peripheral will lock up or return incorrect data.

On the whole, though, you're absolutely correct. :)

In further agreement, part of getting to know a new MCU is to breakdown your project into a series of small conformance test suites and at the same time, trying to get into the mind of the peripheral designers. Delays in config registers, changes not becoming visible until some other action. Weird interrupt behavior, timers, capture compare, reset, brown out, etc. They all have issues, and one can't just assume that _anything_ works. Everyone blinks and LED, sometimes multiple times on the same project. The firmware you use to debug the chip and the system is the stuff that keeps you sane.

Design systems for visibility and debugability. Multiple color leds, extra serial ports, extra flash to dump memory to, an external control MCU that can handle DFU, serial port access, monitoring, etc. Use the largest memory part that has the same pinout. Building a project that is going to ship qty < 100 with the smallest, most resource constrained parts is a foolish thing. Spend an extra $2 and get >256KB of ram. Get remote debugging working in the first week. Automate relentlessly.

Not all. Some parts require proprietary tools to build a full firmware image for the chip, to debug the part, or to write to the target's onboard flash. Thankfully, these are all getting less common -- but there's still some out there. For instance, the Cypress PSoC requires Cypress's tools to generate configuration data for the part's configurable digital blocks -- there isn't enough information in the reference manual to do this yourself.

At least the Cypress tools are freely available and well documented. I have built probably 7-10 products using the PSoC, the tools worked well, resulting firmware solid. Don’t know why you would use Cypress as your example?

Because you can't not use their tools. The register TRM is deficient on some details of the UDB structure like routing, which is essentially mandatory for use the part. (You can technically program the part using only hard peripherals and GPIOs, but that leaves you with a crippled microcontroller.)

Yes, in the sense that even the Chinese no-name parts do have to comply to some kind of standard.

The selling point with lines like STM32 or NXP is that they have lots of good documentation, Application notes etc.

Simple example, I was looking at trying a weird Chinese part with a hardware NN accelerator but the entire documentation available (Chinese or English) was 10x shorter than the documentation on the serial peripherals alone on an NXP part.

K210?

Yep

And absolutely not limited to ARM.

AVR8, MSP430 have the usual as, gcc, etc. toolchain. I don't know PICs as much, but I believe they too do have extensive open toolchains available.

I think there are free PIC assemblers but no free C compilers. All the tools needed to actually load code onto the chip are either proprietary or don't work with the modern programmers.

No great loss in my opinion. PICs are old and slow, and the C programming experience is much worse than an STM32.

Interesting re: pics. That might be why people I know who use them used assembler. I did use them once, and used assembler myself, ages ago.

I'd say avr8, msp430 and stm32 cover the full range.

avr8 (atmega/attiny) is 8bit, very easy to understand, has excellent open ecosystem, the go-to if you don't need the other two. There's fancy new xmega stuff, but at that point, you'd look at stm32.

msp430 is 16bit, smaller rom/ram sizes but very low-power and excellent open ecosystem.

stm32 is 32bit, Cortex-M0+ based in current generation,

pic? attiny trounces pic12, atmega trounces pic16/18, msp430 trounces pic24 and stm32 trounces pic32.

The STM32 is even better than that because the family scales up and down from M0 to M4 or higher without much of a change.

Plus the free libraries that ST has made available are magical. Just - incredibly good. Best embedded C experience I've ever had. Yes using the chip in a more 'bare metal' scenario can be challenging (set 4 registers in the proper order with obtuse values to route the clock signal properly), but it's usually not necessary since the provided libs are so cohesive and comprehensive.

Indeed

I tried the official stm32 tools (code generator) at work and found them horrible. But Zephyr supports some of the boards which makes it worthwhile (for me) to use for quick prototypes.

I’m a vim+gcc user and have never used an IDE in my life, yet even I can’t live without STM32CubeMX. You’d have to be crazy to live without it, how could you possibly figure out non-overlapping pin assignments.

The LL drivers aren’t bad, but it’s hit or miss if they have them for your chip and the peripheral you want.

I might be old school .. I really liked to have a programming manual while doing bare bones development (I did this using a Analog Devices device). The HAL didn't work out of the box as I didn't understand what else was needed for it to work. I had to call certain functions. In that case it would be less work to implement the same functionality using interrupt handlers which I wrote and that would give me better understanding of the platform as I would have to read the documentation.

Does anybody have some experience with gd32 STM clones ? They're much cheaper, but how is the experience porting to from the STM ?

It would nice to run the mbed, or maybe some rust, on a $1.2(qty 10, [1]) chip with 64KB flash.

[1]https://lcsc.com/product-detail/GigaDevice_GigaDevice-Semico...

I try not to use them, but they seem fine for basic SPI/UART/etc. Someone did an analysis of the dies, and apparently they compare favorably in some ways:

https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-...

I haven't tried anything complicated with the peripherals though, and the thing is, STM32F103 chips are so cheap already. The design is over 10 years old, and ST is so good at making them that most "64KB" chips actually have 128KB of Flash.

The GD32V chips are very cool, though; they keep the STM32-alike peripherals, but they use a faster RISC-V CPU core (rv32imac).

This is true for many of the families listed, not just stm32.