Anyone else still starting fresh projects on 8-bit parts? Why?

So my honest answer is that for a dumb job like reading a sensor and flipping a relay, the simplicity is the feature. Fewer ways to shoot yourself in the foot, and the datasheet fits in your head. If someone handed me a project needing USB or serious math, sure, diferent story.

For me, the big reason we stick with 8-bit, especially in battery-operated remote sensors, isn't just about avoiding complexity, but about the sheer power budget. A small 8-bit chip, maybe an AVR or a specialized Renesas part, can sit in deep sleep drawing maybe 2 microamps. You can run a logging cycle once an hour, pull in some temprature data, and go back to sleep without draining a coin cell battery in six months. Running a 32-bit M0, even clocked low, often has a higher static draw that kills that long-term battery life. When you scale up to hundreds of thousands of units, that power difference translates directly into millions of dollars saved on battery replacement and maintenance costs across the fleet. It shifts the design trade-off from 'how fast can it run' to 'how long does it need to last on a tiny power source.' The silicon itself is less complex, which also keeps the entire Bill of Materials cheaper, including the neccesary passive components.

The previous point about fewer ways to mess up the code is valid, but it's secondary to that hard financial and physical constraint of extreme low-power operation. Sometimes, the choice is simply about staying below a 100 microamp average current draw for a decade. That’s where the 8-bit architectures shine for specific, constrained applications!

For me the size thing is a big deal and nobody's touched it yet. The little 8-pin ones are tiny, and when you're squeezing a board into a wall switch or a door sensor, that matters more than raw speed. Also they're dead easy to stick on a breadboard with just wires, no wierd breakout boards or boot modes to fight with. I made a little nightlight with one and it just worked. Question though, do those small chips still get firmware updates and bug fixes years later, or do the companies basicly forget about them once the next model comes out?

One thing that pushed us back to an 8-bitter at work: availability. We ship maybe 25k boards a year on a part that's been in production forever, and when the chip shortages hit our Cortex-M options had lead times in the 40+ week range while the old 8-bit lines never blinked. The vendor even swapped the die revision underneath us and the code didn't care.

That kind of stability matters when a product has to stay buildable for a decade. The cheap 32-bit parts are great til the specific one you picked quietly goes NRND and you're redesigning a board for something you'll never sell in volume.

The thing that flipped me was the debugger, honestly. I'd been doing 8-bit stuff with a serial print and pray workflow for years, then a coworker put a cheap debug probe on my desk and I could actually single-step the code and watch registers live. Went from days of guessing to minutes on the next firmware bug. That said, I still reach for the tiny 8-pin parts when the job is just timing-critical pin wiggling, because the code is short enough that the debugger barely matters anyway.

Agree with the poster who talked about parts never going end-of-life. I had a similar thing with a little heater controller I built years ago on an old 8-pin part. Came back to it last year wanting a small tweak, dug up the project folder, and the whole thing was one C file and a make command. Rebuilt with zero drama on a modern toolchain. Try that with a project that drags in a vendor HAL and three middleware stacks, half of them deprecated. The boring old stuff just keeps compiling.