EEVblog 1539 - NEW PROJECT Part 3 - STM32L vs PIC24F

[EEVblog]

Which microcontroler is better for the new project, the ST ARM STM32L or the Microchip PIC24F. Datasheet power consumption comparisons. All may not be as it appears...

[hans]

STM32CubeMX also has power estimation tools. Many mfgrs do. You can put in clock, memory and activated peripherals to get an estimate of current draw. Some tools even allow simple profiles with run/idle/stop/sleep/wakeup transitions along with battery capacity/life models.

For the STM32L series; the MSI oscillator is IMO where it's at. I've most experience with the STM32L4 devices with them. It's a reconfigurable RC oscillator from 100kHz up to 4 or 8MHz IIRC. Current scales accordingly, which is unique, as a frequency divider is a waste of current. When all ""static"" currents on the chip scale with frequency, there is no need to "race to sleep" and in theory less of a need to support DMA operations in e.g. sleep or standby mode (which is a killer feature of the MSP430 series). The STM32U5 series (and many others, e.g. SiLabs) now also has DMA operations when oscillators are stopped though IIRC, but that's a very high-end part.

Anyhow, point I wanted to make with regarding the discrepancy in banner spec vs datasheet: 1) This chip has a "LP run" mode that is limited to the (lower) MSI speed settings. This may have a lower uA/MHz.
2) The uA/MHz spec for 1MHz on a HSI/PLL oscillator will always be worse than e.g. at 2MHz, since the HSI and PLLs have their quiescent currents which hardly change. When those currents dominate , race to sleep can be more efficient.
3) Current consumption is not always apple-to-apples. E.g. one datasheet may measure with a while(1) program, while another is running a dhrystone/coremark benchmark. Only very rarely you will see a mfgr listing several program test cases, at least for 1 frequency, and showing how the core current can vary. I think SiLabs is one of the few to actually do this.
4) Although not the case for this MCU, but I think many/all MCU mfgrs do this if they can: if a part has an on-chip DC/DC (constant power regulation) instead of a LDO (constant current) voltage regulator for Vcore , they will still happily put the uA/MHz figure up there, while it should be uW/MHz. The figure is typically measured at Vin(max) so the current they boast is as low as possible.

There are lots of shenanigans to low power design, unfortunately..  Having said all of this, I still don't know how they get to 88uA/MHz. Frankly I've always ignored the STM32L0 series when it comes to ultra low power designs, because unless you can utilize some neat peripheral feature (like LCD) or lower pricing, I don't see its strength vs a STM32L4 part. The L4 series sips just as much current (or less), has a more flexible MSI, and the Cortex-m4 core will complete the work faster than a m0 core.

[cortex_m0]

The 88uA/MHz is taken at 4MHz, in Table 29, running a pointless while (1) loop.

I'm guessing the Fibbonacci algorithm uses more power because the chip is capable of clock gating parts of the ALU.

[SiliconWizard]

I second what hans said, I prefer the L4 (as I suggested before). Also, the L0 has pretty limited RAM - maybe it's fine for your project though. The L4 certainly has a lot more. But, if cost is a concern, then it's another story. Then again the PIC24F is not that cheap either.

Of course whatever will draw less current in practice entirely depends on your exact use case. If it spends most of its time in a low-power mode, as I would suspect for a power supply thing, then what will matter is the current in stop mode (for the STM32). But also have a look at how much time it takes for the MCU to wake up and be operational from the lowest power mode that you'll want to use and the active state.

But as to the performance/power ratio, the STM32L, even the L0, will beat the PIC24F hands down, which would matter only if your device will spend a significant fraction of the time in active mode, which may not be the case.

A relatively industry-standard benchmarking for this is the EEMBC ULPmark. https://www.eembc.org/ulpmark/ulp-cp/scores.php
You may see stuff you were not expecting on there.

Benefit of the PIC24 is that it's simpler, the docs are clear and it can be used fully bare metal without any library. While the same can be done with a STM32, you probably don't want to do this, so you'll be stuck with the HAL. Not that it's as bad as some say though. But certainly something to consider - it's not very well documented. Conversely, Microchip tools are uh, what they are, with somewhat questionable licensing, while the STM32 can be used with just GCC if you want to stick with fully standard tools, and the HAL is provided in full source code form.

If you don't have experience with either, are still unsure which to pick, and want to get a better idea also about power consumption in real use cases, I'd suggest buying dev kits for each and evaluating them before picking one. Nothing beats actually trying before committing.

[Kleinstein]

Having the LCD blinking feature may simplify the programming, but in most cases it is not a big deal to have a interrupts for doing the LCD blinking. The frequency is usually relatively low and thus very little processing power needed - could still add latency to other jobs.

Chances are the ARM core can do more processing with the same clock. So as already writtlen it is not so much µA/MHz but µA/MIPS.  It still depends and in some cases the pheriphery can do quite some jobs and reduce the processing needs.  More efficient processing (or a better optimizing compiler) can make a difference if one considers running the whole µC with the 32 kHz of the real time clock.

Price wise the PIC24 seems to be quite a bit cheaper. The availabily of the STM32L053 was bad (I had the problem with a PCB designed for exactly the L053 and not able to get one some 2 years ago and had to settle for the L051 instead - for me missing the DAC). Currently the supply situation is not that bad and the L053 is also available at Mouser and Digiky (with a mix of memory size). As a last resort there would be also STM32L073 as a upgraded (usually pin compatible) version, though a bit more expensive.

[hans]

To be honest - the PIC24 low power features are still pretty competitive. It may lose out on the uA/MHz banner spec (especially the older devices in the family with the same XLP branding), but unless you plan to run the MCU for long periods, it won't be a problem.

E.g. for  project I used a STM32L011 as a soil humidity sensor. It can be woken as I2C slave to start measuring, which takes a few ms, and be read out. All it needs is PWM at 4-8MHz and an ADC. I don't think the peripherals of the STM32L0 are that much more complex than the PIC24 to program, but probably also don't have anything else to offer.
The current draw in "stop" mode is about 0.4uA. Current draw while measuring is about 5mA for ~10ms. If the sensor is read once per 5 minutes, then that's a duty cycle of 0.0033% (33ppm). The average current draw is then 0.56uA, a ratio of 2:1 sleep/run ...
An (older) PIC24 may (or may not) consume double current during measurements, but the computational complexity is nearly zero, so it's duty cycle would be the same. The sleep current is comparable. So it may do the job with 0.73uA instead. Oh no!
It's higher, but it's also good enough. Still I got the STM32 because it was 1EUR each back then.

In an academic project I used the STM32L431. This design doesn't have a battery. The comment regarding the L4 doing more work in less cycles is then quite important, as it's running a software defined radio algorithm at several kbaud using 0.1-1MHz CPU clock.  It's an especially nice chip since I could accelerate some signal processing operations with it's SIMD instruction set. And it has tons of RAM to even run the code from SRAM and utilize some of that academic polish to publish slightly lower figures than is realistically possible (the infamous PhD-ware).

But for a clock project, that's far beyond any reasonable consideration. Honestly I don't see any problem with the PIC24. Especially if they are consistently available. STM32 has a fairly poor track record due to its own success.

[oliv3r]

Personally, I avoid PIC's like the plague, due to toolchain support.

Having to deal with the propriatery compiler is a pain (especially in CI), needing licenses etc for it is just troublesome. The world has (is busy) moving on from proprietary compilers.

I think even dave even mentioned at some point, 'why are these hardware manufacturers trying to do tooling, it costs a lot of money, and it's not likely its a money maker' (or something along those lines, but dave can quote himself better

And yes, sure 'it just works' (for the most time) but as an open source aficionado, and the quite decent quality of toolchains, lets move on.

[EEVblog]

Personally, I avoid PIC's like the plague, due to toolchain support.
Having to deal with the propriatery compiler is a pain (especially in CI), needing licenses etc for it is just troublesome. The world has (is busy) moving on from proprietary compilers.
I think even dave even mentioned at some point, 'why are these hardware manufacturers trying to do tooling, it costs a lot of money, and it's not likely its a money maker' (or something along those lines, but dave can quote himself better
And yes, sure 'it just works' (for the most time) but as an open source aficionado, and the quite decent quality of toolchains, lets move on.

See my recent video with Steve Sanghi for the reasons.

[oliv3r]

Personally, I avoid PIC's like the plague, due to toolchain support.
Having to deal with the propriatery compiler is a pain (especially in CI), needing licenses etc for it is just troublesome. The world has (is busy) moving on from proprietary compilers.
I think even dave even mentioned at some point, 'why are these hardware manufacturers trying to do tooling, it costs a lot of money, and it's not likely its a money maker' (or something along those lines, but dave can quote himself better
And yes, sure 'it just works' (for the most time) but as an open source aficionado, and the quite decent quality of toolchains, lets move on.

See my recent video with Steve Sanghi for the reasons.

I heard it

So I totally understand (from a business point of view) that you treat it as a product, so it can make some money, so you don't shut it down. This is a solid reason when talking about proprietary stuff. I'd even argue, 'proprietary vs gratis' this makes a lot of sense, as someone's gotta pay for the work.

Sadly, you used the words 'free' instead of opensource, though I doubt he'd understand what that is about :p

The whole story about decisions selling their toolchain team is of course silly. It's part of your product, one can't do without the other. But contributing support for your chips to an open source toolchain, in the end, can only be a net positive. It's just 'old-skool thinking' (that aligns perfectly with the thinking of selling your toolchain devision).

But such is it often with hardware vendors, software is just a small part of the equation right? Tooling, testing etc; just write a bit of software.

I think even the automotive world is slowly leaning towards more open source (android automotive, BMW doing more open source). In the long term, opensource will become even more prominent, and dinosours will eventually wane

Also, as the next generations of engineers come to be in these new companies, that grow up with opensource toolchains, CI etc etc they use in their 'hobby' projects or small companies, they'll will demand to use this in their big jobs as well (when there's opportunities, things as always still move slowly sadly).

I've had to use the optimized compiler, in a small company. Just because the software grew, and it was the only way to make it fit. For us, this was a huge cost issue. But more annoyingly, integrating it into the CI was also very painful.

But look at atmel/avr. The company was probably not run great, but their compiler just kept on going no need to grab some ancient compiler. But granted, them asking money for it, means they can hire people to work on their compiler and keep improving on it. Oth, if they main focus is to add support for their hardware to gcc for example, that's work that needs to be done anyway. And in the 'fat years' you can contribute to generic/optimization features of gcc. In the thin years, you do the bear minimum to support your chips. And time-lines is a non-excuse. You have to do the work regardless. But again, ranting now, and only heard a dinosaur :p

Anyway, for me personally, and business, I will avoid anything without an FOSS toolchain like a plague.

And of course, hardware guys (trying) to do software, are fine with whatever clicky interface they can get and do their one-off. Software guys tend to have to work on the same stuff for decades sometimes :p

BUT, it was a really good interview, well done Dave.