>Unfortunately Arduino "experts" have this bad habit of spending a lot of time to do things wrong, then proudly and authoritatively dictating their esoteric hacks and myths to impressionable newbies.
Counterpoint: I think it's cool and fun that there's still a tech community which thrives on goofy hacks which aren't "correct". If you're programming an ESP8266 with the Arduino SDK, you're probably not working on mission critical stuff anyway, and this kind of thing represents a hacky spirit which I think is otherwise largely missing in this era of computing.
I agree completely, but I recently discovered that this stuff has a tendency to leak beyond where it belongs.
Arduini are fine for prototyping, learning, and hacking, but I would avoid the software ecosystem for commercial products. Unfortunately, those raised on these boards do not see the peril of its hackery, and they will incorporate it into products. That’s where things start to go off the rails.
I am currently working on a bringing up a board that replaces one that included an entire 40-pin DIP board. That Arduini-based solution is difficult to maintain and fragile.
These are fine for hobbyists and experimenters, but please use a better tool chain if you need to do real work.
I find it useful for the ESP to import the Arduino libraries as a component in the espressif toolchain. Saves a lot of time when I can just use the Arduino code for the stuff i'm too lazy for (ie handling ethernet) without compromising functionality.
ESP8266 and ESP32 both have deep sleep. CAn't remember the ESP8266's details but the ESP32 even has an auxiliary processor that can run during deep sleep and do trivial ALU/memory work to collect data or wake up the device. My friend made a temp sensor that runs on battery with an ESP32 and it runs > 1 year without a new battery.
Yes, and sleep(), delay(), yield() in Arduino Core for ESP* are task switch to and from Wi-Fi handling code, not busy-loop delays. Espressif seems to have put a lot of scaffolding for you behind the Upload button.
What if OP is just a hobbyist who only knows Arduino and doesn't want to learn a whole new SDK just to toy around with microcontrollers in their spare time? I respect posts like this. They are fun and cool.
If you must use ESP8266 for some reason, then completely agreed. ESP8266 is obsolete now though, there are far more capable ESP32 variants, some of them specifically designed and marketed to replace the 8266 and to make transition as easily as possible. Not to mention the benefits of a now quite mature ESP-IDF SDK.
Arduino is a great onramp to embedded, but it really needs an offramp.
I for one still have plenty of esp8266 based nodemcu/wemos around the house, they still do just fine for most hobbyist purposes and the RTOS SDK is just as pleasant to use as ESP-IDF. Most of the API is the same and they have example code for almost everything.
I also have several smart plugs from different vendors, smart bulbs, one thermostat, a camera, all still using esp8266 and doing just fine.
That's a very ignorant statement; they are still in production and entirely enough for many use cases, just like original arduinos are.
They are also like $2 a pop for whole breakout board and less if you make actual device.
I do agree if you just want to tinker the tiny extra for ESP32 is probably worth just for tinkerer but there is still a plenty of devices (in IOT space mostly) that are just "ESP8266 + some peripherals" and thus nice and hackable
"Original" Arduino on the ATMega8 is fully obsolete and should be moved off of. Fortunately, it wasn't that popular.
"Arduino Uno" (which popularized the Maker movement in 2010) with ATMega328 is also obsolete. You should use ATMega328pb at a minimum (but even then, the 328pb is nearly a decade old now...), or really the AVR DD chips that are cheaper, faster, simpler, more powerful. Ex: AVR64DD32
To explain how absurd it is... the AVR64DD32 uses 4.7mA at 24MHz fully active.
In contrast, the old ATmega328 uses 12mA at 20MHz (its limit), and 3.5mA while idle (aka: 1st level of sleep).
So an idle (1st sleep) ATmega328 uses basically the same power at a fully active AVR64DD32. Indeed, AVR64DD32 only uses 500uA (microAmps) at 4MHz fully active, so it can "busy loop" with less power than a sleeping ATmega328.
AVR64DD32 costs $1.67 at lot size 1 from Digikey. ATmega328 costs $2.73 for lot size 1 from Digikey.
ATmega328 comes with 32kB of Flash and 2kB of RAM. AVR64DD32 comes with 64kB of Flash and 8kB of RAM. It completely dominates the older chip in every possible regards.
------
Original Arduino Uno is still a great learning tool. But there have been over 10+ years of improvements to these chips. Anyone actually dipping down into AVR programming should prefer the newest chips.
IMO, Arduino Uno should be seen as a learning tool. Fortunately, all of the stuff (ex: Assembly language, sleep modes, etc. etc.) still apply to the AVR64DD32. The peripherals have changed though... USART rather than UART. DAC included, OpAmps in AVR64DB32, etc. etc. Integrated dual-power supply on AVR DD chips (PortC can be on a 2nd voltage level, so its basically an integrated level-shifter). Full 24MHz speed at 1.8V (ATMega328 has this annoying "derating" curve, where 1.8V can only handle 4MHz).
But no one should be using ATmega328 in new "serious" designs. Its just "still" useful because all of those old tutorials from 10 years ago still work today. So it has the most tutorials written for it, and should remain "steady" as a learning platform.
But anyone taking the next step (learning the actual chip, learning how to solder, learning how to breadboard), needs to switch to the newest chips. The newest stuff is just cheaper, faster, and easier in practice. And still _mostly_ compatible with the old ATMega328 (same assembly language. A superset of the features. Similar concepts in layout / design, etc. etc)
I wasn't being clear enough, I meant "over just picking some ARM part".
Is there any actual benefit over just going for some Cortex M0 aside from "run old stuff on it" ?
I started my adventure with AVRs and avr-gcc, played a bit with arduino but nowadays there doesn't seem to be a good reason to pick them, M0s and M3s are cheap and plentiful and usually better specced for the price
The old ATMega328 is obsolete. That's my point. There's a ton of chips that are better than ATMega328.
But if we're talking about _MODERN_ chips, like AVR64DD32, the modern successor to ATMega328, with AVR assembly language, GCC support and all that jazz...
EDIT: AVR64DD32 is basically a "modern ATMega" btw. Its not an ARM, its an AVR processor. Is this the point of confusion?
* Running directly off of 5V USB power without any voltage regulators is a neat trick. No ARM Cortex M0+ part I'm aware of goes above 3.6V (they're designed for Li-ion cells). Dropping down to 1.8V is also a neat trick, the AVRs have a very wide practical range of voltages.
* Dual power supply. PortC of AVR64DD32 runs off a 2nd power supply. So the AVR64DD32 can run off of 5V USB power, and with an external LDO regulator can have PortC running 3.3V. (Aka: integrated level shifter). You know, for all of that annoying 3V crap that you need to integrate with 5V other crap.
* The big-brother, AVR64DB32 (the DD turns into DB. Confusing, yes, I know), has 3x OpAmps. Meaning you don't even need a power supply anymore. You can power PortC / secondary I/O lines from the integrated OpAmps on the AVR-DB.
If you upgrade to the bigger AVR DB in the series to $2.00 to $3.50... you get 3x rail-to-rail OpAmps with integrated resistor ladders and suddenly you're in a very flexible mixed-signal world.
I think STM32G4 chips have integrated OpAmps. But these are $7+ chips and a ARM Cortex-M4 (much more expensive / complex / bigger than the M0).
> M0s and M3s are cheap and plentiful and usually better specced for the price
Which one? AVR64DD32 is 64kB of Flash and 8kB of SRAM for $1.60.
Cheapest STM32L0 I can find is $1.82 and only has 2kB of SRAM. And it doesn't go to 5V, doesn't have integrated level shifters, op-amps, or any of the other neat tricks... (And STM32L0 is a _very_ competitive Cortex-M0+ line in my experience).
Like, we all want to just code our way out of problems. But sometimes, you have a 3V thing that you need to connect to a 5V thing. And AVR DD is the perfect tool for that.
------
EDIT: Ah right. And ATMega328 can still sink 20mA to fully turn on an LED without any MOSFETs / external amplifiers. I think PIC is the only other major line of chips that has this feature. AVR-line is legendary for its current source / current sink strength.
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 with other Arm platforms.
Yeah, that's definitely the biggest advantage to ARM in general. It scales really high.
8-bit MCUs scale lower though... down to 32B, bytes (not kB) of RAM... and other such designs. This ~$1 to $3 price point is really a battle between "the biggest 8-bits" (PIC/AVR/8051) and "the smallest 32-bits aka ARM" (with TI being weird with a 16-bit MSP430 sitting comfortable)
If you're thinking of "scaling down" to sub $1 (or more importantly: lower power designs), 8-bit wins. If you're thinking of "scaling up" to $10 (or higher-power, more CPU-intensive designs), 32-bit wins.
--------
EDIT: Honestly, the coolest thing about this XMC1 seems to be the LED controls at the XMC1202 chip, closer to the $3 price point. The XMC1100 are a bit feeble / low end and weaker than the 8-bits I'm familiar with at its ~$2ish price point.
9-channels of LED with 12-bit exponential voltage controls means you can probably offer a full 32-bit color off of those RGB LEDs. And with 50mA per pin, you can probably just drive those LEDs without any resistors.
EDIT: Ah, looks like 50mA pins are the "high current" pins. Only 6 high current pins on the XMC1100. The other I/O pins are 10mA. So resistors are still needed, but that's still a lot of nifty control for those LEDs.
That reminds me of https://jaycarlson.net/microcontrollers/ "$1 microcontrollers" with all of the weird and wonderful variations. Probably not actually $1 after the chipaeddon tho.
Yeah, its those stories hitting the top of Hacker News that got me looking at modern uCs again, and thinking of a hobby-project to do with 2022-era tools.
That page is still a bit out-of-date now. 2022-era uCs have taken a sizable step forward compared to 2018-era... though inflation / chipaeddon has made everything more expensive.
But peripherals, power-usage, Flash/SRAM, etc. etc. are all getting better across the board. Its just one of those 'tredmills', you can never really be an expert on the market, cause the market of chips keeps changing so quickly.
Oh, chipaggedon... I was few weeks off trying the assembly service (think it was on seeed studio?) of small dev board, and then I realized near nothing I had on it was still in stock. Even managed to run Rust on the previous breadboard iteration of the project.
Year and half later I got all the parts finally delivered...
> But peripherals, power-usage, Flash/SRAM, etc. etc. are all getting better across the board. Its just one of those 'tredmills', you can never really be an expert on the market, cause the market of chips keeps changing so quickly.
Sure but you can stay on same chip family for 10+ years and just grab new part when you need features. Especially on hobbyist level there isn't that much reason to chase the latest and greated
I work with artists who build great teetering cathedrals on top of Arduino(and Processing), and it's really difficult to incrementally move to a more serious solution once things have reached a certain level
Specifically the things it does that bake in bad habits are:
- Encouraging globals
- Everything in one namespace
- Arduino is not C++
- not needing pre-definitions(mostly) and spamming all .pdes into the same file leads to tangled code that's really hard to pull apart into modules, even if it's separated in tabs in the Arduino editor
- delay: not composable!
- for esp specifically:
Thinking in terms of a single loop function Vs multiple rtos threads
- the ide is terrible, and encourages a copy-paste workflow because that's how best to work within it
Use Platform IO (I use it inside Visual Studio Code). It's C++. You don't have to use globals. .pde is processing, it's not required to use that (I write python scripts that talk over serial instead). ESP32 in Arduino supports multiple threads (cores).
> Arduino is a great onramp to embedded, but it really needs an offramp.
Does it?
PIC-BASIC was the great onramp like 20 years ago. It never got an offramp. Arduino just did it better / simpler, and all the hobbyists switched to that.
Nodemcu's lua is a reasonable option too. In terms of offramps, platform.io can get you moving towards the doors anyway. I haven't used it with esp8266, but on ESP32, you can switch between arduino and esp-idf; of course, if you use arduino components in your build, you still need them; you can use arduino as a component in esp-idf. It's a little fiddly, but I could see replacing components bit by bit until you run out of Arduino.
