Microchip AVR

I find the lifetime effort of an AVR/ESP8266/ESP32 to be lower than a Pi. I’ve had AVRs (of mine) running in the house for 9+ years without being touched (and ESPs for over 5). Things do just work out of the box on them (often easier than installing Raspian, getting it onto wifi, setting up ssh, looking up the commands to set a GPIO, figuring out cron, rc.d, etc.) It’s way faster IME to just use the Arduino digital_write() functionality in setup and loop. (I’m a long-time c/c++ programmer, which helps a bit.)

I got started with AVRs too! It was just before Arduino became well known, so by coincidence I got started with ASM instead of anything C. I still force myself to take a break from work once in a while and hack together something with hand-optimized assembly. I'm afraid that if I don't do it at least once a year, I will have lost something wonderful and essential. Like forgetting how to write poetry because I spend all day writing manuals for IKEA furniture. The AVR datasheets are also a joy. I'm liking the Attiny10 a lot these days.

They are reliable, easy to learn, low power, have an open source toolchain (and multiple open source programmers), a wide range of package and feature combos, TONS of examples and libraries (even without Arduino), require few external components... on and on and on. If they fit the needs of a project they are quite pleasant to work with and not every project needs a powerful MCU. I dunno if I'd pick them for a large scale product because of unit costs, but I use them all the time for hobby and even some limited production work-related stuff when parts costs are a rounding error.

I don't think the arduino software ecosystem is a good path to becoming proficient in embedded development. The very concepts that you need to really understand well, working with registers and understanding the microcontroller as a set of digital circuits, are abstracted away. With that goal in mind, I see simple devices like AVRs as a better first device because there is just less to configure. There's less to debug when things go wrong. There's only one clock domain. The datasheet is far shorter than most ARM devices. When I look at the example projects for devices I use at work, such as nrf52, or stm32, and then try to put myself in the shoes of someone learning this for the first time, they seem overwhelmingly complex, when compared to similar examples for AVR parts. I must admit that AVR hardware debugging is miles behind ARM though.

Given the amount of Arduino code that existed at the time LLM's were trained, I would have to agree that AVR-8 might be fine. For now it's on the Cortex-M struggle bus.

ATmega328p is legendary but the AVR64DB32 is a far superior upgrade in almost every way that matters. 64Kb Flash, 16kB SRam, full 24Mhz speed at 1.8V minimum power, 12bit 130ksample ADC, 2x Rail to Rail OpAmps for free (3x on higher end versions), etc etc. Better timers, USART, DAC, Comparator, Zero crossing detector, 50mA per pin with full 1.8V to 5.5V range, 300mA total GPIO source/sink, multiple VRefs, 4x 3-LUTs + 2x JK Flipflops for glue logic, event routing system (peripheral-to-peripheral routing while under deep sleep). And... AVR64DB32 is cheaper at Digikey than ATMega328pb. So faster, cheaper, more capable, lower power (sleepwalking peripherals), more flash, better analog components, what's not to like? I realize that Arduino Uno has made ATMega328p absurdly popular. But AVRs have had over 10 years of upgrades since then. And so has the competition (TIs MSPM0 Cortex M0+ for like 50 cents is very competitive, as is STM32C0 line or STM32U5 low power line)

I guess I'm showing my "hobbyist" bias, because I was looking at Digikey-pricing quantity 1, not bulk prices, with my discussion earlier. So that's still in the general price range (XMC1 is similar to STM32L0). Not that the price point matters too much, but just trying to keep things apples-to-apples here. But the 1.8 to 5.5V support and 50mA is _definitely_ impressive. Its not very common in my experience to see such a wide voltage range on an ARM chip (though it is somewhat common in PIC / AVR / 8051 8-bit uCs). I'd still say that AVR DB has the advantage though, because 3x OpAmps can do so so much. The marketing page for that XMC1 shows off a SMPS DC-DC voltage converter for example with the XMC1 50ns comparator. Certainly nifty but... I'll one up that with a true-and-proper DAC and a rail-to-rail OpAmp controlled by the AVR DB series. (The cheaper AVR DD also has a DAC, but is missing the OpAmp). There's just things you can do with a 5MHz OpAmp / analog control that you can't do as well with digital logic. I'm willing to bet that the current control / response time off of the 5MHz OpAmp from the AVR DB will beat the pants off of any digital logic the XMC1 tries to do. And while 50mA is huge, the most I've seen in this class of chips... the AVR DB OpAmp is specified for ~30mA current source / sink. So while its smaller than the 50mA pins of the XMC1, its still rather strong. ------ > The upshot there would be high commonality with XMC4 (Cortex-M4F), and general commonality…

I dunno. AVR-8 is basically the last 8 bit CPU so it is much better than the CPUs we remember from the 1980s like the Z80, 6502, 6809, in most respects except RAM size. 32 registers is a lot! It also takes advantage of the Harvard architecture and has none of this pipelining and cache BS, most instructions take a cycle so if it runs at 20MHz it is basically running at 20 MIPS. Assembly language is beautiful and thinking about writing C for it makes me want to cry. The one issue is that it has no upgrade path to anything more powerful so if you want something better it is going to be ARM or ESP32 so you might just keep writing portable C.

I feel you're mixing things up. Not every embedded application requires parsing strings or JSONs like you do with web frameworks. AVRs and 8 bit chips in general are mostly used in various fixed point numerical control applications like CNC, industrial automation, elevator control, and white goods for the home like washing machines, HVAC, and microwave ovens, so for that they're perfect and so is C. All they do is read some buttons and sensors, crunch some basic math, run a state machine, and turn some motors, LEDs and relays ON and OFF. That's it. Complex string manipulations is something you'll never see on an AVR chip in such production applications.