Hacker News new | past | comments | ask | show | jobs | submit login
PSA: If you're a fan of ATmega, try AVR Dx (lcamtuf.substack.com)
150 points by scrps 3 months ago | hide | past | favorite | 117 comments



If you are a hobbyist reading all this, and trying to compare it to arduino or raspberry pi, do yourself a favor and buy one of these: https://www.adafruit.com/product/5325

$12, fantastic documentation and tutorials, and you can literally just plug it in via usb and edit the python code as if it's just a text file on a thumb drive. No programmers, special IDE's, or specialty equipment

Microcontrollers are fun again


I'll plug ESP32 more broadly, which are half the cost of the Adafruit user friendly chip, which is only single core. If you're familiar with Arduino, the regular dual core ESP32 are fully compatible with cross-platform Arduino C code. You can get ESP32 for $5 each from US resellers or even cheaper in bulk on Aliexpress from China.

If you really need to get cheap, the ESP8266 is also fully Arduino compatible and less than $2. Still way overpowered for a wireless temperature sensor sending packets to homeassistant or whatever.


If it solves your problem for a price that is acceptable, it isn't "overpowered". This isn't using an i5 to blink an LED territory.

Unless you are shaving pennies for mass production, I'd stay away from any of the Tensilica LX6 LX7 based ESP32 parts. Toolchain and library support will be much better with the RISC-V based parts.

The ESP8685 is the current budget RISC-V based MCU. 384K of user SRAM, 4MB of Flash, 160Mhz RISC-V core. $1.50 qty 1.

https://www.espressif.com/sites/default/files/documentation/...


Are the toolchains and libraries already much better or will that be in the future? Note that the CPU architecture is the least important thing of a microcontroller; as long as you have a decent compiler for a higher level language you don't care what instruction set it uses. And I can see the toolchain getting more love if it's a more widely used CPU architectue (and Tensilica is rather niche), but I don't see why library support would be any better.


The LX6 wasn't supported by LLVM for the longest time, only GCC.

RISC-V is nearly identical to MIPS or Arm, so anything to add Arm support to library, would also make it RV compatible (before inline asm).

Build breakages on LX6 or LX7 are 100% on you.


Forgot to mention, that as these MCU and crossover parts get more capable, the expectation that you can basically run a linux distro and then also communicate with many RT control-loop mcus. At some point, embedded control applications will have a Js toplevel.


I have an open source fetish for RISC-V, but to be honest, the LX6 and LX7 toolchains are perfectly fine in terms of functionality for what most people need a low-cost chip to do. ESP-IDF and FreeRTOS are pretty mature at this point. Really cool things could happen with RISC-V. But when I need a chip to read/write some GPIO pins, drive a display, and do some networking, it doesn't really matter.


I think I bought about 5 ESP32-WROOM-32D, 25 ESP8266, 10 Arduino Mini clones, 10 Arduino Nano clones during the pandemic. They're coming out of my ears.


To me that is a very different experience from actual 'fun' MCU programming. I do not know if the ATMega community is so keen to program python. I remember sitting in front of a scope to carefully insert nops to get timings correctly or spending hours fixing bugs in the sdcc code generation before resorting to assembler again. Nothing against esp32 and python...


> I do not know if the ATMega community is so keen to program python.

Not sure that it's the ATMega community being keen to program Python, or Python people keen to program on ATMegas.

The hobbyists I know who prefer ATMega are certainly not using Python. They take the extra step of reflashing the chips, if needed, to get rid of it.


Yep. Atmel/Microchip AVRs popularized by megaAVR ATMega328 toolchain favors their restricted C/C++ subset.

There are a couple of alternative languages that don't require a computer host to drive them:

Visual programming language: https://xod.io

There was Céu: https://github.com/ceu-lang/ceu-arduino

And one can always try AVR assembly if they're really curious.


Thank you for highlighting this — I hadn’t realized how far the lower end of the price range had advanced since the days of cheap Pro Micro clones. 240MHz, 2MB ram, 4MB flash, circuit python —- this is incredible for $12, and from Adafruit no less!


the lower end of the price range has advanced by almost three orders of magnitude since 12 dollars: https://jlcpcb.com/partdetail/NyquestTech-NY8A051H/C5143390

those are 1.6¢


Then take a look at the RPi Pico. All of the above at an even lower price point: I think I bought 3 for $12. Only thing missing is wireless, which you can get in the Pico-W.


The only thing the Pico-W beats the ESP32 on is power consumption. ESP32 costs the same as Pico non-wireless. ESP32 has double the clock speed, ram, and flash, plus wifi and Bluetooth, at the same price.

Plus ESP32 has a huge ecosystem of software and hardware, the same way the original big Raspberry Pis are much easier to develop on. Pico ecosystem isn't nearly as big.


The PIO units can be a killer feature in some specialized cases. And not all the ESP32 variants have native USB, which can be a requirement. But generally I agree that ESP32 is the winner, for now.


the RP2040 can be overclocked like crazy, has dual cores, a considerable amount of ram and the amazing PIO devices which allow the RP2040 to bitbang DVI. The PIOs are amazing.

https://rp2040pio-docs.readthedocs.io/en/latest/

An ideal board would have an RP2040 as the USB terminator (where it can be a usb mass storage device for dragging and dropping firmware) and the ESP32 can handle the radio.

ESP32 is on the order of 1.05-2$ each and the RP2040 is 0.70


+1! the Picos have been an absolute joy to work with, and take me back to my C coding start from.. gosh.. 38 years ago. :)

Mix in some I2C components and a few jumper wires, and you basically have my whole childhood distilled down and reborn -- legos and code.


If you're limited to Python and aren't an EE/CS, sure. Developer support is one of the key points for hobbyist- and industry-useful MCUs/SBCs.

There are other interesting boards out there:

--- ESP32-C6-DevKitC-1 ---

C and Python in the box

https://docs.espressif.com/projects/espressif-esp-dev-kits/e...

$9 gets you

- 32-bit RISC-V

- WiFi 6 2.4 GHz

- BLE 5.3

- Zigbee 3.0

- Thread 1.3

- ARGB LED

--- ESP32 RISC-V Rust board ---

$19.80

https://www.espressif.com/en/dev-board/esp32-c3-devkit-rust-...

- Temp and humidity sensor

- Inertial measurement unit

- Li-ion charger

- USB-C

--- Orange Pi 5 Pro ---

$141

http://www.orangepi.org/html/hardWare/computerAndMicrocontro...

- Rockchip RK3588S

- 16 GiB LPDDR5

- GPU 10x faster than an RPi 5's

- NVMe without a hat

- WiFi 5, BT+BLE 5.2

- H.265 8K@30fps encoding and 8K@60fps decoding

- AI accelerator built-in

Once upon a time™, c. 2000 for hobbyists, there was primarily BASIC Stamp (with BASIC obviously) and PICs with their own assembly ISA. Yep, we had to walk 100 miles barefoot to school in the snow back then. ;)


> and you can literally just plug it in via usb and edit the python code as if it's just a text file on a thumb drive.

The original mbed featured that but implemented using a separate micro. You copied the file and pressed the reset button to load it.


I often wonder how you do that : the usb mass storage let you use blocks, not files (if you want files use the MTP/PTP usb protocol), so how will the target "know" that I'm uploading a file to write to the flash wihtout writing and reading a full FAT on the device flash ?


This blog article gives a rundown of all of the ways this has been implemented. https://makecode.com/blog/one-chip-to-flash-them-all


Nice! So what this means is that you put all info for flashing a part of flash in a 512 byte sector so you don't need filesystem info (place within file, even order) since it's all written as a bunch of self contained 512 bytes commands in the data itself. Clever!


The flash on the mbed was a real 2MB FAT disk that you could upload one or more random files to, not just mbed binaries. I assume they built a dual ported flash driver that arbitrates access between the loader and the USB storage driver. I should also mention it looked for .bin files and checked the mtimes to load the newest .bin file in the disk's root. So it was using a real FAT file system on both ends.


Call me old fashioned, but I wouldn't waste 100s, if not 1000s of bytes of program space to program them in python when literally 5-10 bytes of register programming would suffice. But, of course, this requires a bigger commitment of time to study and understand the reference manual.


Realistically its "wasted" whether or not you fill that address space with instructions or 0's. The memory is there whether or not you choose to use it. If you don't, nothing is going to use it at all.

I'd also argue that "old fashioned" would include the era of the venerable 6502 (yes, not an MCU, but hobby electronics programming isn't all MCUs) which was often programmed by hobbyists in BASIC, another interpreted language, so it's hardly a new thing to "waste" those bytes.


Oh no … there goes my “no more money on unnecessary projects” resolution.


I'm a bit torn. While there's something nice about the simplicity of an 8-bit device and DIP packages, I've come to enjoy ARM's Serial Wire Debug, and ARM tooling. Definitely don't miss avr-gcc and avrdude.

In a way, it's ironic. The AVR tooling back in the day was just so much better than PIC (for a novice hobbyist, pre-Arduino).


Ah, the good old days where computers had a serial port and you could assemble an AVR programmer on a breadboard to flash an AVR and build a USB programmer.. Programmer bootstrapping ?

But you're right, the tooling has come a long way. The proliferation of ARM in so many domains means lowly microcontrollers can benefit, as opposed to being bound by the manufacturer or community size.

Hopefully RISC-V will improve this even further.


The simpest AVR programer, widely used in ex-USSR was called "5 wires" and consisted of 5 wires, ic-socket and 25 pin connector for the parallel port.


> Hopefully RISC-V will improve this even further.

In was more hopeful in past then I'm now with the RISCV ecosystem.

The issue there is fragmentation, so it's not RISCV... every vendor will have their tooling because they'll be adding their secret sauce that they wont be sharing with everyone else, which is a shame.


Three resistors and a parallel port?


> The AVR tooling back in the day was just so much better than PIC

I'm disappointment MPLAB X Ide only supports x86 Macs. Also, release 6.20 was Jan 2024 so the release cycles are pretty long... doesn't inspire confidence.


I generally use ESP32 nowadays, since most things I do benefit from having WiFi connectivity, but I have fond memories of using AVR microcontrollers in the past.

For hobbyists, AVR (ATmega, ATtiny) microcontrollers were really great. Easy to use in C for most cases, great cross-platform toolchain, and many of them came as DIP package, which made them breadboard/protoboard friendly.

Heck, we even had a USB 1.1 library, that could bitbang USB 1.1 on practically any AVR, including 8-pin ATtiny: https://www.obdev.at/products/vusb/index.html

Not to mention, that Arduino started with ATmega, and still have many board featuring it.

I definitely might check Dx line, just to see if the experience is the same as it was before.


I started working with Microcontrollers when 80C51s were still somewhat modern, and I remember how frustrating the toolchain and the general experience was.

When AVR came out with their ATmegas, it was a revelation. Not having to use shitty proprietary programmers and windows-only software was amazing. We could finally use Linux. PIC was one of the main competitors in our circles, but it was losing the foothold quickly, because the AVR tooling was just hands-down better.

Also, documentation was easier to read and interpret, especially compared to PIC, which is still giving me slight PTSD when I try to recall how hard it was to get non-mainstream features to work. Whenever I had to deep-dive PIC documentation I stumbled over weird behaviour or outright hardware bugs that, in some cases, could not even be worked around.

I don't actively work with microcontrollers nowadays, but I am excited to hear that AVR is still making an effort to have an objectively good product. The market is tough nowadays, with ESP32s and ESP8266s being so cheap and widespread, but I hope AVR keeps it up.


Very few hobby designs that use more capable chips actually need more capable chips, and the added complexity - hardware and software - often bites hard.

That said, wifi is a major selling point, and you need a beefy 32-bit computer to run the protocol. This is the brilliance of ESP32: you can actually use it just as a wifi dongle for another microcontroller, but since it needs so much computing power, might as well give you some RAM and CPU to do your thing directly on the wifi chipset...


The ESP32 is very overpowered for random home projects. But the cost is low, and they can be used with the Arduino ecosystem which is very beginner friendly.

Often the ESP32 is far cheaper than whatever sensor you're making it monitor. WiFi isn't the perfect technology to upload sensor data in the home, but anything proper Zigbee is more expensive and more complex to use. So the ESP32 ends up in all kinds of projects.


The ESP32 is not overpowered! Either for the cost or the power consumed. This idea that if an MCU is too easy to program for or has "resource left over" after completing the task that it is ill suited for the task has to go.

ESP32-H2 and ESP32-C6 both do Zigbee.


I haven't tried the ESP32-H2 or ESP32-C6 yet, but they have 802.15.4 radios so they can be used with Zigbee or Threads (plus WiFi 6 on the C6). I definitely am eager to play around with one, most of my current projects have been on the ESP32-C3.


I have worked with DD and have some DA laying around. The UPDI is a very nice and simple programming interface. All that it takes is a USB-UART and a diode or a resistor (I used a diode) to connect between RX/TX.

I didn’t used ATmega a lot, but comparing the experience to MSP430 and EFM8 the AVR chip has a bunch of niceties, superb documentation and life improvements like, in order to clear some registers all one need to do is write 1 instead of the whole =& ~(REG | 0x8) (or something like that, it’s been a while since I write embedded C)

The other thing that I loved is that one can download headers for the chip directly from the manufacturer!

Way too many chip manufacturers keep locking headers/libraries behind their proprietary IDEs, but Microchip, even though they have an IDE let’s you download the headers so one can use whatever tooling one is comfortable with! Props to Microchip for that!!


> life improvements like, in order to clear some registers all one need to do is write 1 instead of the whole =& ~(REG | 0x8) (or something like that, it’s been a while since I write embedded C)

This is a really interesting feature since it addresses a shortcoming of the C language (inability to easily express bit set/clear) by introducing a new hardware feature.


SBI/CBI only allowed changing one bit, new registers allow for multiple bits and also toggling them.


How’s debugging and breakpoints for these?


I don’t remember having used a debugger with these, so I couldn’t tell you how was that experience


UPDI has robust on-chip debugging capabilities.


Haven't played with these yet, but they do look interesting. Might have also to add support for the new IO blocks in my AVR simulator simavr[0] -- I still use the AVR a lot, since they have no pipeline and other fancy CPU optimization, they are 'cycle accurate' and are a lot closer to a PIO than most other more complex 32 bit CPUs.. Now that they ALSO have an equivalent to PIO it might even help with reaching faster IO speed when toggling pins.

[0]: https://github.com/buserror/simavr


PICs have had these CPU independent logic blocks for a while too so it makes sense they ported the idea to AVR too.

I don’t remember exactly how many “things” you can do with them in comparison to PIO though. Probably a lot less, as it’s pure gates and not a set of extra instructions like PIO.


This unlocked such fond memories, I'll buy some just to make some LEDs blink. I am glad my first exposure to embedded systems was through ATmega series, not for the chip, but the user's manual. That is perhaps the only manual I have read cover to cover, that thing took me to knowing rudimentary electronics to actually understanding a full system. The first real world system I could hold fully in my head, and that was an amazing feeling. Who ever wrote that, hats off. I remember then encountering the ARM manual which had similar clarity of writing. Were there like professional writers for these things?


Yes.


Or, you can get an stm32g0 for $2, which is faster, has a modern 32 bit cpu, and has more powerful peripherals.


> and has more powerful peripherals.

I severely doubt that. On a G0?

AVR DB has 3x OpAmps. AVR EA and AVR EB have a x16 gain differential amplifier on the ADC (!!!).

The peripherals on the AVR Dx and AVR Ex series are just out-of-this-world good. And unlike ESP32, the ADC has good linear qualities and reasonable accuracy.

------

Even the "runt" of the bunch, the AVR DD (fewest features / cheapest price) has an Event System and Programmable Logic. You get ~4x 3-LUTs + 2x 1-bit memory that can perform operations on your inputs before the AVR Core/CPU even wakes up.

In fact, there's a sample demo of AVR Programmable Logic + AVR Event System (which is a "router" to tie inputs and outputs more flexibly. Its not a perfect router but its better than nothing) + ties it to AVR Timers, so that a quadrature-encoder could be offloaded outside of the core. https://ww1.microchip.com/downloads/en/AppNotes/00002434A.pd...

--------

STM32 G0-series is somewhat comparable to AVR DD in that the STM32 G0-series is "barebones". But the AVR DD's "barebones" has more features than STM32 G-series.

Now STM32 G0 has a lot more SRAM and MHz. But peripherals? Peripherals is where the PIC and AVR series shines. The only competitor to peripherals is like... TI's new MSP M0 line (which also ships with 1 to 3 OpAmps... zero-drift / chopper OpAmps to boot).

If you want a comparable 32-bit processor, I'd go to TI MSP M0 (also ARM but TI is adding an event-system, OpAmps, and other nice low-level peripherals that are familiar to the AVR Dx users)

--------

STM32 does have OpAmps / Event Systems and all that good stuff. But they're locked to the more expensive G4 series.

-------

Ultimately, STM32 and AVR Dx aren't competing in the same league. AVR Dx is more of a competitor to your I2C ADCs or simple logic (now that AVR Dx and Ex have Four 3-LUTs, you have a surprising amount of glue-logic available that can take the place of old 7xxx chips).

PIC and AVR core sucks. Its all about the peripherals. (Well.... AVR and PIC are also absurdly power-efficient. In part because of how well designed the peripherals are)


But what if I don't need all that. What if the AVR is better for some of the uses cases? Or if you already have code for AVR/Arduino.


I often use Arduino (or AT Mega/Tiny) purely for it's 5V and very robust GPIO pins.

I can short circuit an Arduino pin for days, or (attempt to) pull 3 or 4 times the rated current from them - and they just keep on rocking. I've even accidentally hit them with 7.2V or even 12V on the GPIO and not had them let the magic smoke out.

You only have to look sideways past a 5V rail at as RasPi to kill it, and ESP aren't a heap better.

If I can get all the code I need onto an Arduino/AVR, I'll use one. If I need more complex code than I can run on an Arduino but still need GPIO (especially anything 5V tolerant) I'll use an ESP or RasPi (or some other Linux SOC board) with an Arduino (or other AVR) for GPIO. At least for the prototyping stage when I'm using breadboards and moving wires around - if I'm building something permanent (or at least semi permanent) I'll sometimes build a version 2 with level shifters to deal with 3.3-5V stuff, but mostly only once I've got to the "prototype that's got to the PCB stage" iterations. I've almost never killed an Arduino, but I've killer too many RasPis and way way too many ESPs.


Pretty much all ICs these days have builtin ESD protection which usually involves current steering diodes to supply rails.

So if you limit the input current (typically <5mA, and assuming the steered-to rail uses at least 5mA to sink it) it will survive any voltage. (Of course if it's a low power design or the device is off this wont work that well, then you want external clamping)

I have tested 24V AC applied to an stm32f0 pin with a 10K series resistor and it survives that indefinitetly.


I have tested 24V AC applied to an stm32f0 pin with a 10K series resistor and it survives that indefinitetly.

Which mode was the pin in? I'm not an STM person but my understanding is that most MCU pins are tri or at least multi-mode, if you have the wrong mode set it's effectively isolated.

Edit: Can't reply to child. Schmitt trigger circuitry is disabled if pin is in analog mode or is an ADC pin according to https://www.st.com/resource/en/datasheet/stm32f071cb.pdf page 59 .. could affect sensitivity ... perhaps there exist other mode-related influences, too.


in most cases diode clamping to the rails is still active though? and that's what sinks those 2.4 milliamps and keeps your gate oxides from avalanching. i think the stm32 datasheet only guarantees withstanding 0.5 milliamps of such 'injection current' per pin

there do exist cmos chips with pins without input clamping diodes but they are rather exotic usually


Inputs which is the default in f0 series. Structure is:

esd cell -> optional pull ups/down -> schmitt trigger.


I've spent years working with TTL so 5V is just more convenient. Besides USB is 5VDC as well. When breadboarding, more than once I've mixed up 3.3V and 5V domains with dire consequences - always on the 3.3V side.

Unless I really need WiFi, I prefer to go with ATmega. Once you get used to writing structured assembly language, you can get so much more functionality fit within flash memory.


A lot of the pins on STM32 are 5 volt tolerant (and almost all of them are on the smaller devices).


Until you design and solder up a PCB with $50 worth of parts, then discover the timers can't do what you needed them to do. (Ask me how I know). If you're a hobbyist, the STM32 has so much more functionality, and I've wasted so much time trying to get the underpowered AVRs to work, I'll never touch them again.


That seems a bit weird of a complaint.

All of these chips have devboards in the order of $20. Surely you could have built a code prototype with a devboards before designing up a PCB?

In the embedded world, timers are very specifically designed. Yeah, TimerA is more flexible and maybe you needed more of that, but the less flexible TimerB on AVR is more power efficient (like 1/3rd the power or something). So TimerB has it's other uses. (Really, I'd say TimerB is specialized at frequency counting tasks but is less good at PWM or other "output" tasks. So TimerB is kind of an "input timer")

And TimerD is this weird behemoth that I don't understand yet. But someone probably used it for something good out there...

--------

But given the nature of TimerA vs TimerB vs TimerD (as well as the knowledge that TimerA is on different pins than TimerB), surely that should have cued you into the point that you should prototype your design?

Don't lock down your PCB until you have idea of what wires should go to which pins. And part of that process is deciding if TimerA vs TimerB vs TimerD was what you needed.


AVR gives up on core/SRAM and instead offers incredible peripherals. While AVR DA, DB, DD, EA, and EB chips can serve as replacements to ATmega (albeit with new pinouts), the newer chips are a completely different ballgame.

AVR DB has 3x OpAmps for free.

AVR EA and EB have differential 12-bit ADCs with programmable 1x to 16x gain. We're not just talking about measuring 4mA to 20mA protocol easily, but you can measure uA of current with reasonable accuracy with just a shunt-resistor + the AVR EA's ADC.

AVR DD has a dual power-supply with 1.8V to 5V support. That means that some pins can be on 3.3V logic while other pins are on 5V logic. IE: The AVR DD's job is to be a built-in full-and-proper level shifter.

Bonus points: All modern AVR chips (Dx and Ex) have an event-system to route events from any peripheral (Timers, Pins, UART, etc. etc.) to many other pins and even interrupts to the CPU. This combines with the CCL programmable logic unit (Four 3-LUTs + two 1-bit memory cells) to have an incredible amount of "glue logic" built into these chips.

Anyone who comes in this topic and talks about "But 32bit whatevers", ESP32 or about super-cheap RISC-V chips is missing the point of the AVR line. You're not really the ones in the market for this chip. Anyone who has to deal with a cheap design that manipulates a bit of analog sensors, or glue together logic... well... AVR is the right chip for these jobs.

----------

There's one problem. It means that you need to know the ins-and-outs of the peripherals that are offered on these chips. AVR DD cannot do the same current-measuring job that an AVR EA or AVR EB can do.

Mixed-signal Peripherals are so much harder to understand than MHz and SRAM. But for those who are "in the know", well... these are awesome peripherals. Its difficult to find competitors to these chips.

Indeed, a proper bidirectional 3.3V to 5V level shifter across 28 I/O pins alone would probably cost you more than the $1-ish AVR DD.

3x Rail-to-Rail OpAmps with programmable voltage-reference, a DAC and differential ADC is a *bargain* for the AVR DB's $2 price point.

---------

And the whole line offers like 5V and 50mA in/out on the GPIO. Its an extremely forgiving chip. The fun trick is to run Resistor+LED directly off of GPIO because... you can. (Typical LEDs are 20mA).


i feel like the ch32v003 might plausibly be the right chip for these jobs, even though it's risc-v, because it's so much cheaper than the avrs. as a bonus, it's made by a chinese company, so you can use it even in contexts where foreign hardware isn't allowed (this has become a big deal as the usa has started ramping up its sanctions)

in theory it's 12¢ each at lcsc, but it's out of stock, so that's only theoretical: https://www.lcsc.com/product-detail/Microcontroller-Units-MC...

it's not competitive with the expensive avrs when it comes to mixed-signal peripherals and 1.8-volt support, but it does have some tasty stuff. you get 3.3 to 5 volts, a 10-bit adc (1.7 megasamples per second with a ±2% bandgap reference), and an op-amp (so you can do differential input to the adc and set its gain), a basic set of digital peripherals, and that's about it. that's still better than an atmega328 or an stm32f103 but not in the same league as the stuff you're talking about

i haven't actually tried the chips myself, so i don't know if they're all they're cracked up to be, but except for a fatal problem with the spi peripheral in the smaller packages, other people seem to report good success, even without speaking chinese: https://hackaday.com/tag/ch32v003/

in this price range, there's also the arm puya py32, and of course the padauk chips with their redoubtable multithreading so you can do your i/o from a separate hardware thread instead of from interrupt handlers


> it's not competitive with the expensive avrs when it comes to mixed-signal peripherals and 1.8-volt support. you get 3.3 to 5 volts, a 10-bit adc (1.7 megasamples per second with a ±2% bandgap reference), and an op-amp (so you can do differential input to the adc and set its gain), a basic set of digital peripherals, and that's about it. that's still better than an atmega328 or an stm32f103 but not in the same league as the stuff you're talking about

Yeah, the features you just talked about are definitely more akin to what AVR Dx or Ex have to offer (albeit the ch32v003 is cheaper and has less features).

I do like this modern trend of making incredibly powerful peripherals that most mixed-signal designs need (ex: adding OpAmps to a device, or in the AVR case, adding Differential ADCs to explicitly support more use cases). This design trend didn't exist back in the day when ATMega328pb was designed however, so you don't get it with the old chip.

-----------

OpAmps seem to be one magic device that really should be in more of these designs. There's so much you can add with one OpAmp (or a team of 3x OpAmps). So I love it when people point out chips with an OpAmp (or two or three) that come with a uC.

I've seen some pretty silly designs, like using the OpAmps to sense Voltage (or current), hooking up the output of those OpAmps to the Analog Comparator that triggers an interrupt + internal state, and that state controls a Timer-waveform / PWM output that controls a Voltage-Controlled Current-Controlled battery charger that's feeding a MOSFET + inductor to create effectively a software-controlled buck-boost converter. I doubt its as good as any "real" solution, but if you've got a bunch of these uCs lying around, it might be a better solution than adding more SKUs of the specialized power chips.

Just a hobbyist here btw. Not a real engineer. The real engineers might look at my previous paragraph with horror!


yeah, i think software control of buck and boost converters is a mainstream thing to do at this point, and if you think about it, that's what you're doing every time you control a motor with a pwm signal, even if the motor's windings are the only inductor. building discrete dc-dc converters turns out to be the main purpose for the 184-picosecond-resolution high-resolution timer included in chips like the stm32g484. i was reading this appnote yesterday: https://www.st.com/resource/en/application_note/an4539-hrtim...

incidentally, even the old attiny chips that don't have adcs at all do have analog comparators, so you can do tricks like that with them too

i'd be happier with the on-chip op-amps if they also included on-chip analog multiplexers, resistors, and capacitors sufficient to build something like a sallen–key filter in software, but so far only the cypress psoc line seems to be doing that, and it's probably a lot of chip real estate to sacrifice for an inferior version of a couple of 0.3¢ external components

i'm not an ee either, i just play one in ngspice


Exactly this. Also, if it's anything like the ATmega, instruction timing will be very simple and deterministic. For some applications that matters a lot.


There's actually tons of really interesting microcontrollers of every size and shape.

Many of them are available as dev boards for under $20.

You can burn plenty of hours and dollars browsing all the good stuff on electrodragon at https://www.electrodragon.com/product-category/dev-board/


If anyone wants to get into hobby electronics, please just go on AliExpress. It has everything and it's way cheaper.


I've ordered from Ali Express, but a few day to a few weeks later I get a message from someone who has not shipped my item and thinks my order and payment was the first step in a negotiation.

Can you please tell me how to deal with Ali Express sellers?

I have several hundred dollars of embedded systems parts on order from Chinese eBay sellers right now.


With AliExpress, my orders never feel like a negotiation. I put stuff in the cart, eventually push the "buy this stuff" button, give them money, and stuff eventually shows up -- just as with other e-commerce sites for decades.

Sometimes it's slower (months), and sometimes it's stupid-fast (a few days), but outside of things like Chinese New Year the sellers generally seem to be very prompt at handling the orders and getting things into the delivery stream.

I've come to expect most things to show up in a couple of weeks (at least here in the States).

I'm not doing anything particularly weird, I don't think. My order history consists of almost entirely of small electronics (sometimes components, sometimes populated PCBs) and 3D printer parts, from dozens of different sellers.


Just be aware, returns are essentially not possible. It's prohibitively expensive to send the item back to China.


While it is certainly true that shipping from the US to China is expensive, it is my understanding that returns for many kinds of items are free these days, using a shipping label generated by AliExpress.

(How they handle that on their end is really not something that I think I need to worry about.)


they will generally refund you if you are unhappy


That sounds more like Alibaba, where it operates like a B2B type transaction. In my experience, just talk to them, sure it might take more time but you can usually get a good price if you’re buying higher quantities.


Never experienced that on AliExpress over the last decade.

Nowadays it just feels like Amazon without the middlemen and slightly slower shipping. I usually receive my stuff within a week (central europe).


Pick the ones that give a delivery deadline (5/7 days). No problems at all (at least from UK), always arrives ahead of schedule.


I would instead recommend Adafruit. No, they're not cheaper, but you pay for knowing that the device will work right out of the box. You get excellent documentation, user forums, and probably most important, working demo code with all the source on github.

That's worth paying a few extra bucks for, IMO.


I'd rather get a clone from China and use all that stuff anyway.


To each their own, I guess. If a business is going to those lengths to support their product, I'd prefer to throw them a few bucks when I can.


With a side serving of fake parts, multi-week transit times, and the added benefit of propping up the Chinese regime.


> please just go on AliExpress

There are too many documented cases of fake (and nonfunctional chips sold as AVR MCUs) that it’s not worth it. For jellybean components, sure. AVRs like those referenced in TFA, not for me.


I've ordered many microcontrollers from AE and they've all worked.


Not good advice.

Buy from a reputable local firm, pay a few extra bucks.

Support local businesses.

Set aside greed.


Pay $20 for a part you can get for $3.


More to this world than a handful of bucks, my friend.


I regularly use both atmega328p (Arduino Uno) and stm32g0 (st-nucleo boards) microcontrollers for hobby projects. The linux toolchain for both are equally good. But the Nucleo boards are a lot cheaper than Arduino Uno/Mega boards, have a lot more capabilities, any are 32-bit microcontrollers.

I am actually fascinated with the things you can do with stm32 chips. If I ever do a commercial project, I would definitely use stm32 chips. Bare metal programming them has been a lot of fun.


See also the CH32V003 [0] (more expensive variants also available), a neat, cheap and standalone RISC-V with plenty of modern & flexible peripherals, good package options, single wire debug and an open toolchain [1] for ~20c per.

Mitxela has a great article on them [2] and I totally agree they have a lot of the same joy & simplicity of the ATTiny - but with the added bonus of lots of interesting DMA controller misuse!

The peripherals have a very STM feel (in a good way) which perhaps isn't surprising given WCH's history.

0: https://www.wch-ic.com/products/CH32V003.html

1: https://github.com/cnlohr/ch32v003fun

2: https://mitxela.com/projects/badge


Came to say this too... I was really pleasantly surprised by how easy it was to get a full dev & build & test environment set up with Visual Studio Code, and how well their little WCH-LinkE debugger works (both SWD and UART in one, Segger could learn from that...). Now I'm experimenting with their BLE variant, which is a lot more complex, but still simpler than what I'm used to.


I just stumbled onto these recently. The big hang up for me is that the programmer is proprietary. I was hoping there would be a bootloader onboard like the CH552. No dice. In waiting a bit more than a week to get one shipped. They’re not expensive, but I’m annoyed that I can’t just load some software on an Arduino and flash the chip.

(Note you can debug open source, just not program afaict)


I wrote a CH32V003 programmer that runs on a RPi Pico - https://github.com/aappleby/picorvd


Oh, excellent! I will check it out. Thank you!


AVR was cool, but I have moved on to RISC-V (ch32v, esp32c...).


Does it have Arduino support?



Pinouts are absolutely not compatible, so you can't reuse the exiting PCB's...


I want my AT90S2313 back. The best most versatile AVR imho of its era.


China prices are still double the old chips, with very limited availability (single digit volume for 2-3 models only). I trust China prices. If it aint there, it aint real.


I don't understand what you mean. These chips are available in bulk from the manufacturer and from all major distributors worldwide. Why would you want to go through China? These chips aren't even manufactured there. The fab is in Thailand.

If you mean a PCBA shop, Mouser or DigiKey can ship your order directly to your favorite PCBA place.


The wisdom of the crowd can be substantial in supply chain. That is to say, for non-trivial projects, selecting any kind of component which may not be immediately available in arbitrary quantities represents a huge project risk. The numbers currently available in China show that the chips' position in the market is too early days / small volume to be considered a viable development target given the fact that the world center of electronics production is yet to see enough aggregate demand to stock more than a handful.

Now if you want to develop against a chip on a 10 year outlook, go for it. But if you want to get work done this week, or this month, or even this year, I'd argue that the distribution is too premature to make that a smart decision.


I don't follow. You can source the chips, in large quantities, right now, and have them delivered to any non-embargoed country in a matter of days.

That they're in limited stock at a particular outlet in China means very little, no? And conversely, that STM32 chips happened to be in stock in 2018 meant very little in the following four years.

If you want the chips right now, you can have them. If you want long-term availability, either buy ahead of the time or sign a contract with the manufacturer (and hope it doesn't fall apart due to a geopolitical crisis or whatnot).


I think perhaps you miss the difference between ordering from the vendor and having stock in the marketplace. The first is just a promise, which everyone learned had little value during chipaggedon. It turns out vendors have all sorts of interests which affect which customers they prioritize stock for in the event that a shortage is anticipated, and most of us aren't on the list. Stock in the distribution marketplace means that not only does the quantity really exist, but it has been in demand long enough that the distribution chain has decided to buffer additional volume. This means there's volume moving and you can to a much greater extent than a vendor promise actually count on it being available and the price representative (rather than promotional, temporary, or highly subject to fluctuation). In general, you also get your stock quicker. I hope that clarifies.


China is full of counterfeits though. I don't actually expect those chips in China to be legitimate. Its public information that these chips are made in Taiwan or other locations, so Chinese supply is pretty equestionable.

I can order 3000+ from Microchip's website right now for any of the AVR Dx series. And Microchip has decades-long reputation of a solid supply chain, even in the 2020 COVID19 period when STM32 got issues.

--------

The older chips are fully obsolete compared to these modern designs. The newer AVR DD is cheaper, faster, loses the Voltage-slowdown issue (1.8V is only qualified for like 4MHz on ATMega328. 1.8V on AVR DD can go full 24MHz), etc. etc.

I don't see any reason why anyone would ever choose the decades-old ATMega328 when AVR DD is right here, cheaper and better in every conceivable way. One exception: if you really need the ATMega328 pinout _exactly_ because you can't change the PCB or update the electronics, I can understand legacy issues. But new projects should pretty much switch to AVR Dx or AVR Ex (depending on your project's needs, since the different chips specialize in different purposes). Ditto for legacy software because ATMega328 peripherals are older. (Modern TimerA and TimerB are much better than ATMega328's legacy Timer0 and Timer1)


China-bashing is naive - most of the world's electronics are produced there for a reason. Here's how it works. Projects aren't open shut, and they don't exist in a vacuum. The cost of targeting a new hardware platform is nontrivial. All hardware costs are trivial vs. overall project costs (time, people, shipping, testing, production, packaging, distribution, etc.). Even then, outside of launch-time near-shore marketing-land, the chips currently cost double the old ones. No prior software will run without modification. Even the programming interface is new, which means retooling production code, jigs and fixtures in addition to firmware and schematics. Nowhere did I say "the hardware is worse", rather I said "the hardware is a premature choice for commercial projects with rapid delivery requirements at this time". Understand the difference. I stand by that assessment.


> China-bashing is naive - most of the world's electronics are produced there for a reason.

I didn't say that China didn't have most of the world's production. What I said is that a large number of Chinese chips are counterfeit. So when we're talking about discussion points like:

> Even then, outside of launch-time near-shore marketing-land, the chips currently cost double the old ones.

Well, have you done the QA to assure that these "old chip lots" are actually legitimate AVR ATMega328pb or are they some king of counterfeit chip? I know the STM32 chips in a lot of Chinese shops are just clever replicas, and that's key to their lower prices.

I don't fully trust prices, especially of old stock in China.

---------

China has enormous potential in terms of electronics manufacturing. But the supply chain problem / counterfeit problem certainly exists. No matter how clever their replicas get, there are minor concerns about power-delivery differences or minor differences to the ADC (or whatever). Maybe the counterfeit chips are good enough for your projects, or maybe not. But its still a concern that floats in the back of my mind, especially if the prices are much cheaper than the legitimate sources.

Like: maybe the chips don't sleep quite as low power as a legitimate chip, or the ADC is slightly less linear than a legitimate chip. Etc. etc. Minor differences that with good testing you could actually work with the counterfeit and get a usable product, but a risk nonetheless if you have an old design that depends on the specifications of the original.

----------

Here's a Hackaday on some STM32 counterfeits they found: https://hackaday.com/2020/10/22/stm32-clones-the-good-the-ba...


> China has enormous potential in terms of electronics manufacturing.

this is like saying 'south africa has enormous potential in terms of diamond mining' or 'the us has enormous potential in terms of mass shootings'. china had enormous potential in terms of electronic manufacturing 30 years ago. today, electronics manufacturing outside of china is a footnote. an increasing number of manufacturers don't bother to produce non-chinese-language datasheets. in this context, if a chip's availability in china is sketchy, that's reason to question its viability

the hackaday article does start with talking about stm32 counterfeits but is mostly about legitimate clones, most of which are improvements over st's chips


I dunno why you're so focused on trying to make China look better. It's well acknowledged by pretty much everyone that supply chains in China have a counterfeit problem.

There are pretty much two solutions. Either you more closely handle supply chain issues yourself by buying from the OEM or reputable sources (which increases costs). Or you accept the counterfeits as good enough. Based on this discussion, you've gone with the second option which is fine. But it's something people should know about your argument.

You CANNOT compare prices in the way you've been doing in your argument. That's all I'm saying.

When we compare OEM ATMega328pb vs AVR64DD32, the OEM prices for AVR DD is cheaper. That's the ground truth.

The methodology you've chosen as the basis of your argument is not accounting for the huge, well known risks of counterfeit ATMega328.


you have me confused with someone else; i haven't compared any prices in this thread

i agree that there's a counterfeit problem, and it's worse in china, but that's irrelevant to my argument

i don't think it makes sense to say that i'm trying to make china look better. you're painting a pants-on-head absurd picture of china's role in electronics manufacturing, apparently taken from some kind of incredible propaganda. i'm just giving you the basic facts that everyone agrees on but you don't know yet


The issue here is ATmega328 pricing vs AVR DD pricing. Which is the crux of the discussion.

The pricing estimates discussed earlier have to be factored against the well known, widespread counterfeits. Especially because ATMega328 is a well known counterfeited chip, and the Chinese market well known for being full of not only counterfeits in general, but even counterfeits of this specific chip under discussion.

You cannot compare chip prices like the poster did earlier. And all this Chinese vs whatever discussion you're trying to distract me with aside doesn't change the core fact.


i think the pricing is a mostly irrelevant detail, actually, which is why i didn't mention it. what's relevant is availability

you're right that availability of counterfeits isn't real availability, but i think you're vastly exaggerating the seriousness of that problem. a more likely reason for chinese distributors lowering their prices for the atmega328 is that it's not appealing for new designs, so they need to offload their leftover inventory


> The fab is in Thailand.

While Microchip has offices in Thailand, I thought these chips were made in Taiwan??


I think they package many of their chips in Thailand, so that's where those chips ship from. I don't know about these chips in particular.


Would Rust for AVR work with these too I wonder?


Yes. Its the same architecture.


Looks like a modern PIC with swapped out MCU core. Probably nothing to miss if you use PIC already.


Sounds like a great improvement to me, the 8-bit PICs have great peripherals and are easy to use but the CPU cores are garbage (slow 4T architecture, no hardware stack, bank switching necessary, forced to use Microchip's proprietary compiler instead of GCC).


Yeah these are cool, there is a bunch of info on SpenceKonde's github pages,

https://github.com/SpenceKonde/DxCore


The key points of marketing and executing a successful a MCU are:

0. simplicity

1. robustness

2. developer support

3. essential features




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: