The generic compiler-provided startup code is fine for AVRs under most circumstances, since they're only produced by a single manufacturer and don't have fancy features like PLLs which need to be initialized. It's the more complicated chips where it gets a little hairy, especially if you have to deal with things like external RAM.

There actually isn't any reason STM or NXP or whatever ARM vendor couldn't provide AVR-like usability and awesome libc. For example the assembly blobs used on most STM32s are very simple.

It's simply that they want to push people to their propietary IDEs (to increase vendor lock in). STM used to provide an okayish libc implementation but then decided to bury it inside CUBE (MX).

If your design becomes complicated enough sure go ahead and change the startup code. But that's quite a small portion of all uses and for those we should have AVR like ease of use.

The choice of board support stuff like crystal frequency is stuff that needs to be tweaked per board really early in the boot process.

I guess I rarely see the case for an AVR when you're not prototyping on an Arduino. You can get chips that are an order of magnitude more powerful per $/watt/and any other metric you'd want to use.

Have you read "The Amazing $1 Microcontroller" [0], which might have been posted here before? It's a survey of available microcontrollers, with the intent of helping you choose one. If you have read it, are you in agreement with the article, for example on how AVRs compare to others?

[0] https://jaycarlson.net/microcontrollers/

Yeah, he put a lot of work into that, and I love that he published all of the information.

My biggest complaint though is that he expresses GPIO cycle time and interrupt latency in cycles, rather than normalized on real time.

Particularly when comparing a STM32F0 to an AVR, the perf looks almost even, until you realize that the STM32F0 is clocked 2.5x faster.

Good point. Have you, or someone else, mentioned this to the author?

Low latency IO and computational performance isn't always needed.

If it's not, you can drop the cost. There are AVR like 8051s that you can get for 10 cents.

I can't find any 8051 less than 30 cents and I digikey sells attinys for 17 cents.

I haven't confirmed what you've said yet, but it makes sense since 8051/8052 MCUs are generally used for their compatibility with legacy code.

I've been working on an agricultural spray controller that uses some silab part only because there is already assembly code written for it. The company that sells the controller doesn't want to spend the time rewriting it in C and moving to arm or pic.

> digikey

There's your problem. Digikey is only really meant for low volume.

That doesn't explain why you suggested a more expensive chip.

What's cheaper or not depends on your volume at that level.