3 ms·

You can get stm32 boards with more memory for a similar price. I really don't get the appeal of those AVRs.

contingencies 6y ago
Arduino support (STM32 has it now but only relatively recently and with substantially less libraries), better availability, less of a confusing hardware landscape with numerous minor chip variants and 'pill' form-factor hardware versions with wacky incompatibilities, more open source PCB designs available, inertia...
dragontamer 6y ago
Its not about CPU-power, its about electronic flexibility. AVR has 1.8V to 5V power tolerances. STM32 boards have 1.8 to 3.6V tolerance. (Yes, STM32 boards can have 5V I/O tolerances, but you need the power line to be ~3.3Vs) This means that you can run an AVR system from 3xAA batteries or Li-Ion without much more thought involved. STM32 is more complex: 2xAA works, but that's much less energy than 3xAA. Lithium Ion is nominally 3.6Vs, but when charging Li-Ion can be 4.2Vs IIRC, so you're going to need to protect the STM32 from the higher charge voltages, because 4.2Vs is out-of-spec. This means that STM32 needs an external voltage-regulator module, while the AVR can just happily accept the 4.2V voltage-under-charge under a Li-Ion setup. ------- The 5V that ATTiny or ATMega supports can also deliver more power from its I/O pins. STM32 is pretty impressive with 15mA source/sink from 3.3Vs, but ATTiny and ATMegas are specified with up to 20mA at 5Vs, both source and sink. That's a lot more potential wattage you can source (and sink) from a raw I/O pin. ---------- So consider what you need to do if you have a 5V line (3x AA batteries): you'll need to create a safe 3.3V line for your STM32, you'll need to have a reference 5V voltage that your ADCs are based off of, and you'll need a voltage-converter to handle all of your 5V electronics. Or, you can just throw an ATMega or ATTiny at the problem, and just run your entire system off of 5V (ADC, I/O pins, everything). In my experience, the higher voltage (5V instead of 3V) has a lot better op-amps, and other such devices, that you can work with. Having more voltage is an advantage in electronics design: it really makes things a bit easier to design electrically. (Less noise, less hysteresis issues, etc. etc). A rail-to-rail OpAmp still only has +/- 2.5Vs at the 5V level, but that's a lot more voltage to work with than +/- 1.65Vs at 3.3Vs, especially if the rail is losing 0.2Vs as is typical. (+/-2.3V once you lose 0.2Vs, but only +/-1.45V on the 3.3V system). Traditionally, OpAmps operated at +/- 12Vs for a reason, the larger voltage just gives you more room to play with. Throw down 100mV to noise 5V also opens up the possibility of running off of a USB line without any voltage-regulation. An important-trick for sure.
meekrohprocess 6y ago
They have a much shallower learning curve and a large moat of people who have used them for decades, simple as that. These days, AVR chips are a stepping stone to learning embedded development. They're fine for very cash-strapped beginners, but it would behoove new developers to leave them behind quickly. They are more expensive and less efficient than modern options, and you won't find many well-paying jobs asking for AVR/Arduino experience. STM32 chips are a much better option, IMO, especially for beginners. They come in sizes ranging from <$1 Cortex-M0 chips up to dual-core Cortex-A/Cortex-M processors, and they use the same sorts of peripherals across all of those product lines. So you can start small, and incrementally learn about more complex parts and topics. And if you really need a breadboard-friendly chip, an MSP430 is probably a better option. It's a 16-bit MCU focused on power efficiency, and it has GCC/Arduino ('Energia') support. Some of them also have non-volatile FRAM memory.
kps 6y ago
I have three projects in progress and chose AVRs. Part of it is the voltage flexibility that dragontamer mentioned — two run off USB power and include 5V SPI LEDs, and one runs off unregulated 3×AA. The other part is simplicity and directness — I can just write *PORT=0x42 rather than rely on some vendor BSP that doesn't address my use case and will be deprecated next month.

Arduino support (STM32 has it now but only relatively recently and with substantially less libraries), better availability, less of a confusing hardware landscape with numerous minor chip variants and 'pill' form-factor hardware versions with wacky incompatibilities, more open source PCB designs available, inertia...

dragontamer 6y ago

Its not about CPU-power, its about electronic flexibility. AVR has 1.8V to 5V power tolerances. STM32 boards have 1.8 to 3.6V tolerance. (Yes, STM32 boards can have 5V I/O tolerances, but you need the power line to be ~3.3Vs) This means that you can run an AVR system from 3xAA batteries or Li-Ion without much more thought involved. STM32 is more complex: 2xAA works, but that's much less energy than 3xAA. Lithium Ion is nominally 3.6Vs, but when charging Li-Ion can be 4.2Vs IIRC, so you're going to need to protect the STM32 from the higher charge voltages, because 4.2Vs is out-of-spec. This means that STM32 needs an external voltage-regulator module, while the AVR can just happily accept the 4.2V voltage-under-charge under a Li-Ion setup. ------- The 5V that ATTiny or ATMega supports can also deliver more power from its I/O pins. STM32 is pretty impressive with 15mA source/sink from 3.3Vs, but ATTiny and ATMegas are specified with up to 20mA at 5Vs, both source and sink. That's a lot more potential wattage you can source (and sink) from a raw I/O pin. ---------- So consider what you need to do if you have a 5V line (3x AA batteries): you'll need to create a safe 3.3V line for your STM32, you'll need to have a reference 5V voltage that your ADCs are based off of, and you'll need a voltage-converter to handle all of your 5V electronics. Or, you can just throw an ATMega or ATTiny at the problem, and just run your entire system off of 5V (ADC, I/O pins, everything). In my experience, the higher voltage (5V instead of 3V) has a lot better op-amps, and other such devices, that you can work with. Having more voltage is an advantage in electronics design: it really makes things a bit easier to design electrically. (Less noise, less hysteresis issues, etc. etc). A rail-to-rail OpAmp still only has +/- 2.5Vs at the 5V level, but that's a lot more voltage to work with than +/- 1.65Vs at 3.3Vs, especially if the rail is losing 0.2Vs as is typical. (+/-2.3V once you lose 0.2Vs, but only +/-1.45V on the 3.3V system). Traditionally, OpAmps operated at +/- 12Vs for a reason, the larger voltage just gives you more room to play with. Throw down 100mV to noise 5V also opens up the possibility of running off of a USB line without any voltage-regulation. An important-trick for sure.

meekrohprocess 6y ago

They have a much shallower learning curve and a large moat of people who have used them for decades, simple as that. These days, AVR chips are a stepping stone to learning embedded development. They're fine for very cash-strapped beginners, but it would behoove new developers to leave them behind quickly. They are more expensive and less efficient than modern options, and you won't find many well-paying jobs asking for AVR/Arduino experience. STM32 chips are a much better option, IMO, especially for beginners. They come in sizes ranging from <$1 Cortex-M0 chips up to dual-core Cortex-A/Cortex-M processors, and they use the same sorts of peripherals across all of those product lines. So you can start small, and incrementally learn about more complex parts and topics. And if you really need a breadboard-friendly chip, an MSP430 is probably a better option. It's a 16-bit MCU focused on power efficiency, and it has GCC/Arduino ('Energia') support. Some of them also have non-volatile FRAM memory.

kps 6y ago

I have three projects in progress and chose AVRs. Part of it is the voltage flexibility that dragontamer mentioned — two run off USB power and include 5V SPI LEDs, and one runs off unregulated 3×AA. The other part is simplicity and directness — I can just write *PORT=0x42 rather than rely on some vendor BSP that doesn't address my use case and will be deprecated next month.