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