Current consumption in different sleep modes is also very interesting. A lot of applications uses sleep mode to cut power usage.

Very informative, thank you! The flexibility of these microcontrollers is pretty amazing, allowing them to fit a wide range of use-cases.

That's a lot of hard work, Gary. Thanks for doing this!

Great video! Thank you for doing all the work. I’m sure this took a considerable about a time.

THANK YOU! A really well made clip, explaining the efficiency and how it was computed, all the steps required to asses a particular chip when figuring out your particular case. Rarely there's a mention that other things on the board need power too, so if you care about that, you should think about that. So very nice to see, also with numbers, the difference between the same microcontroller, but in different boards, how much different it can be in both performance and power consumption and performance/watt too! Rarely there's a mention in the quality of the benchmark and the relevance of it (in this case that it basically uses just the CPU/compute intensive, and doesn't stresses the RAM bandwidth or latency or the SD card/SSD. Because in the end, when basing a decision on this efficiency, the task(s) that will/would be run should be taken into consideration. And of course, it's nice to see relevant adjusted numbers so they can be compared easily. Like performance / MHz and total energy required to run a task, in mWh. While, conceptually I didn't really saw something new, that I didn't knew before, this is a video (or style of presentation for this topic) that I wanted to see for a looong time. Others usually rush a bit and only present the benchmark numbers and 1-2 calculations based on that. They don't focus on providing the full picture, to point to all things that can vary. For someone who has no idea how these things work, it's really good to know what to look for/at, not focus on one single thing. I have to say, I didn't knew that the Pi Pico is so efficient. Very nice to see that! Also didn't knew about that Magma Splash and that it's made in Romania. That's where I'm from! :D Though to fair, I didn't got to play with microcontrollers and SBCs yet, though I planned for a long time to, just never been forced to and never felt like having proper time and space to play with one.

Definitely interested in more tests, especially involving risk-V. I would love a glimpse of the asm output (just the inner loop) to be sure the differences are not down to the compilers being less clever with some of the cpus. Gary, you are such a resource, there is no way you are getting enough paid for this. 😊

Awesome video Gary. More of these please.

Its a great concept to benchmark MCUs please carry on doing it , thanks alot

Great review video Great to see good compered chips video Thanks for sharing your expirence with all of us 👍 😀

@Gary, Thanks for this vvideo! I am very interested in seeing what other benchmarks you could make to compare microcontrollers like this. This one helped me to decide which controller to use in one of my current projects. I figured out that the esp32's I already have will do what I need. I was thinking that I would have to buy something with more processing power.

Great info! this is exactly what I needed! Looking forward to the comparison with the RISC-V!

Good and solid comparison! Great work!

This was very useful Gary. Thank you.

Thank you, Gary, for your most Appreciated, Articulated Interesting Hard Work.

Great video, and explanation. Thanks! Subscribed I'm going to stick with the LOLIN ESP32 boards. I have many Wemos D-1 minis at work 24/7 for a few years without fail. Just started playing around with other boards. I have a LOLIN ESP32 Pico and Pico W. ESP32wins in my book.

Very nice comparison, Gary! Much appreciated. ST has very low and ultra low power microcontrollers designed for battery applications. These are the L series and the U series. They also have the H7 series that can run up to 550MHz (I LOVE these faster boards, btw). For the Nucleo or Discovery boards, looking at the power consumption is a bit tricky, as these boards come with ST-LINK which if active, will draw power too (ST used to use an STM32F103 for their ST-LINK, which is the same uC as the bluepill). So you'll need to use an external serial programmer with these while disabling ST-LINK. Furthermore, using Arduino IDE is a bit tricky, as you never know how the uC is set (which peripherals are turned on). This is one instance where using CubeIDE offers so much more control and optimization features compared to Arduino IDE.

It feels like this channel is reading my mind, great videos btw!

Enjoyable and informative video. A factor in the processors efficiency is also how much it consumes while idle (or asleep), the total efficiency is the sum of the power whilst active plus the power whilst idle over a given period. Also not mentioned is the scalable clock on the Pico, this can run from 16MHz up to 420MHz ,(albeit with some some issues/workarounds), and can be dynamically changed over a program cycle. Having this scalability in clock frequency can give the user much more flexibility in their design. The overclocking is discussed in a pair of Robin Grosset videos on youtube. In comparison the ESP32 can only operate at 80/160/240 MHz. I don't know what clock rates the other controllers can operate at.

Nice video. It would be interesting to see how the new RISC-V MCU's compare to these. I have been playing with some GD32 dev kits as a potential replacement for some STM32 devices we make. Performance is roughly the same as the STM32 series but power consumption is lower for the test kits that Im using

It might not be so important for most applications, but I think it'll be very interesting to test floating point performance on this boards, since some of them don't include a floating point unit. Pure floating point workloads might not be very realistic, but at least some mixed workloads could be relevant. I can think of a applications, like a PID controller, that could easily apply to this microcontrollers

Really great video. We've used the cortex M4 in an embedded railway application to great success in the past for control. I think there is forward compatibility with cortex M4/M7 as well.

A related question is how much power they use when doing nothing. That is, if the fastest boards are put into a reasonable (wake-able, say by timer interrupt) power save mode when they complete the task, what are the total maH used over the period of time that the slowest takes to complete the task? And over ten times that long? The energy cost of other operations, for example, I/O operations, is a whole other interesting kettle of fish when choosing a board for best battery efficiency in it's given application. But thanks for this data. It gives one a leg up.

Always interesting!

At these numbers the regulator on the boards play a measurable role in power consumption as well. The ESP32 devkits especially the stock chinese ones have a big but not very efficient linear regulator.

A couple of points to note about this, you also need to consider the manufacturing process used as well. The process can have a big impact on energy efficiency, ie a lower process node will do the same work with lower power. In the comparison of the PI Pico vs the ESP 32 though, the process used was the same with both chips. However, it may explain why some ARM chips were not running as efficiently as others.

really good video 👍🏻

The PICO is really great for most things other than its sleep current draw. The STM and probably they Microchip part are orders of magnitude better in this. For the classic battery powered IOT device that might wake up every hour, do a bit of number crunching and transmit the result, the energy consumption is overwhelmingly the sleep state. Would be interested to see how the ESP chip does this as IOT is it's main use case. The M7 and H7 chips are great when you need raw performance and have less concern about power draw. I see these used a lot on drone flight controllers. The power draw really doesn't matter compared to the motors and the ability of the MCU to instantly switch on, reliability and plenty of grunt wins out.

Really interesting video Gary thanks. This will probably sound stupid but I also want to say thank you for pronouncing Nvidia as en vidia, instead of how I've heard literally everybody else, (aside from me) say it, which is nur vidia! They may be right and we may be wrong but I much prefer your pronunciation. 😁

Hey Gary, I really enjoyed this video. I’m sure many others have commented on this but if you cast those integers as floats and ran the same test, you would’ve seen extremely different results. It would be interesting to use a 50/50 integer and floating point workload and run the test again. The cortex M4Fs and M7s have built-in floating point hardware, as does the ESP32. The M0+ boards chug away with software emulation. The Pico would get hammered in this test.

I have XIAO-ESP32-C3 from SeedStudio sitting on my table, could you guide me to the exact same code you used for tests, so I can run on it and get some timings? I think, it does worth to include this tiny module in your benchmarking reviews next time. Thank you and respect for the effort and quality job you are doing. Best regards

Nice video on a difficult topic. A 8-Bit AVR as bottom anchor would be nice. And of course the ESP32-S3 should be included.

Hey Garry i love watching your videos . If possible make a video on snap 8 gen 2

Image processing is a nice heavy useful benchmark. I run motion detection and jpeg decompression on ESP32 and it really pushes.

Very nice results, please can you make a hardware and software floating point calculation comparision because here will shine the M4 ,M7 and ESP32 as i think.

I'm looking forward to Risc V evaluation.

Gary, Please, load me up on benchmarks..!! Any boards you can get a hold of. How about benchmarks such as... - Matrices operations - String comparisons - Power usage for IoT sensor read scaling (e.g. 1/s incrementing to (n)) - IoT with multiples of sensors - IoT remote push, and pull.

Price is also an important factor. Do include that and price to performance ratio as well.

Is relative performance a (i.e. performance/clock speed) more a measure or software , firmware and compiler or a measure of hardware and architecture?

It's great to see performance comparison normalised to performance/hz - but it's still pretty much abstract and academic. In reality the only real world measure is performance/dollar (or euro/pound) It would be great if you could include this.

This makes me wanna see you do an analysis on apple’s “effecient” cores, nice work

When the Pico's Bluetooth comes online, which is already there on the ESP32, Will the power drain go up on the Pico W?

I would love to see power consumption results with some higher precision. To be honest 1mA granulity is not so great and whole calculations seems really crude. Btw, how did you get those current numbers? Did you capture whole current profile for the board and calculate the mean of it?

Great video and lots of details. Just curious to understand if the ESP32 was running with dual core or single core for all the measurements. If it was dual core, it would be great to know how these numbers change if 1 core could be powered off. Will the performance degrade or was the code single threaded and only the power will decrease..

I wonder what would be the results if you didn't use arduino libraries (ideally CMSIS for arm chips). would the performance be better for all of them or some of the boards would catch up to eachother. honestly I knew bluepill would lose but didn't expect that much of a gap since it's not floating point operation. Sleep mode power consumption comparison would have been interesting too.

Yes do a more extensive test pls!

Had there been a meta block that would let you matel the probe of the ASETEK Vapochill Lightspeed Phase Change Cooler unit with the Raspberry Pi IV but also keep the moisture away from the electronics of the SBC then that might be a idea.

Gary, it would be interesting to see the results running your test program using both cores of the Raspberry Pi Pico.

i loved it when you hosted back then at android authority and now I love your own content more

Where power is limited such as in space projects and time is not an issue, I can see them using boards such as the pico.

Hi Gary, not sure if this question makes sense, but I believe the Pico has 2 cores, did your trial use both (I assume other boards have multi core, did you use those)? If not, I'm guessing that would make a difference to speed, but how much difference to power usage?

Very detailed and interesting and yet convincing comparisons. I wonder how the AVRs would fair in similar comparisons since many hobbyists are still sticking to them and some argued that the AVRs are more power efficient..

What equipment do you use to measure electric power consumption?

good comparison but power saving/sleep/deep sleep modes power consumption in Wh or actually nWh are very imporant too.

Could you re-run the tests of the ESP32 using both of its cores? And maybe add the cost variable in the mix.

Hello Gary, the ESP32 sports a dual core CPU. I was wondering if the benchmark tests accounted for it

Since you used the arduino ide sketch for both the esp and the arm m, wouldn't the underlying arduino core also affect performance? I wrote a simple program for the blackpill using the arduino stm core and also the stm HAL library(stm cube ide), the difference in code loop time is very big. Arduino core 300kHz, HAL library >1MHz.

I'd like to see a comparison with the new ESP32-C3 with the RISC-V core

We’re both cores used on the PICO?

Looking forward to seeing the ESP32-S2 (or what the Risc-V model number is) in comparison

I'm wondering what would be the results if you will use both cores of pi pico

@8:28 The units are seconds/cycles/second, so just "cycles" (shifted by whatever order of magnitude). This is a plot of how many clock cycles it took to run the algorithm.

I would be interested to also see how these compare to the teensy 3.2 and teensy 4

Is this data available on a repository like GitHub?

I would love to see a much broader and more intensive benchmark!

Or if you really need some more performance, step up to the ARM Cortex-M7 at 600 MHz (native, up to 1Ghz overclocked) on the Teensy 4.x series. I'd love to see what they do with the M8 or M9.

Interesting how clock speed seems to matter a lot even across completely different architectures. The architecture only matters a little bit.

@1:00, what about MIPS processors like the PIC32?

I feel like most microcontroller projects are not math-intensive, but timer or interrupt driven-especially the battery-powered ones. I’d also be curious how the ESP32 would compare at calculating primes if you used C++ code.

Q: is #DDR5 memory *10 times faster* than the old brand X memory?

Can you please include cost of each mcu?

another question i have, what is the mWh for say a pico, running at 10mhz? 50mhz? 100mhz? does it get more efficient at lower speeds? or higher speeds? what if you clock every board, so they all complete the benchmark in the same amount of time, and have equal performance/time ratings will the relative mWh performance change?

The RP Pico will run at 250MHz all day. It can do over 400MHz but inevitably will have some issues with I/O not working properly.

Hey, Gary. How about a comparison between STM32F4x1 Blackpill vs Raspberry Pi Pico?

Hey, did you turn off/disable the WiFi in software? Asking because I know you can do this for the esp32 and that's supposed to make the WiFi chip use a lot less current.

I would love to see more benchmarks because the STM F7 series is not really comparable to the ESP32. The M0+ and M4 are more in the same tier. I think the FPU tests will show a lot more of the ARM strengths.

What I find interesting is how well the Pico M0+ holds up, the fact it’s dual core with a highly repetitive task like this could put it on par with the STM32 F7 board, and the ESP32 also being dual core would move in front, both are quite inexpensive too

Could you try again with the new esp32 s2 and s3? Maybe the risk v c3?

Also note that ESP32 has 2 cores, and I don't think you can shut one down. So distribute the prime factoring task among two cores should improve the power efficiency a bit? 🤔

Gary, would you specify which ESP32? Since you say LX6, I believe you are using the original ESP32. The newest ESP32-S3 uses an LX7 processor. The new ESP32-S3 is basically the equivalent to the old ESP32 and the new ESP32-C3 is equivalent to the ESP8266. The latter is a closer match to the RPi Pico in terms of perf/power mix. Additionally, the quoted consumption of the ESP32 in the video looks like maybe both cores were active. The ESP32 (and probably the STM's) can shut down one core to have more favorable power profile. From its datasheet, the ESP32-S3 claims to scale from 1 core 40Mhz 32b inst at 22mA to 2 core 240Mhz 128b instr at 108mA. Quite a range! In any case, thank you for making this video. It would be excellent if you and Andreas Spiess (or others) would coordinate testing methods so we mortals can more easily compare apples to apples.

I'm regards to power consumption, you can shut off WiFi. There are even ESP32 variants without WiFi. It would be interesting to see the power consumption of the system itself without peripherals like WiFi.

Great job, just one question: Isn't it TRIAL BY DIVISION...not TRAIL BY DIVISION.

esp32 boards uses linear regulator that waste like 40% of the power , pico board uses a dc-dc buck-boost regulator . Just run the esp32 with 3.3v by the 3.3v pin and retest .

What about dspics?

It seems like the test was run on a single core. ESP32 double core calculations is tricky thing. In default setup it uses second core to handle Bluetooth and Wifi network stacks.

Thanks for the video. Int32 is one thing, int64 is another. Try the double float on the Teensy 4@816Mhz, K210@600Mhz, Pi Pico@240Mhz and you will see all the differences! BTW, ESP8266 is really good on integer, better than ESP32. And ESP32 S3 is much better than ESP32! STM32's compiler is really smart. If you use -O3, when add up from 1 to a million, the compiler will give you the result rather than STM32 doing the real calculation in run time!!!

the rp2040 and the ESP32 (some of them) are dual core and i expect that your sketch only ran on 1 core so in a way it is not the full power

It could be mildly interesting to compare the efficiency of a few different single board computers and also compare those to a handful of older phones, since they're basically just computers you could for example repurpose one sitting in a drawer as a pi-hole or an octoprint server instead of spending $40+ on a RBpi.

Happy I skipped to 17:15 before commenting… Anyhow would have been great if you could have emphasis power consumption… Eg either trying for a relatively similar execution speed to compare power usage or oppositely for a relatively similar power use compare execution speeds.

Hmm. I suspect that turning off unused radios and stop/idling unused related cores might make a huge difference in all of this.

Why you did not include the esp8266 its still popular and it can run @160MHz

add the teensy boards at a few speeds?

Ever look at the STM32G and STM32H serieschips?

8:00 Hearing “megahert” makes me hurt. :p

I think power draw also depends on the process nodes of mcu, rpi2040 is built on 28nm while tensilica lx6 is probably above 32nm or 40nm

So you tested 4 different ARM generations and just one ESP32? Where is ESP32S3? How about the RISCV ESP32C3? Waiting for the video to finish to see if you make any comments on the ARM prices and availability :)

With the graph at 9:00 you’re basically comparing number of clock cycles, no?

Quick aside, Gary: Can you use something other than a red dot as your pointer? My cat won’t stop pawing at my display. 😂

No atmega328 in test. Even for fun. Rest in peace 😭

The Pico kinda baffles me. Especially compared to the other M0+ based cores. Usually the M0+ core does not include a floating point unit, hence finding prime numbers by division should be overall very poor. The Raspberry Pi Foundation must have implemented some sort of FPU extention to the M0+ core.

I appreciate the amount of work Gary puts into a video like this, and running all the tests but, sadly, this is a really terrible benchmark for most people. Finding prime numbers by Trial by Division is unrepresentative of most programs because it is built around -- obviously -- division, while most programs use division very very rarely. So rarely that many CPUs, such as the Cortex M0+, don't even bother to have a division instruction, instead using a software subroutine that probably takes up to around 100 clock cycles in the worst case. Other CPUs have a hardware division instruction, but some of these take 32 clock cycles (for division of 32 bit numbers) while others take 8 or even 4 cycles. Sometimes CPU cores with the same model name can be licensed from the supplier with a choice of fast (but big) or slow (but small) divide units. Cortex M3/M4 take 2-12 cycles for a divide depending on how many significant bits the result has. M7 seems to be 3-19 cycles. And then there is the Pi Pico, which has an M0+ that (like the other M0+ boards) doesn't have a divide instruction in the CPU. BUT, the Pico's SIO peripheral has a memory-mapped division unit. Rather than an instruction in the CPU, you write the dividend to one memory location, then the divisor to another memory location, and then 8 clock cycles later you can read the quotient and the remainder from two more memory locations. If you use a generic Cortex M0+ compiler then it might not know about this, but a specialised Pico compiler will know how to use the SIO divide. Or maybe it's just a custom __aeabi_idiv / __aeabi_uidiv function in the runtime library. I hope it's inlined. It is also very unfortunate that Gary has not published the source code he used so people can try it on other things, and also check that no mistakes have slipped in. If people are interested in a primes benchmark that IS representative of average programs -- because it doesn't use division -- they might want to look at hoult.org/primes.txt which I have tried on many machines including M3/M4/M7 and ESP32 as well as various RISC-V and x86 and Pi-like ARM boards. I don't have an M0+ result but I'd welcome one (or others)