Congratulations on such a huge undertaking!
Thanks! Glad to see people are learning and starting conversations from it.
I noted that you included a Code Generator section. Do folk really use these for production code? OK, when you need to use complex peripherals, like USB, for some devices it’s the only thing the vendor offers, but for more mundane peripherals like SPI, I2C, UARTs, PWM, really? You’re going to have to understand the device at the peripheral register and hardware level anyway, so what value do they add perhaps beyond short term instant gratification?
In my experience, I see start-ups and R&D teams using code generators all the time, because they're not an "Atmel shop" or an "Infineon shop" — and, for small-volume or R&D work, code generators let you get quick access to the stuff you selected the part for (say, the PIC16's NCO/CLC stuff), without having to futz around with UART baud-rate generator settings and clock-gating. This is especially true in the 32-bit space.
When engineering consultants can cost a company north of $200/hr, do you really want to pay an engineer to sit around and read datasheets, or do you want to use a slightly faster part that allows them to quickly build up the demo for the investors meeting?
The two I have the most experience with by a long chalk are Microchip’s MHC and MCC. Both are bug ridden, and both make code incredibly difficult to maintain
I had admittedly limited surface-area contact with the code-gen tools in my review, but I didn't notice any outright bugs in the generated code for my DMX-512 receiver, which has to do UART, PWM, and any secondary function (pin muxing, clock gating, timer init, etc).
There are some design decisions I would probably change, but that's a give-and-take that different vendors land on.
The biggest bugs were with Atmel START on the SAM D10 — which didn't provide any modicum of error-checking, and statically displayed a "48 MHz" label under the DFLL, regardless of what it was actually configured to use.
As for the "hard to maintain" argument, the best code-gen tools had no issues with this. For example, Silicon Labs' Simplicity Configurator has no problems adding/modifying/removing ISRs in the same files that had my custom code. ST and Renesas, too --- albeit they cheat a bit and have comment blocks that define precise locations where you can and cannot put user code.
The worst offenders for what you were talking about were probably Microchip and Atmel — their code-gen tools seem incapable of merging their changes with custom-written code.
It sounds like you have experience with Microchip; one of my goals of this review is to illustrate how other ecosystems work, so people don't accidentally generalize their understanding of a function across every possible product line.
For what it's worth, the most efficient (in terms of speed and/or flash) code for the DMX-512 receiver was generated by code-gen tools, compared to those from just standard runtime peripheral libraries.
Intuitively, it seems to make sense: runtime libraries have to calculate a bunch of crap that's known at compile time. Theoretically, the optimizer should be able to get in there and eliminate a bunch of that stuff, but in practice, this doesn't happen as much as you'd think.
A code-gen tool that just spits out a bunch of raw register writes in an init function for a UART is always going to beat a run-time UART initialization library that calculates baud-rate generator registers on the fly, for example.