I've been at Atmel boy for about 20 years and in the last 4 or 5 years have moved over to STM32 almost purely for the inbuilt DFU over USB (not all STM32 have it, but many do). It's great not to have to worry about a bootloader and having inbuilt USB means it's super easy for customers to do firmware updates in the field.
For very low- power applications, the dominant factors are usually sleep mode draw, draw of whatever timer you use to periodically wake, and also how long it takes to start from sleep mode. The latter can overwhelm all other factors if using a crystal or resonator, due to the time to start the oscillator. That''s where having a part which has an RC oscillator that's accurate enough to not need a crystal can make a huge difference.
Yep. I did a worst case 24/7 operation calculation in this case to show that power consumption wasn't a huge deal in this application, so no need to go deeper and consider the various sleep modes.
Intersting, i always wondered if "wakeup" overhead would negate any power savings going into sleep mode, especially if youre doing it very often, even asked chatgtp about it and it didnt mention startup time of the crystal . Great explanation.
I was very surprised to hear at the end that these sorts of design videos don't perform well - personally I find a lot of value in project based learning and especially the design choices they often have to begin with
@@EEVblog Well, I enjoy videos like this, because it is a rabbit hole I don't want to go down myself. A whole "Micro Shootout" series where you pick a few (3) MCUs with similar features from different manufacturers, build up circuits and pit them against reach other in the EEV octagon would make for fine viewing. Yeah, I must be weird.
@@EEVblog It depends what "doing well" means. It is getting several tens of thousands of views for a pretty niche topic, so it is probably doing very well with the audience, only the size of that base audience is just smaller. If "doing well" means "pays the rent" I see what you mean and that's understandable.
Thanks Dave, that was topical for me and interesting, keep doing these type of blogs. I recently did a similar comparison myself but being short of time used the PIC24FJxxxGA for one project and am using the STM32L4xx for the current one to compare. I had also noticed the apparent uA/MHz advantage of the STM32L in the datasheet 1st page but as you rightly point out in a battery powered use case with most time in sleep/standby its the battery self discharge and circuit sleep current that matter more, and the devil is in the detail regardless. The PIC also has far greater pin MUX flexibility as over half the GPIOs can route an input or output digital peripheral signal (RPs or RPIs) which I found greatly simplifies your routing e.g. order of fast SPI signals going to/from an external IC can be ordered by the PIC to match the slave SPI IC pinout (thus avoiding vias and removing location constraints and maintain controlled trace impedances easily) but on STM32 for any digital peripheral you are constrained to use a fixed pin arrangement out of only 2-3 preset options - I have found that immensely frustrating about STM32. Extending that, on some STM32L4 they have cool sigma-delta digital sinc filter modules but Murphy's Law says the output clock is always constrained to be on the wrong side of the data stream pin so you have to effect a cross-over in your layout and you can only output one clock from only 1 or 2 pin options which means that if you have bit streams coming in from all angles to thus avoid a bird's nest of a layout an external 1:n clock buffer is required and is still hard to layout, whereas if I was improvising in PIC (they don't have that peripheral) you could pump out a clock almost anywhere and do multiple clock copies from any side of the MCU. I have however found the STMCubeIDE eclipse based IDE with its GUI based configurator and code generation much better than MPLAB X and although in PIC I usually configure the initialisation of peripherals via a laborious bottom up bit by bit procedure using a template, the CubeIDE GUI makes it happen in a snap and error free, and full optimisation is free of charge, so in that way STM have really raised the bar. I concur with your conclusion - its swings and roundabouts and generally they are substitutable but which one is better comes down to the requirements of the specific project. One last observation, STM now have the M33's and claim even 4x less uA/MHz than the L0's - but with performance better than even a Cortex-M4F - have a look at e.g. STM32U575xx claiming 19.5uA/MHz!
I would LOVE to see you go through the process of building the dev boards for testing the ultra-low power consumption -- the educational value here would be amazing even if in practice for this application it doesn't matter too much.
I love design videos like this. I like the STMs, never used PIC (I was an AVR fanboy). But at the end of the day, it's more important that you actually pick something rather than letting the entire project drown in finding and selecting that one perfect micro. Which is now out of stock because it took you so long to find it...
The thing I love about STM32's is that a LOT of the parts are pin compatible. So you can pretty painlessly go up and down in performance or across families, depending on your needs. Makes EOL updates just a smidge less painful. CubeMX has gotten a lot better over time too. Use what you like.
That was the main thing when i worked on my master's thesis. I did all my work on F3 series, and downsized the project for te F0 series... all worked like a charm with minimal adjustments.
As someone working in industry doing this kind of stuff, yes this is very much part of the process, and very easy to get stuck in rabbit holes on it. Although the chip storage that's made it a bit easier since there is so much less to pick from lol
that thing about sticking with what you already have is hard to overstate. It's knowing the toolset, being set up to manage the workflow, having libraries, you name it. There's often hundreds of hours involved in recreating that with a differend micro.
100% correct. The quality of the libraries and tools is my #1 factor in choosing micros and that is where ST still rules supreme. Everything else I have tried has too much abstraction, a quirky release schedule or something else. (hints for MCUs with good libraries welcome)
@@fxois3318 I am working on a project with a LPC5536 at the moment. Where I thing is falls behind from my point if view is that a lot of parameters that could be enums are just integer (personal preference and company guidelines) and you don‘t have the level of control of the ST LL lib. On the other hand, there is no function to get the transmission complete flag of the UART for example (only for the FIFO registers but that doesn‘t help when you have half duplex communication on one line). I also don‘t like that you have to use the online generator to build a library. A simple zip file is still what I prefer.
Can you get the chips? - that's all the matters. And STM is still the most "unobtanium" Also if you don't have a 32-bit timer just have a 16-bit timer do an ISR rollover that ticks a variable.
Not sure if the timer needs to run during operation or during sleep. If the latter, then another rabbit hole opens up - what timers can wake up the cpu. Or if they are internally chained, if that mode still works under (selective) sleep mode. Sadly, not enough requirements are given.
Pitfalls of datasheets are always really handy, Dave. When you're a high level hobbyist and working from prebuilt boards like an Arduino Uno or Rasberry Pi, you don't tend to need the detail, but as soon as you think, "Hey, I'll go build my own variant to do specifically this thing!" the datasheet and supporting docs become crucial to pulling off a decent design, particularly when battery life and other hard to measure stats are important.
...and don't forget the errata--ignore them at your own peril. I recall a PIC32MX design that looked to be the cat's whiskers, until an errata sheet rolled around that said "Uh no, that doesn't work--yet".
yeah, got to be cautious of datasheet sleep currents. They often quote the sleep current with everything turned off and in a state that no one will ever use it in. Oh you wanted to run the watchdog? extra 0.3uA, You want brownout, extra 0.4uA, You want to keep the 32khz crystal active +1uA , You want to keep the UART active and wake from sleep on RX +10uA etc...
I'm pretty new to the whole embedded programming world, so when I started making my own custom boards with an MCU, I started on STM because it's basically the only ecosystem of MCU's with semi-existent resources online. I wouldn't even know where to start with a different flavor of MCU, and I'm not sure how mature the hardware abstraction libraries are for other chips. Since it's where many people start now, and it requires a pretty considerable effort to learn any MCU ecosystem, i can see why so many people end up as STM32 die-hards. It's where they started and what they spent time learning.
I started out with 8 bit CPUs , then after a long break picked up with Arduino and Atmel, which was unfortunately bought by an overseas competitor while the Arduino team was destroyed by internal strife.
Your selection technique is awesome. For new designers starting out, picking a couple of good uC candidates and doing a quick trip through the data sheets is a very good start. Rather than do a deep dive on the data sheets; I would prefer designing the circuit and making a PCB for each processor. I like getting the power consumption figures from actual hardware. I find the PIC24's (and 33's) very easy to program. Haven't spent as much time on the STM's.
@@JairoGustavo Good question. An EVK targets the u Controller itself. When you do a layout of your actual design, you are not only evaluating the chip in its intended application, but you are (ideally) further down the development path in creating your product. An additional benefit is that you have one or more options if chip shortages become a problem.
Good spot. Not that silly though as many applications might have while(1) foreground and everything else on interrupts or spend 99% of the time spin-waiting.
@@chrismorley5393 I meant - it is silly quoting it on product page as baseline uA/MHz figure. Sure it can be provided as additional data to better gauge code perf. But to quote it as official uA/MHz is plain misleading.
Most of those low power modes look like they are specmanship, operating with the device in modes where they are basically doing nothing, with all peripherals totally disabled, and with barely any ability to operate the chip to do something useful. Also beware of the "typical", because you can be pretty sure that the low power modes were cherry picked devices, run at "room temperature" in a walk in freezer.
I made an alarm product using a PIC24F micro - it was a battery powered radio alarm made in the thousands. It used to go to sleep for almost all the time and then wake up every 2s for a few ms to listen for radio messages. Average current was a few uA. All worked nicely, but there was a problem with the PIC - when the USB subsystem was enabled (we used USB for configuring the device), you could never completely turn that part of the core off again, and it ended up using a few uA more - the PIC had to reboot to turn it off completely. This was undesirable because it took a few minutes to join the radio network.
The trick is absolutely to narrow it down to a manageable number of candidates then order them and run ur own tests. Doesn't necessarily mean building out full prototypes, but at least building up the circuit and then playing with the key variables for yourself. With parts this complex you will never be able to select the optimum component based solely on the datasheets.
I finally joined your Patreon because of this video. I'm a long time fan, and this type of video is what I'm here for. It's a sad reality that these videos don't pull many views, but they're the most valuable and interesting to me. 👍 Keep them coming! I'm excited to see more of this project.
For my personal "one of" projects I generally power from a usb adapter/wall wart. Usually a esp32. I'm not overly concerned if there is a bit of wasted heat as quite often the house needs to be heated regardless. Not in to just wasting the energy, but I don't need to worry to much. Still interesting to learn about the power consumption. Thanks Dave!
STM32L053 88 Mhz/uA comes probably from table 29: 353uA/4MHz = 88,25. In other STM32L412KB datasheet for similar tables 31, 33 power consumption is calculated to uA/MHz and it match values from first page of datasheet and info on mcu webpage. Also for STM32L412KB consumption is also presented in table table 4, that have no equivalent in STM32L053
About 88uA/Mhz: On page 63, code running from RAM, VCORE @ 1.2V, at 4MHz while (1) loop consumes 340uA. Divide it to 4 to have uA/MHz value which is 85uA, even less than what is claimed.. Also fibonacci calculations take 370uA at 4MHz, resulting to 92uA/MHz.. Not bad.. You were confused when you read "running from flash".. ARM can run code from FLASH and RAM. Running from RAM most of the time is faster with less power consumption.. You may move code that run repeatedly into RAM to save power consumption.. Code that reads the sensors, updates the LCD are the candidates..
I haven't watched your videos in a while. The reason for this is that I did not consider them educational enough. Now that I saw that it was about a new product, design, choice of microcontroller, I clicked immediately as if something had stung me. This is what we need, this is why we are engineers and follow this channel! Let's see ideas, ways of thinking and learn from experienced people. If all videos were of this type, I would watch them every day!
This is a well timed video. I'm currently in my Masters while working and our class project is to design a low-power sensor system that can last long in the field based on our specs. This is awesome and I plan on sharing it with my class. Excellent coverage of all that is being looked at so far in our class.
I neither know not understand much of what you mention, but I like the way you present such topics, because every freaking time I learn a thing or two, no matter whether I wanted to or not, lol. ;D
I've been using PIC since the very early 16F series first came out way back in the early 1990s. After 20+ years, I found them less attractive when Microchip released Harmony with it's 4000+ page reference manual. Other devices have much easier configuration tools and libraries and to be honest, for me, the development tools are the prime concern
I've always found ST datasheets to be pretty sparse compared to Microchip's - which for me is a big ugh factor. Having to find a which register to enable a particular mode should be trivial, unless the manufacturer has failed to update their datasheet....
Main reason I never consider PIC is because Microchip are still charging money for the tools! AVR and pretty much any ARM chip have GCC, which is 100% free.
In fact, there is no ideal MCU for all applications. I had used AT89, AT90 (first AVRs), ATMega, ATXMega, AT91SAM7, H8, H8S, R8C, SH2, MSP430, STM32, LPC200 and few others and everywhere was some troubles to use it. But what I learned is - don't believe to marketing papers. If they offer low power consumption let's take calculator, scope and multimeter. When ATXMega devices started I did a project that should run 30 days from CR2032. 1.3uA in deep sleep looks, wake up each two seconds to get the ADC data and store them, fall down to idle... It looks great in ATXMega64D3 whitepapers so HW guys uses that and put final board to me to program it. What was real? 1. Reset current was 1.3mA. There was no way to start with older battery as its internal resistance didn't allow to increase voltage above BOR level and it kills the battery.. 2. Real consumption was 64uA instead of calculated 3,5uA in this configuration as somebody from Atmel forgot to write that wakeup took 640ms 3. Tech support of Atmel didn't believe it until I sent them demo code, configuration of lock bits and images from the cope. After two months they apologize me they didn't test this setup. Material dor 20k units was alreaady ordered... 4. Four another undocumented HW issues made the firmware design one month longer Lessons learned: From all the numbers in Atmel's AT64DB3 datasheet only package dimensions were OK If there is a critical parameter I want to have a week to check each of it it before start the desing since this project.
20:14 In fact, regarding the supply crisis. I actually managed to order free samples of a few different Microchip parts in the midst of worst part of the chip shortage. Microchip delivered! I thought for sure they'd cancel the order. I enjoy working with either STM32 or PIC, but I must admit, I have a soft spot for PIC's -- it's the platform I originally learned embedded programming on.
I'm essentially pure software, with just a little bit of homebrew device making for home automation, but it's really heartening to see that it's not just software people who like to say others are doing things wrong when they don't know the full list of soft and hard factors that made a decision happen. Of course, sometimes people are just not thinking - with modern toolchains all you need to do to switch to a new micro is to change the tools in your cmake and move some addresses about for your IO. Lots of people seem to know one architecture and decide everything else is a massive headache, even if that means using a £3 controller with long leadtimes when there's a £.90 available.
I'm sure you noticed this, but I believe the J parts are one-time programmable. Be aware. Also, be sure to check the errata for the Microchip part that you are thinking about. Sometimes some peripherals just don't work.
ST lost my business many years ago, repeatedly. I was doing system design and picked out a part that looked like it would do what I wanted. I just had some questions, and it being the depths of the recession, the apps engineers & reps were very keen for new business and were happy to meet with us (which in busy times, they're harder to get ahold of). I had the ST apps engineer look me directly in the eyes and lie to my face about the capabilities of the processor I was looking at. Later on another contract, I was doing some interface work with the software engineer and an FPGA, and that software engineer could do nothing but complain about ST and their software ecosystem, and again, shock and amazement, the ST part woefully underperformed. Its a pity their support suck(ed/s), they lost me as a customer at that point, along with that entire company. Not that I'm a super fanboy of Microchip**, had I done as a Microchip employee what that apps engineer did, my boss would have had no problems burying me out back in new parking lot construction. Sad that I have to design them out of my design ecosystem completely, but I can get what I need elsewhere. All that said, plenty of vendors though do stupid things to lose customers. Lattice likes to EOL their chips super fast, ST lies, Microchip I hope you like errata sheets and some weeeird designs, TI good luck finding anything modern with availability (or these days, older), etc etc. **Disclaimer I have been [past tense] a Microchip employee, not a PIC fan, but I use their AVR+M0/M4 stuff among other vendor's MCU's for my applications these days. TI, Lattice, Microchip round out the bulk of the MCU's in my inventory.
I hear you... ST has shitty datasheets and underperfom, Microchip has good documentarion ma its chip are full of surprises... I prefer freescale/nxp if possible, but they are expensive.
@@VndNvwYvvSvv 14 years on (this was ~2009) it probably isn't relevant anymore, and I have no recollection of what part it was. It was a specification on the NAND flash controller, and it was basically implemented in software and not in hardware as promised, after the software team broke the news to me.
@@MartinDoesStupidThings same here, chips for distance sensing was almost all firmware library with their undocumented firmware and undocumented registers with a datasheet like "use the library". Never again.
@@AppliedCryogenics - there were 3rd part compilers for PICs before Microchip really got on board with rolling their own. Back then a lot of projects could just be written in assembler as well which was "free" in the MPLab SDK. I still have my PCB,PCM,PCW PIC C compiler software (circa 1999) from Custom computer services, both disk and manual, on my shelf. Cheers,
Very interesting discussion. The RISC processor is optimized for instruction throughput (MIPS) per unit area of Silicon. Optimizing for power is an entirely different issue because it would require Voltage/Frequency scaling including switching ON/OFF. You identified the energy sources an Alkaline cell, there is little to improve there. The dominant power consumption isn't as clear, could be MCU, IO devices or LCD display plus duty cycle/sleep. Thank you for the discussion.
There are maybe a couple of valid reasons to think of to go for 8bit if you need 32bit hardware(like timers), but I would advise it. A 32bit that uses more per Mhz can still be more efficient than an 8bit that uses half of it. If the 32bit(one clock to move 32bit data around and higher IPS) is 10% run mode and 90% in sleep mode and 8bit(4 clocks to move 32bit data around) is 40% in run mode and only 60% in sleep mode then the 32bit will be use less energy.
The STM32 series parts are pretty nice for most general purpose applications if you need the grunt, but I have found that many of the peripherals can have a lot of frustrating gotchyas for things like USB, serial audio protocol and spi transfer sizes, weird DMA buffering workarounds, etc. At the end of the day I tend to select an MCU almost soley based on the peripherals, power consumption, OFF THE SHELF STOCK FROM MULTIPLE DISTRIBUTORS, and available development hardware.
I've used numerous PIC chips for smaller projects and the MSP430 series for more complex projects. I haven't tried any of the STM chips yet. For the PIC chips, I don't think I've ever bothered moving any code to ram though it certainly wouldn't be difficult to put small core assembly loops there if the project is such that the cpu spends most of its time spinning. We almost never use sleep modes on the PIC chips beyond implementing the "off" button... the restart latency is too high. So idling in ram isn't a bad idea.
I'm voting for Microchip PIC. The Positron PIC Basic Compiler is a good compiler and allows you to define many functions and macro. The Compiler's Programmer, Les Johnson, is constantly updating the Compiler and you can ask him directly about the problem you are having. The compiler's float math operations are fast and accurate. For a single fee, the compiler 16,18,24 and dspic series are available to you. This is a great advantage. Also, Less can help you with your questions on the forum page, as he reads the datasheet of all microprocessors step by step.
ปีที่แล้ว +2
STM32L is fine for a bunch of uses, even having a bit larger chips... amazing stuff that worked on multiple projects so far. But if Arm is making changes to its licensing moving arm tax to the end product and not the chip provider. It makes sense slowly move all new products away from arm altogether. But low power matters, if the battery is hard to replace and the product needs to last for many years.
I do hope you continue to do these design videos, I always learn so much! Sux that the algorithm ends up punishing you for these, they are really good sources of info!
For the STM32L0 series is 0.95 DMIPS per MHz. This means if you want to compare MIPS of the PIC vs STM32. You need to compare at approximately 0.5MHz. On the datasheet (page 63) you can run from the MSI clock for Typical 83uA. Therefore PIC = 210 uA at 0.5MIPS, vs STM32 83uA at 0.5MIPS. I couldn't find the headline figure of 88uA/MHz, and on page 18 it even explicitly says for running from RAM 140uA/MHz. The only thing I can think of is that the power figures on the STM32 datasheet are for 125C, which the headline figure might be for 25C.
We had a product designed around an NXP part, had a huge order for it right at the start of 2021 and we had to redesign it for an ST part that was in stock at the time and we just got all the once we needed. Spend like a month redesigning the board 5 months re-writing the code ... that was some crazy time.
@@denizcancgsar2810 There were 3 main reasons. 1. The programmer who wrote the original code used the NXP HAL, without making an "intermediate" layer, so switching the HAL was not as quick as I would have liked. For our projects making a HAL from scratch is out of the question. We CAN write that code, but we juggle many peripherals and on tight deadlines. The HALs from the manufacturers speed it up. 2. Also we changed one other main IC, because we couldn't get the original one. That required a significant rewrite. 3. We had a new embedded developer colleague and management gave the job to him. Great C programmer, but it was his first time working embedded and it took him a while to get the hang of it. I'd have done it a bit sooner ... maybe.
@@Nik930714 The HAL's from manufacturers have always been garbage.. Somehow hardware developers are the worst in the programming area.. Spending time on their HAL consumes more time than rewriting the whole suit.. Only area I keep myself rewriting is the Bluetooth LE stack not because it is complicated but because of the certification process.. But spending 4 months on race conditions, such as indication stopping working with Xiaomi devices, not properly negotiating with Realtek chips made me think that I wish I have written the whole BLE stack as well.. Design a framework such as UART would be like this, I2C would be like this, and the HAL would be very small part of your problem.. That way same code runs on MSP430 as well as on NXP and ST's.. That's what I've been doing..
@@denizcancgsar2810 Oh yes, manufacturer HALs used to be pretty bad. About 5 years ago i re-wrote the UART and I2C stacks for STM32, because they had huge problems. They barely worked. Now days they are quite good, I've not had problems with them for years. Same goes for NXP - they had problems, but are pretty much resolved by now. I've not used any MCUs for almost 10 years now, so I really cant comment on their HALs, but the ST and NXP once are solid now. Also the graphical tools for setting up the peripherals save so much time. Especially for the more complex stuff like clocking or SDIO or whatever.
@@Nik930714 I can not say the same. Visual IO mapping is nice but the rest.. For instance UART design of both of them have major issues. First of all they have lot's of code in IRQ's. Nearly all code runs in interrupts which creates latency hell. Last time I helped for a code that runs on ST, STCube was not using FIFO but only receiving given amount of data which was ridiculous even 30 years a go etc.. I plan releasing my multiplatform framework soon.. That is one may run its code on Nxp, ST, MSP430 or even on Nuvoton's ARM MCU's.. Designing "write once run everywhere" has been torture for a time. It is very difficult finding a common base for the same module etc.. That postponed my plans a lot.. A question: For you, if you were to use the framework, will it be a problem using C++ instead of C? I wrote it all in C++ taking care of the C++'s "invisible traps"..
I looked up the L0x3 parts after that video and saw they can't compete on price and availability at the moment, not sure what NXP or other cortex M0's have to offer in that segment. For personal projects I like the STMs but for professional projects you have to be agnostic, even if I don't like working with Microchip's tooling (maybe it got better it's been a while since I worked with them) Good compiler support is important too though, for more complex software where you need modularity and abstractions it's a huge leap from C++03 to a modern standard in terms of code size, efficiency and reliability.
They also can't compete on basic functionality. I think I used 32L073 specifically for LCD control. Then with the official STM32 IDE I made basic LCD test, everything according to the datasheet. Well the debugging shows the CPU crashes right after enabling the LCD with 4 common multiplexing. Further research shown that static mode works (can't really use that) but anything beyond that doesn't. Posted about it on STM forums, no reply. I ordered other pin compatible parts, tried again without success, the other MCU didn't even connect to the ST-link even when I checked and the second boot pin should be wired fine for programming. So that's the end of my STM32 development.
The thing about "can you source the part", goes beyond a single chip. We have been in wait list to get a server, because not available CPU, or SSD, or what not. Some times you can get around with a similar part, other times you just can't; and if you are going into a new design with readily available part you also need to worry about it... oh my. A new vector in the design phase to consider.
I like the design video's a lot. There aren't that many video's around that actually explain what there doing. Or it is a video about e.g. a power supply built but then it just involves some aliexpress stuff wacked in a box and just wire it up. I've watches the uSupply series and likes that too. For this video, I'm not that concerned about mcu a or b, but still interesting that you mentioned you would build the actual circuit up to test. So many conditions, to me that's just insane. When designing I really get lost in datasheets in general, really hard to read. Also explaining something and than take it to the breadboard is interesting. Especially what the pitfalls are. Or what makes an op amp oscillate and how to fix that. I liked the fundamental stuff a lot too. Guess I like everything that isn't popular on the channel haha.
"execute code from flash - isn't that a given?" - you could also execute from RAM, e.g. for speed purposes, or if there is only one flash bank, you cannot at the same time program the flash and also process further instructions & be responsive e.g. during a firmware update.
Guess part of the problem is that these videos are harder to digest /can't be watched anytime as light hearted ones. I don't watch them as willy nilly as your other stuff, but when I'm in the right mood, if I think about it, these types of videos are the most interesting and most engaging ones on your channel.
We used to have the same crap to deal with when comparing battery data sheets. The specs from different manufacturers were done at slightly different conditions , so never side by side comparable. Test was always the best way. Duracell were the worst back then....so much useful data was left off
As someone who has only ever designed and built one project (a esp8266 based temperature / humidity and motion sensor to link to home assistant) I don't rearly understand everything that goes into the design of a product so find the design videos fascinating
lol. looks at uA/MHz and ignores instructions per MHz AND code density. ARM is more than twice as fast at the same clock speed (MIPS vs MHz) AND ARM instructions do ~ 25% more work than MIPS instructions on average.
It is tempting to concentrate on the microcontroller hardware specification, however, for projects that involve a small production runs. It maybe the cost and availability of the development tools that are the limiting factor determining the choice of microcontroller. For amateur Projects, and those involving a limited number of builds, such as prototypes, one off test equipment, etc, the major project cost is likely to be the purchase of the compiler and the development toolset. This is why the Arduino is so popular, its toolset is free. Even for projects with larger production runs, the choice of software development tools maybe a critical factor. Worth asking how much for a C compiler, debugger, with IDE for the device you want to use. What are the software limitations? How much for single seat commercial licence, and how long does it last?
Historically its always been NXP that was winning over ST Micro parts for the companies I worked for. But then I have not been part of a decision process there since around 2014 so, who knows, maybe ST micros are better now. NXP parts were pretty pricey tho. Good video on the difficulty in defining actual real world power consumption in your choice of MCU. Getting below 100 uA the choice in such things as what mode to leave GPIOs in start to play a big part in sleep mode currents, even asking if external parts should be powered down or not.. a powered off component will turn into a resistor and can pull current from MCU pins. Cheers,
Design videos are a must! Next project could be some all-analog device or some FPGA-based digital ASIC, or even an all-analog ASIC to demonstrate how to go from a board to a manufactured chip
I‘m surprised to hear that STM32s were a big topic in the supply shortage for some people. We redesigned devices for a lot of missing parts from regulators to ATMegas but we never had a STM32 missing. Seems our purchasing department has swept them all up. (Might also help if you are in the tens of millions a year). Maybe a general video about „good enough engineering“ would be interesting for some. Even in the professional world, if you have solved the problem it is rarely a good idea to optimise further. In most cases you are wasting money pretty quickly.
When we compare by uA per MHz we must compare similar cores. PIC - do 1M instruction per 2MHz meanwhile STM32 do almost 1M instruction per MHz. In case of equal computational performance, STM32 wins by smaller consumption. Or in other words it needs smaller amount of MHz to do the same computational task.
I've been looking at microcontroller recently for a project of mine and sure I probably could do without a microcontroller but I want some features that kinda requires it. But the biggest constraint I have is myself I am not able to design all the circuitry for the microcontroller, so Arduino it is. So yeah if you have a part that you know, does the job you want, there's no point to be stuck up with microamps...
I almost feel sorry for participating in promoting of the STM32L0x3 option. 😁 But on the other hand, it turned out to be an excellent video about the complexity of choosing "the right" microcontroller for your tasks and requirements. 👍🏻 I would like to say a few words in defense of the STM32L053. You absolutely rightly noted that it's not MHz that is important, but MIPS. Yes, STMicro cheats a little when claims consumption per MHz, but not at 1 MHz. To be fair, Microchip did exactly the same: 160 uA/MHz claimed vs 350 uA @ 1 MHz in the datasheet vs 230 uA @ 1 MHz for STM32. However, a twofold difference in CPU energy efficiency does exists anyway: the performance of the STM32L053 is at the level of 30 MIPS at 32 MHz and 6.3 mA (executing a Dhrystone benchmark), while the performance of the PIC24FJ128 is at the level of 16 MIPS at the same 32 MHz and 6.2 mA (executing just NOP). In addition, the STM's CPU is 32-bit, while PIC has only a 16-bit CPU, which means that when doing math with numbers larger than 16-bit, it will require from 2 to 4 times more core operations. So, I have zero doubts who will win in a direct competition in the energy efficiency of cores, which execute the same code every second, for example. PIС24 has just zero chances to beat ARM Cortex-M0+, which will do things faster and turn off much earlier, consuming less energy as a result. As for the power consumption of the peripheral modules, that's a completely different story... P.S.: I hate Apple for betraying the ideals of engineering in favor of marketing. 😁 P.P.S.: I’ll add a little more fuel to the fire: the STM32L053 current in the lowest mode is 24 μA max, the PIC24FJ128 current in the lowest mode is 150 μA max. 😈
If it's just your personal project, you're already comfortable working with it, and you don't care whether people follow along on youtube then the PIC is as good of a choice as anything. If you DO want people involved though, it's an abysmal choice. Hobbyists dislike PIC for a reason, it costs $2000, per flavor, for a perpetual license to the PIC C compiler.
@@EEVblog traditional compilers like GCC have trouble targeting non-mips PIC. The instruction set + architecture is rather unusual compared to most processors so a compiler needs a custom instruction synthesizer on the back end of the compiler.
@@marzacdev I seriously doubt that. At least not without making big compromises on coding style. And suggesting to use assembly in lieu of an optimizing compiler is entirely unreasonable. I'm not going to spend months learning a programming language specific to one processor when there are dozens of other micros that can be targeted with GCC.
I've been at Atmel boy for about 20 years and in the last 4 or 5 years have moved over to STM32 almost purely for the inbuilt DFU over USB (not all STM32 have it, but many do). It's great not to have to worry about a bootloader and having inbuilt USB means it's super easy for customers to do firmware updates in the field.
Dave, here's my vote for you to continue making design videos like this. They are very useful & informative. Thumbs up!
For very low- power applications, the dominant factors are usually sleep mode draw, draw of whatever timer you use to periodically wake, and also how long it takes to start from sleep mode.
The latter can overwhelm all other factors if using a crystal or resonator, due to the time to start the oscillator. That''s where having a part which has an RC oscillator that's accurate enough to not need a crystal can make a huge difference.
Yep. I did a worst case 24/7 operation calculation in this case to show that power consumption wasn't a huge deal in this application, so no need to go deeper and consider the various sleep modes.
Another option found on a few MCUs is a PLL multiplier that can run the CPU at a high multiple of the RTC crystal .
Intersting, i always wondered if "wakeup" overhead would negate any power savings going into sleep mode, especially if youre doing it very often, even asked chatgtp about it and it didnt mention startup time of the crystal . Great explanation.
I was very surprised to hear at the end that these sorts of design videos don't perform well - personally I find a lot of value in project based learning and especially the design choices they often have to begin with
Sadly, yes, the views are consistenty low.
@@EEVblog Well, I enjoy videos like this, because it is a rabbit hole I don't want to go down myself. A whole "Micro Shootout" series where you pick a few (3) MCUs with similar features from different manufacturers, build up circuits and pit them against reach other in the EEV octagon would make for fine viewing.
Yeah, I must be weird.
@@EEVblog It depends what "doing well" means. It is getting several tens of thousands of views for a pretty niche topic, so it is probably doing very well with the audience, only the size of that base audience is just smaller. If "doing well" means "pays the rent" I see what you mean and that's understandable.
Yeah I always find these videos very useful! As a hobby tinkerer I have learned a lot from videos like this 😊
Thanks Dave, that was topical for me and interesting, keep doing these type of blogs. I recently did a similar comparison myself but being short of time used the PIC24FJxxxGA for one project and am using the STM32L4xx for the current one to compare. I had also noticed the apparent uA/MHz advantage of the STM32L in the datasheet 1st page but as you rightly point out in a battery powered use case with most time in sleep/standby its the battery self discharge and circuit sleep current that matter more, and the devil is in the detail regardless. The PIC also has far greater pin MUX flexibility as over half the GPIOs can route an input or output digital peripheral signal (RPs or RPIs) which I found greatly simplifies your routing e.g. order of fast SPI signals going to/from an external IC can be ordered by the PIC to match the slave SPI IC pinout (thus avoiding vias and removing location constraints and maintain controlled trace impedances easily) but on STM32 for any digital peripheral you are constrained to use a fixed pin arrangement out of only 2-3 preset options - I have found that immensely frustrating about STM32. Extending that, on some STM32L4 they have cool sigma-delta digital sinc filter modules but Murphy's Law says the output clock is always constrained to be on the wrong side of the data stream pin so you have to effect a cross-over in your layout and you can only output one clock from only 1 or 2 pin options which means that if you have bit streams coming in from all angles to thus avoid a bird's nest of a layout an external 1:n clock buffer is required and is still hard to layout, whereas if I was improvising in PIC (they don't have that peripheral) you could pump out a clock almost anywhere and do multiple clock copies from any side of the MCU. I have however found the STMCubeIDE eclipse based IDE with its GUI based configurator and code generation much better than MPLAB X and although in PIC I usually configure the initialisation of peripherals via a laborious bottom up bit by bit procedure using a template, the CubeIDE GUI makes it happen in a snap and error free, and full optimisation is free of charge, so in that way STM have really raised the bar. I concur with your conclusion - its swings and roundabouts and generally they are substitutable but which one is better comes down to the requirements of the specific project. One last observation, STM now have the M33's and claim even 4x less uA/MHz than the L0's - but with performance better than even a Cortex-M4F - have a look at e.g. STM32U575xx claiming 19.5uA/MHz!
I would LOVE to see you go through the process of building the dev boards for testing the ultra-low power consumption -- the educational value here would be amazing even if in practice for this application it doesn't matter too much.
I love design videos like this. I like the STMs, never used PIC (I was an AVR fanboy). But at the end of the day, it's more important that you actually pick something rather than letting the entire project drown in finding and selecting that one perfect micro. Which is now out of stock because it took you so long to find it...
The thing I love about STM32's is that a LOT of the parts are pin compatible. So you can pretty painlessly go up and down in performance or across families, depending on your needs.
Makes EOL updates just a smidge less painful. CubeMX has gotten a lot better over time too. Use what you like.
That was the main thing when i worked on my master's thesis. I did all my work on F3 series, and downsized the project for te F0 series... all worked like a charm with minimal adjustments.
I prefer this kind of videos. I'm a graduate student and this is the process I assume I would be doing in an engineering company
As someone working in industry doing this kind of stuff, yes this is very much part of the process, and very easy to get stuck in rabbit holes on it. Although the chip storage that's made it a bit easier since there is so much less to pick from lol
that thing about sticking with what you already have is hard to overstate. It's knowing the toolset, being set up to manage the workflow, having libraries, you name it. There's often hundreds of hours involved in recreating that with a differend micro.
This is so true! It's sometimes a lot of work to change to a micro in the same family, never mind a different ecosystem.
100% correct. The quality of the libraries and tools is my #1 factor in choosing micros and that is where ST still rules supreme. Everything else I have tried has too much abstraction, a quirky release schedule or something else. (hints for MCUs with good libraries welcome)
@@chrisridesbicycles I woulds say that NXP beats ST, in terms of library quality... But it is a personal opinion, of course.
@@fxois3318 I am working on a project with a LPC5536 at the moment. Where I thing is falls behind from my point if view is that a lot of parameters that could be enums are just integer (personal preference and company guidelines) and you don‘t have the level of control of the ST LL lib. On the other hand, there is no function to get the transmission complete flag of the UART for example (only for the FIFO registers but that doesn‘t help when you have half duplex communication on one line). I also don‘t like that you have to use the online generator to build a library. A simple zip file is still what I prefer.
Can you get the chips? - that's all the matters. And STM is still the most "unobtanium" Also if you don't have a 32-bit timer just have a 16-bit timer do an ISR rollover that ticks a variable.
Not sure if the timer needs to run during operation or during sleep. If the latter, then another rabbit hole opens up - what timers can wake up the cpu. Or if they are internally chained, if that mode still works under (selective) sleep mode. Sadly, not enough requirements are given.
Pitfalls of datasheets are always really handy, Dave. When you're a high level hobbyist and working from prebuilt boards like an Arduino Uno or Rasberry Pi, you don't tend to need the detail, but as soon as you think, "Hey, I'll go build my own variant to do specifically this thing!" the datasheet and supporting docs become crucial to pulling off a decent design, particularly when battery life and other hard to measure stats are important.
...and don't forget the errata--ignore them at your own peril. I recall a PIC32MX design that looked to be the cat's whiskers, until an errata sheet rolled around that said "Uh no, that doesn't work--yet".
yeah, got to be cautious of datasheet sleep currents. They often quote the sleep current with everything turned off and in a state that no one will ever use it in.
Oh you wanted to run the watchdog? extra 0.3uA, You want brownout, extra 0.4uA, You want to keep the 32khz crystal active +1uA , You want to keep the UART active and wake from sleep on RX +10uA etc...
Thank you for taking the time to work on this. Very helpful to me.
These sorts of videos are what makes the channel so valuable (to me).
After the first page of the datasheet, you should always check the errata next.
I'm pretty new to the whole embedded programming world, so when I started making my own custom boards with an MCU, I started on STM because it's basically the only ecosystem of MCU's with semi-existent resources online. I wouldn't even know where to start with a different flavor of MCU, and I'm not sure how mature the hardware abstraction libraries are for other chips. Since it's where many people start now, and it requires a pretty considerable effort to learn any MCU ecosystem, i can see why so many people end up as STM32 die-hards. It's where they started and what they spent time learning.
I started out with 8 bit CPUs , then after a long break picked up with Arduino and Atmel, which was unfortunately bought by an overseas competitor while the Arduino team was destroyed by internal strife.
Your selection technique is awesome. For new designers starting out, picking a couple of good uC candidates and doing a quick trip through the data sheets is a very good start. Rather than do a deep dive on the data sheets; I would prefer designing the circuit and making a PCB for each processor. I like getting the power consumption figures from actual hardware. I find the PIC24's (and 33's) very easy to program. Haven't spent as much time on the STM's.
Why not an evk instead design a pcb?
@@JairoGustavo Good question. An EVK targets the u Controller itself.
When you do a layout of your actual design, you are not only evaluating the chip in its intended application, but you are (ideally) further down the development path in creating your product.
An additional benefit is that you have one or more options if chip shortages become a problem.
Page 61/136 datasheet. Bottom table. 88uA/MHz is for 'while(1)' loop at 4MHz. This is ridiculous stat xD
Good spot. Not that silly though as many applications might have while(1) foreground and everything else on interrupts or spend 99% of the time spin-waiting.
@@chrismorley5393 I meant - it is silly quoting it on product page as baseline uA/MHz figure. Sure it can be provided as additional data to better gauge code perf. But to quote it as official uA/MHz is plain misleading.
88 uA? Based.
Most of those low power modes look like they are specmanship, operating with the device in modes where they are basically doing nothing, with all peripherals totally disabled, and with barely any ability to operate the chip to do something useful. Also beware of the "typical", because you can be pretty sure that the low power modes were cherry picked devices, run at "room temperature" in a walk in freezer.
These types of videos may not be very popular, but they are very necessary. Thank you very much for the effort. Greetings from the south of Chile.
I made an alarm product using a PIC24F micro - it was a battery powered radio alarm made in the thousands. It used to go to sleep for almost all the time and then wake up every 2s for a few ms to listen for radio messages. Average current was a few uA. All worked nicely, but there was a problem with the PIC - when the USB subsystem was enabled (we used USB for configuring the device), you could never completely turn that part of the core off again, and it ended up using a few uA more - the PIC had to reboot to turn it off completely. This was undesirable because it took a few minutes to join the radio network.
The trick is absolutely to narrow it down to a manageable number of candidates then order them and run ur own tests. Doesn't necessarily mean building out full prototypes, but at least building up the circuit and then playing with the key variables for yourself.
With parts this complex you will never be able to select the optimum component based solely on the datasheets.
No Dave, these design videos are the absolute best ones. I dig'm.
I finally joined your Patreon because of this video. I'm a long time fan, and this type of video is what I'm here for. It's a sad reality that these videos don't pull many views, but they're the most valuable and interesting to me. 👍 Keep them coming! I'm excited to see more of this project.
For my personal "one of" projects I generally power from a usb adapter/wall wart. Usually a esp32. I'm not overly concerned if there is a bit of wasted heat as quite often the house needs to be heated regardless. Not in to just wasting the energy, but I don't need to worry to much. Still interesting to learn about the power consumption. Thanks Dave!
STM32L053 88 Mhz/uA comes probably from table 29: 353uA/4MHz = 88,25. In other STM32L412KB datasheet for similar tables 31, 33 power consumption is calculated to uA/MHz and it match values from first page of datasheet and info on mcu webpage. Also for STM32L412KB consumption is also presented in table table 4, that have no equivalent in STM32L053
About 88uA/Mhz: On page 63, code running from RAM, VCORE @ 1.2V, at 4MHz while (1) loop consumes 340uA. Divide it to 4 to have uA/MHz value which is 85uA, even less than what is claimed..
Also fibonacci calculations take 370uA at 4MHz, resulting to 92uA/MHz.. Not bad.. You were confused when you read "running from flash".. ARM can run code from FLASH and RAM. Running from RAM most of the time is faster with less power consumption.. You may move code that run repeatedly into RAM to save power consumption.. Code that reads the sensors, updates the LCD are the candidates..
I haven't watched your videos in a while. The reason for this is that I did not consider them educational enough. Now that I saw that it was about a new product, design, choice of microcontroller, I clicked immediately as if something had stung me. This is what we need, this is why we are engineers and follow this channel! Let's see ideas, ways of thinking and learn from experienced people. If all videos were of this type, I would watch them every day!
I am following this project design series with immense interest, just as I did with the uSupply. Keep it up, Dave!
This is a well timed video. I'm currently in my Masters while working and our class project is to design a low-power sensor system that can last long in the field based on our specs. This is awesome and I plan on sharing it with my class. Excellent coverage of all that is being looked at so far in our class.
I neither know not understand much of what you mention, but I like the way you present such topics, because every freaking time I learn a thing or two, no matter whether I wanted to or not, lol. ;D
I've been using PIC since the very early 16F series first came out way back in the early 1990s. After 20+ years, I found them less attractive when Microchip released Harmony with it's 4000+ page reference manual. Other devices have much easier configuration tools and libraries and to be honest, for me, the development tools are the prime concern
I've always found ST datasheets to be pretty sparse compared to Microchip's - which for me is a big ugh factor. Having to find a which register to enable a particular mode should be trivial, unless the manufacturer has failed to update their datasheet....
My favorite is the STM32L5 series. You can drop the power consumption extremely when needed, but provides ARM 32 bit power when it‘s fun time. 😍
I 💯 agree but I often question whether this is my go to as it is like an old friend.. and I can programme it with confidence
Main reason I never consider PIC is because Microchip are still charging money for the tools! AVR and pretty much any ARM chip have GCC, which is 100% free.
I cant comment from experience, therefore i listen to persons more experienced than myself, like Dave for example.
Always learning.
Showing the process of choosing parts for your design, good stuff.
Me designing new toy, I'm going to need a bigger power supply!
Great video Dave
Love these design videos and seeing what you think are important metrics to consider. Please continue!
In fact, there is no ideal MCU for all applications. I had used AT89, AT90 (first AVRs), ATMega, ATXMega, AT91SAM7, H8, H8S, R8C, SH2, MSP430, STM32, LPC200 and few others and everywhere was some troubles to use it. But what I learned is - don't believe to marketing papers. If they offer low power consumption let's take calculator, scope and multimeter.
When ATXMega devices started I did a project that should run 30 days from CR2032. 1.3uA in deep sleep looks, wake up each two seconds to get the ADC data and store them, fall down to idle... It looks great in ATXMega64D3 whitepapers so HW guys uses that and put final board to me to program it. What was real?
1. Reset current was 1.3mA. There was no way to start with older battery as its internal resistance didn't allow to increase voltage above BOR level and it kills the battery..
2. Real consumption was 64uA instead of calculated 3,5uA in this configuration as somebody from Atmel forgot to write that wakeup took 640ms
3. Tech support of Atmel didn't believe it until I sent them demo code, configuration of lock bits and images from the cope. After two months they apologize me they didn't test this setup. Material dor 20k units was alreaady ordered...
4. Four another undocumented HW issues made the firmware design one month longer
Lessons learned: From all the numbers in Atmel's AT64DB3 datasheet only package dimensions were OK
If there is a critical parameter I want to have a week to check each of it it before start the desing since this project.
Really love this format, please go on, dave! ❤
20:14 In fact, regarding the supply crisis. I actually managed to order free samples of a few different Microchip parts in the midst of worst part of the chip shortage. Microchip delivered! I thought for sure they'd cancel the order. I enjoy working with either STM32 or PIC, but I must admit, I have a soft spot for PIC's -- it's the platform I originally learned embedded programming on.
Thanks for the video! Love the development series. Give us more!
Love videos like this! I do love following a good project. Having been bit hard by STs supply chain issues, I'd struggle to go back to using them
This is good stuff, it lets me know all the things I should be thinking about when making designs.
I'm essentially pure software, with just a little bit of homebrew device making for home automation, but it's really heartening to see that it's not just software people who like to say others are doing things wrong when they don't know the full list of soft and hard factors that made a decision happen.
Of course, sometimes people are just not thinking - with modern toolchains all you need to do to switch to a new micro is to change the tools in your cmake and move some addresses about for your IO. Lots of people seem to know one architecture and decide everything else is a massive headache, even if that means using a £3 controller with long leadtimes when there's a £.90 available.
I'm sure you noticed this, but I believe the J parts are one-time programmable. Be aware. Also, be sure to check the errata for the Microchip part that you are thinking about. Sometimes some peripherals just don't work.
ST lost my business many years ago, repeatedly. I was doing system design and picked out a part that looked like it would do what I wanted. I just had some questions, and it being the depths of the recession, the apps engineers & reps were very keen for new business and were happy to meet with us (which in busy times, they're harder to get ahold of). I had the ST apps engineer look me directly in the eyes and lie to my face about the capabilities of the processor I was looking at. Later on another contract, I was doing some interface work with the software engineer and an FPGA, and that software engineer could do nothing but complain about ST and their software ecosystem, and again, shock and amazement, the ST part woefully underperformed. Its a pity their support suck(ed/s), they lost me as a customer at that point, along with that entire company. Not that I'm a super fanboy of Microchip**, had I done as a Microchip employee what that apps engineer did, my boss would have had no problems burying me out back in new parking lot construction. Sad that I have to design them out of my design ecosystem completely, but I can get what I need elsewhere.
All that said, plenty of vendors though do stupid things to lose customers. Lattice likes to EOL their chips super fast, ST lies, Microchip I hope you like errata sheets and some weeeird designs, TI good luck finding anything modern with availability (or these days, older), etc etc.
**Disclaimer I have been [past tense] a Microchip employee, not a PIC fan, but I use their AVR+M0/M4 stuff among other vendor's MCU's for my applications these days. TI, Lattice, Microchip round out the bulk of the MCU's in my inventory.
I hear you... ST has shitty datasheets and underperfom, Microchip has good documentarion ma its chip are full of surprises... I prefer freescale/nxp if possible, but they are expensive.
ST lies? About what?
@@VndNvwYvvSvv 14 years on (this was ~2009) it probably isn't relevant anymore, and I have no recollection of what part it was. It was a specification on the NAND flash controller, and it was basically implemented in software and not in hardware as promised, after the software team broke the news to me.
@@MartinDoesStupidThings same here, chips for distance sensing was almost all firmware library with their undocumented firmware and undocumented registers with a datasheet like "use the library".
Never again.
Interesting video Dave! Please keep it up!!! Thank you! Kind regards, Vincent Pothuizen 🙂
I have used Microchip in product designs since the 90's and I love their field support and they very seldom discontinue products.
Were the dev tools available to the hobbyist then? I seem to remember a $20000 cross-compiler.
But you can’t get certain Microchip parts…
@@AppliedCryogenics - there were 3rd part compilers for PICs before Microchip really got on board with rolling their own. Back then a lot of projects could just be written in assembler as well which was "free" in the MPLab SDK.
I still have my PCB,PCM,PCW PIC C compiler software (circa 1999) from Custom computer services, both disk and manual, on my shelf.
Cheers,
Mikroe makes compilers and dev tool the compiler is even free if you are under 1kb.
Very interesting discussion. The RISC processor is optimized for instruction throughput (MIPS) per unit area of Silicon. Optimizing for power is an entirely different issue because it would require Voltage/Frequency scaling including switching ON/OFF.
You identified the energy sources an Alkaline cell, there is little to improve there. The dominant power consumption isn't as clear, could be MCU, IO devices or LCD display plus duty cycle/sleep.
Thank you for the discussion.
There are maybe a couple of valid reasons to think of to go for 8bit if you need 32bit hardware(like timers), but I would advise it. A 32bit that uses more per Mhz can still be more efficient than an 8bit that uses half of it. If the 32bit(one clock to move 32bit data around and higher IPS) is 10% run mode and 90% in sleep mode and 8bit(4 clocks to move 32bit data around) is 40% in run mode and only 60% in sleep mode then the 32bit will be use less energy.
Looking forward to the next video on this project
Picking what you know has the features you need, you know how to program and know you can get your hands on totally fine even if its 8bit versus 32
Great videos Dave, there are a lot of details I have learned from them, thanks
I've never used either of these but I found this video fascinating. Thanks!
The STM32 series parts are pretty nice for most general purpose applications if you need the grunt, but I have found that many of the peripherals can have a lot of frustrating gotchyas for things like USB, serial audio protocol and spi transfer sizes, weird DMA buffering workarounds, etc. At the end of the day I tend to select an MCU almost soley based on the peripherals, power consumption, OFF THE SHELF STOCK FROM MULTIPLE DISTRIBUTORS, and available development hardware.
Thanks Dave! These videos are very interesting!
Very good video. Please do more tech discussions. You provide some high quality good advice here.
I've used numerous PIC chips for smaller projects and the MSP430 series for more complex projects. I haven't tried any of the STM chips yet. For the PIC chips, I don't think I've ever bothered moving any code to ram though it certainly wouldn't be difficult to put small core assembly loops there if the project is such that the cpu spends most of its time spinning. We almost never use sleep modes on the PIC chips beyond implementing the "off" button... the restart latency is too high. So idling in ram isn't a bad idea.
I'm voting for Microchip PIC. The Positron PIC Basic Compiler is a good compiler and allows you to define many functions and macro.
The Compiler's Programmer, Les Johnson, is constantly updating the Compiler and you can ask him directly about the problem you are having. The compiler's float math operations are fast and accurate.
For a single fee, the compiler 16,18,24 and dspic series are available to you. This is a great advantage. Also, Less can help you with your questions on the forum page, as he reads the datasheet of all microprocessors step by step.
STM32L is fine for a bunch of uses, even having a bit larger chips... amazing stuff that worked on multiple projects so far. But if Arm is making changes to its licensing moving arm tax to the end product and not the chip provider. It makes sense slowly move all new products away from arm altogether. But low power matters, if the battery is hard to replace and the product needs to last for many years.
I do hope you continue to do these design videos, I always learn so much! Sux that the algorithm ends up punishing you for these, they are really good sources of info!
I use stm only because I have worked with it a lot. It's not the best tool but that's the compromise I am happy with. That and I am lazy.
For the STM32L0 series is 0.95 DMIPS per MHz. This means if you want to compare MIPS of the PIC vs STM32. You need to compare at approximately 0.5MHz. On the datasheet (page 63) you can run from the MSI clock for Typical 83uA. Therefore PIC = 210 uA at 0.5MIPS, vs STM32 83uA at 0.5MIPS.
I couldn't find the headline figure of 88uA/MHz, and on page 18 it even explicitly says for running from RAM 140uA/MHz.
The only thing I can think of is that the power figures on the STM32 datasheet are for 125C, which the headline figure might be for 25C.
I love this kind of videos! --nowadays any PowerPC core mcc or cpu are out of stock, I bought a couple of tens with delivery on November
We had a product designed around an NXP part, had a huge order for it right at the start of 2021 and we had to redesign it for an ST part that was in stock at the time and we just got all the once we needed. Spend like a month redesigning the board 5 months re-writing the code ... that was some crazy time.
Isn't 5 months rewriting too long? I always write my own drivers for MCU's.. Switching a MCU becomes switching the drivers..
@@denizcancgsar2810 There were 3 main reasons.
1. The programmer who wrote the original code used the NXP HAL, without making an "intermediate" layer, so switching the HAL was not as quick as I would have liked. For our projects making a HAL from scratch is out of the question. We CAN write that code, but we juggle many peripherals and on tight deadlines. The HALs from the manufacturers speed it up.
2. Also we changed one other main IC, because we couldn't get the original one. That required a significant rewrite.
3. We had a new embedded developer colleague and management gave the job to him. Great C programmer, but it was his first time working embedded and it took him a while to get the hang of it. I'd have done it a bit sooner ... maybe.
@@Nik930714 The HAL's from manufacturers have always been garbage.. Somehow hardware developers are the worst in the programming area.. Spending time on their HAL consumes more time than rewriting the whole suit.. Only area I keep myself rewriting is the Bluetooth LE stack not because it is complicated but because of the certification process.. But spending 4 months on race conditions, such as indication stopping working with Xiaomi devices, not properly negotiating with Realtek chips made me think that I wish I have written the whole BLE stack as well..
Design a framework such as UART would be like this, I2C would be like this, and the HAL would be very small part of your problem..
That way same code runs on MSP430 as well as on NXP and ST's.. That's what I've been doing..
@@denizcancgsar2810 Oh yes, manufacturer HALs used to be pretty bad. About 5 years ago i re-wrote the UART and I2C stacks for STM32, because they had huge problems. They barely worked. Now days they are quite good, I've not had problems with them for years.
Same goes for NXP - they had problems, but are pretty much resolved by now. I've not used any MCUs for almost 10 years now, so I really cant comment on their HALs, but the ST and NXP once are solid now. Also the graphical tools for setting up the peripherals save so much time. Especially for the more complex stuff like clocking or SDIO or whatever.
@@Nik930714 I can not say the same. Visual IO mapping is nice but the rest..
For instance UART design of both of them have major issues. First of all they have lot's of code in IRQ's. Nearly all code runs in interrupts which creates latency hell.
Last time I helped for a code that runs on ST, STCube was not using FIFO but only receiving given amount of data which was ridiculous even 30 years a go etc..
I plan releasing my multiplatform framework soon.. That is one may run its code on Nxp, ST, MSP430 or even on Nuvoton's ARM MCU's.. Designing "write once run everywhere" has been torture for a time. It is very difficult finding a common base for the same module etc.. That postponed my plans a lot..
A question: For you, if you were to use the framework, will it be a problem using C++ instead of C? I wrote it all in C++ taking care of the C++'s "invisible traps"..
I looked up the L0x3 parts after that video and saw they can't compete on price and availability at the moment, not sure what NXP or other cortex M0's have to offer in that segment.
For personal projects I like the STMs but for professional projects you have to be agnostic, even if I don't like working with Microchip's tooling (maybe it got better it's been a while since I worked with them)
Good compiler support is important too though, for more complex software where you need modularity and abstractions it's a huge leap from C++03 to a modern standard in terms of code size, efficiency and reliability.
They also can't compete on basic functionality. I think I used 32L073 specifically for LCD control. Then with the official STM32 IDE I made basic LCD test, everything according to the datasheet. Well the debugging shows the CPU crashes right after enabling the LCD with 4 common multiplexing.
Further research shown that static mode works (can't really use that) but anything beyond that doesn't. Posted about it on STM forums, no reply. I ordered other pin compatible parts, tried again without success, the other MCU didn't even connect to the ST-link even when I checked and the second boot pin should be wired fine for programming. So that's the end of my STM32 development.
Very good choice. I've used these and ran off of coin cells. I had to measure the voltage on the coin cell every month to see the drop in its voltage.
The thing about "can you source the part", goes beyond a single chip. We have been in wait list to get a server, because not available CPU, or SSD, or what not.
Some times you can get around with a similar part, other times you just can't; and if you are going into a new design with readily available part you also need to worry about it... oh my.
A new vector in the design phase to consider.
I like the design video's a lot. There aren't that many video's around that actually explain what there doing. Or it is a video about e.g. a power supply built but then it just involves some aliexpress stuff wacked in a box and just wire it up. I've watches the uSupply series and likes that too. For this video, I'm not that concerned about mcu a or b, but still interesting that you mentioned you would build the actual circuit up to test. So many conditions, to me that's just insane. When designing I really get lost in datasheets in general, really hard to read. Also explaining something and than take it to the breadboard is interesting. Especially what the pitfalls are. Or what makes an op amp oscillate and how to fix that. I liked the fundamental stuff a lot too. Guess I like everything that isn't popular on the channel haha.
Thank you for the video, designing something and you put me on the right track. Love this, need more!
Spec sheets are spec sheets and are a ballpark until you have a prototype running on a data logging meter.
"execute code from flash - isn't that a given?" - you could also execute from RAM, e.g. for speed purposes, or if there is only one flash bank, you cannot at the same time program the flash and also process further instructions & be responsive e.g. during a firmware update.
You should also compare erratas. Just in case a critical peripheral or its function doesn't work...
Guess part of the problem is that these videos are harder to digest /can't be watched anytime as light hearted ones. I don't watch them as willy nilly as your other stuff, but when I'm in the right mood, if I think about it, these types of videos are the most interesting and most engaging ones on your channel.
We used to have the same crap to deal with when comparing battery data sheets. The specs from different manufacturers were done at slightly different conditions , so never side by side comparable. Test was always the best way. Duracell were the worst back then....so much useful data was left off
I think the uA/MHz spec is dynamic power over and above quiescent current.
Maybe Project Farm can help you out with that :) "We´re gonna test that!"
As someone who has only ever designed and built one project (a esp8266 based temperature / humidity and motion sensor to link to home assistant) I don't rearly understand everything that goes into the design of a product so find the design videos fascinating
lol. looks at uA/MHz and ignores instructions per MHz AND code density. ARM is more than twice as fast at the same clock speed (MIPS vs MHz) AND ARM instructions do ~ 25% more work than MIPS instructions on average.
STM provide a power calculator. I don't know how accurate it is, but it may be worth checking out, if the PIC has something similar.
Good decision, go with what you know.
It is tempting to concentrate on the microcontroller hardware specification, however, for projects that involve a small production runs. It maybe the cost and availability of the development tools that are the limiting factor determining the choice of microcontroller.
For amateur Projects, and those involving a limited number of builds, such as prototypes, one off test equipment, etc, the major project cost is likely to be the purchase of the compiler and the development toolset. This is why the Arduino is so popular, its toolset is free.
Even for projects with larger production runs, the choice of software development tools maybe a critical factor.
Worth asking how much for a C compiler, debugger, with IDE for the device you want to use. What are the software limitations? How much for single seat commercial licence, and how long does it last?
The run mode power on the STM32 has a typo, is 88.8 uA/MHz! 🤓🤣
Historically its always been NXP that was winning over ST Micro parts for the companies I worked for. But then I have not been part of a decision process there since around 2014 so, who knows, maybe ST micros are better now. NXP parts were pretty pricey tho.
Good video on the difficulty in defining actual real world power consumption in your choice of MCU. Getting below 100 uA the choice in such things as what mode to leave GPIOs in start to play a big part in sleep mode currents, even asking if external parts should be powered down or not.. a powered off component will turn into a resistor and can pull current from MCU pins.
Cheers,
Design videos are a must! Next project could be some all-analog device or some FPGA-based digital ASIC, or even an all-analog ASIC to demonstrate how to go from a board to a manufactured chip
Mirrored video? Thought Im going mad there for a second with those red/yellow buttons on 121GW
Clearly, Dave is a little biased to Microchip products!
Or someone else is biasd to a other. Uhh might i source the power of stm32 i need ble, wifi, +512kb memory, more than 8mb flash, +31 IO‘s
I‘m surprised to hear that STM32s were a big topic in the supply shortage for some people. We redesigned devices for a lot of missing parts from regulators to ATMegas but we never had a STM32 missing. Seems our purchasing department has swept them all up. (Might also help if you are in the tens of millions a year). Maybe a general video about „good enough engineering“ would be interesting for some. Even in the professional world, if you have solved the problem it is rarely a good idea to optimise further. In most cases you are wasting money pretty quickly.
When we compare by uA per MHz we must compare similar cores. PIC - do 1M instruction per 2MHz meanwhile STM32 do almost 1M instruction per MHz. In case of equal computational performance, STM32 wins by smaller consumption. Or in other words it needs smaller amount of MHz to do the same computational task.
Dave, you really know how to drive a point home;)
Good video. I've been debating pic vs stm
Great example, Thanks!
very informative, thanks!
The ARM can run code from Flash or Ram
I've been looking at microcontroller recently for a project of mine and sure I probably could do without a microcontroller but I want some features that kinda requires it. But the biggest constraint I have is myself I am not able to design all the circuitry for the microcontroller, so Arduino it is. So yeah if you have a part that you know, does the job you want, there's no point to be stuck up with microamps...
I almost feel sorry for participating in promoting of the STM32L0x3 option. 😁 But on the other hand, it turned out to be an excellent video about the complexity of choosing "the right" microcontroller for your tasks and requirements. 👍🏻
I would like to say a few words in defense of the STM32L053. You absolutely rightly noted that it's not MHz that is important, but MIPS. Yes, STMicro cheats a little when claims consumption per MHz, but not at 1 MHz. To be fair, Microchip did exactly the same: 160 uA/MHz claimed vs 350 uA @ 1 MHz in the datasheet vs 230 uA @ 1 MHz for STM32.
However, a twofold difference in CPU energy efficiency does exists anyway: the performance of the STM32L053 is at the level of 30 MIPS at 32 MHz and 6.3 mA (executing a Dhrystone benchmark), while the performance of the PIC24FJ128 is at the level of 16 MIPS at the same 32 MHz and 6.2 mA (executing just NOP). In addition, the STM's CPU is 32-bit, while PIC has only a 16-bit CPU, which means that when doing math with numbers larger than 16-bit, it will require from 2 to 4 times more core operations. So, I have zero doubts who will win in a direct competition in the energy efficiency of cores, which execute the same code every second, for example. PIС24 has just zero chances to beat ARM Cortex-M0+, which will do things faster and turn off much earlier, consuming less energy as a result.
As for the power consumption of the peripheral modules, that's a completely different story...
P.S.: I hate Apple for betraying the ideals of engineering in favor of marketing. 😁
P.P.S.: I’ll add a little more fuel to the fire: the STM32L053 current in the lowest mode is 24 μA max, the PIC24FJ128 current in the lowest mode is 150 μA max. 😈
Sounds like development and production cost, between good enough devices, is a dominant consideration for this design.
If it's just your personal project, you're already comfortable working with it, and you don't care whether people follow along on youtube then the PIC is as good of a choice as anything. If you DO want people involved though, it's an abysmal choice. Hobbyists dislike PIC for a reason, it costs $2000, per flavor, for a perpetual license to the PIC C compiler.
I haven't done PIC for quite a few years, but don't they have a GCC variant? You only pay if you want the really high level optimisations?
@@EEVblog traditional compilers like GCC have trouble targeting non-mips PIC. The instruction set + architecture is rather unusual compared to most processors so a compiler needs a custom instruction synthesizer on the back end of the compiler.
@@EEVblog Pic32 has a GCC compiler since it's MIPS
The free version of the compiler is good enough for almost every application, if you need the extra performance... write in assembly.
@@marzacdev I seriously doubt that. At least not without making big compromises on coding style.
And suggesting to use assembly in lieu of an optimizing compiler is entirely unreasonable. I'm not going to spend months learning a programming language specific to one processor when there are dozens of other micros that can be targeted with GCC.