What's missing from this announcement for me is a comparison of current draw, sleep states, etc.
It's nice to get more powerful within a form factor and voltage and so on, and I realize many applications don't care about energy use, but increasingly the metric I care about with DIY/MCU gear (and my phone and my laptop is) "watt-for-watt performance increase".
With DIY stuff especially because I build battery-powered things here and there, and recharging once a year instead of once a month is a massive reduction in nuisance for stuff around the house. I dream of low power compute where I can consistently get away with solar or kinetic energy harvesting to reduce operational maintenance to 0!
I'm a bit lothe to admit it, but for beginners... anything under 50mA probably doesn't matter. So that includes Teensy Boards, RP2040, Arduino Uno, this new Arduino, etc. etc. A typical LED draws 20mA for example, while WiFi will draw 100mA or more. Ethernet also draws 100mA+.
So its very difficult for a beginner to "care" about anything below 50mA. Its just not something worth caring about, because everything else in your circuit uses so much more power.
-------
> With DIY stuff especially because I build battery-powered things here and there, and recharging once a year instead of once a month is a massive reduction in nuisance for stuff around the house. I dream of low power compute where I can consistently get away with solar or kinetic energy harvesting to reduce operational maintenance to 0!
Just search on UltraLowPower (ULP) microcontrollers, such as the STM32L5 (or the next version: STM32U5, whenever that comes out). Low-power microcontrollers are measured in "microamps per MHz".
That's 16uA / MHz active on the STM32U5. Though it fails at the lower end of things (~1mA or ~2mA is just the cost of the clock itself, so you can't drop below that in active mode. Sleep modes turn off the clock of course and allow the ~100nA to 500nA sleep modes on these ULP chips though).
STM32U5 isn't alone btw. There's plenty of competitors for this ultra-low power field.
The LEDs on these little development boards are typically big sources of current draw too. Like the main CPU can go into deep sleep sipping microamps of power, but the power and other LEDs sit there with a resistor pulling tens of milliamps all the time.
I know all of this of course (but nevertheless thanks for spreading useful information) :-)
What I'm saying is that I would really like this type of announcement to not take shape of absolute performance increase but at least include, if not focus, on performance-per-watt. I honestly don't agree with the "beginners won't care" - battery life is not a difficult concept and battery-powered projects are super common.
And I think it is on Arduino to do this, since the value they provide as a middle-man is to package this BOM up as a product and explain it and their product design choices.
As a sibling points out power efficiency can also vary with other component choices on the breakout board, e.g. the power delivery or included BMS. This is also something Arduino could optimize for and market as they productize. The MCU datasheet isn't everything.
20mA is an equivalent of a typical LED. And if that is too much for you to power a microcontroller you do what you do with a normal LED -- you do not power it all the time and instead you use it when it is needed and put to sleep when it is not.
So I fully agree with the parent comment that for an amateur once you got to this point, further improvements on power efficiency here is pretty much inconsequential. It is not like you are going to be building a watch or a sensor that will have to work for years on a single AAA.
A 20mA microcontroller will be sufficient for pretty much any project an amateur can think of, power usage wise.
"Putting it to sleep" is where a lot of details matter. Different MCUs don't have parity on what sleep states and options they offer and what they mean in practice. Often there are complex tables where certain wakeup schemes are only available in certain sleep states, and to extract minimum idle draw you need to know what you're doing.
The Arduino framework currently offers only minimal abstraction over this. If you use Arduino on an esp32, you have to reach into ESP-IDF API to dial in the details, e.g. set up ext1 wakeup and disable the RTC memory explicitly if you don't need it. Betting this is the same here at launch.
Arduino here is introducing two versions of the same product with widely different BOMs and not addressing this matter at all.
I think it'd be a great enhancement of their productization effort if they started explaining power envelope, showing improvements over time, standardized an API (derived from actual use cases) etc. This would add value over the raw chips and datasheets for their audience of beginners looking for ease of use. Without it this is just throwing some random new breakout boards with the same layouts over the fence - a very crowded market - and banking on ecosystem effects without evolving the ecosystem and tackling new aspects.
As an amateur EE I am looking at Arduino as an entry-level solution for people who want to learn a bit about electronics and have fun getting some results.
Arduino is supposed to be simple and it is a feature, not a bug.
If they start making it more and more complicated, it will just stop being simple and it will stop being what makes it so usable to complete noobs.
There is no shortage of options if you somehow find that Arduino is not powerful enough to you.
Well that's sorta the point - they're making it more complicated here (same name, two completely different BOMs with different behavior). An improvement would be to make power management and low-power projects beginner-friendly (e.g. by expanding the API framework) and a compelling announcement would be showing that off. For me it's still a curious omission.
Nah, two different BOMs isn't making it more complicated. In the end you hold a board in your hand and have to figure out how to get from it to what you want.
Or think in a different way: A board you have in your hand does not suddenly become more complicated because the company comes up with another board with different BOM. Maybe choosing the board becomes a bit more complicated, maybe choosing any addons for the boards becomes a bit more complicated (as you have to navigate compatibility), but using the board -- I don't think so.
Just from a glance at the microcontroller datasheets, it looks like the RA4M1's current draw in "Software Standby" mode is much lower than the older ATmega328P's "power down" mode (5μA vs. ~50μA).
But IIRC, the voltage regulators in previous Arduino boards already waste orders of magnitude more current than that, even while quiescent, making them not very suitable for battery-powered applications. So it remains to be seen if the R4 board improves on this.
One thing that's makes the product line a bit hard to reason about is that they have a Wifi and a non-Wifi version using two very different MCUs with very different power use characteristics. I.e. even if you have Wifi disabled on the Wifi version, it'll behave very differently from the non-Wifi board. People looking up numbers or experiences will have a harder time.
Add to this that afaict, the Arduino framework API currently doesn't provide fantastic abstractions for power/state management either. I had an Arduino-based esp32 project once and extracting best deep sleep performance definitely required reaching lower into ESP-IDF API instead (e.g. the difference between ext0 and ext1 wakeups and being able to shut off RTC memory in one but not the other).
That means with the current framework, you have to potentially write non-portable code between two different versions of the "same Uno R4" if you want to optimize for low power.
All of embedded is like this, really - scanning through and understanding a product line is basically a required skill - but meh, what a mess for beginners.
I could be wrong, but my reading of the post was that the Wi-Fi version has two MCUs - the main RA4M1, and the S3 WiFi module. So, if you turn off wi-fi, they should be effectively the same board.
I'd wager that 99% of Arduino enthusiasts (and a good percentage of industrial hw engineers...) do not have a habit of using power save modes on bare metal.
I agree, considering that much of their marketing surrounds DIY automation and they have this whole IoT cloud platform now, they very little support for low-power operation. In this regard I think Adafuit and Seeed platforms do much better, while still being very beginner friendly.
It's nice to get more powerful within a form factor and voltage and so on, and I realize many applications don't care about energy use, but increasingly the metric I care about with DIY/MCU gear (and my phone and my laptop is) "watt-for-watt performance increase".
With DIY stuff especially because I build battery-powered things here and there, and recharging once a year instead of once a month is a massive reduction in nuisance for stuff around the house. I dream of low power compute where I can consistently get away with solar or kinetic energy harvesting to reduce operational maintenance to 0!