Embedded - 104: Only the Paranoid Survive

Episode Date: June 10, 2015

Atmel’s Andreas Eieland (@AndreasMCUguy) spoke with us about low power chips and benchmarks, including tips for measuring and achieving the lowest power possible. EEMBC has a low power benchmark: ULPBench. EETimes wrote up a great introduction to the benchmark. Atmel’s SAM-L posted some excellent numbers for ULPBench. Chris wanted to look at processors between Cortex-M4 and phone chips. Andreas suggested the SAM7, SAM E, and Cortex-A5. Programmable logic blocks (Look Up Tables) Coding tips and tricks for AVR micros (most things apply for all embedded development) App Note: Ultra Low Power Techniques App Note: Performance Levels and Power Domains Andreas was also on Episode 15: Robot on the Front, speaking about how the AVR processor line came to life, why there is an AVR in Arduino, and the spirit of making things. The Planet contest ends Friday June 12 (at midnight your time). Check out their jobs and send in your contest entry. Also, check out Elecia’s BLE Intro.

Welcome to Embedded FM, the show for people who love building gadgets. I'm Elysia White, here with Christopher White. Today we are joined again by Andreas Eiland from Atmel. We're going to talk about power. Before we get started, I wrote an intro to BLE article that I'm quite pleased with. It's in the linker blog on Element 14. You can find the link on the website. And I would like to remind you that we still have that contest going for another week.

Email us to enter. Tell us what you'd put in a satellite. Be as fanciful as you want. See if you can outdo a teapot full of spaghetti and meatballs. Or using solar weather to predict Terran. The contest winners will be chosen randomly. We have two copies of my book and one copy of Kerbal's space program. Why satellites and Kerbal?

I'm glad you asked. This contest is sponsored by Planet Labs, a new kind of space company based out of San Francisco. They're building satellites to photograph the entire Earth every day. They're ditching the old slow-to-get-things-done mindset in favor of developing a new approach to space development with cheaper hardware and faster cycles. They've already put 80 imaging satellites

across seven major hardware generations into orbit. And right now, Planet is on the hunt for the embedded and electrical engineers they need, especially intermediate to senior level people. If you want to work on space gadgets, and who doesn't, reach out to them, embeddedfm at planet.com. There are 40 positions open at their website. Take a look.

Send them your resumes and me your ideas for the contest. Now our guest. Hi, Andreas. Welcome back. Thanks, Christopher. Thanks for having me again. Could you tell us a bit about yourself? Yes, my name is Andreas Eiland, been in the embedded business for a long time. My education was actually building gadgets, something called cybernetics, which translates to robotics, but also ABS brakes and everything else of control systems. Started working in atmel actually

almost 10 years ago so i've been there my entire career started doing application support for big customers and writing application notes and papers and then at some point i guess some clever people in the company found out i was better at talking than writing code so they moved me to the marketing group. And since that, it's taken me all over the world for a lot of interesting customers, a lot of interesting makers and startups. And the last couple of years, I've been here in the Bay Area. So I wanted to ask you about low power things. I have all sorts of questions, from how do I tell if a processor is lower power

than its competitors to how do I measure power and how do I minimize it? I think we should get started with how do I tell that a processor is low power? Yeah, so luckily the situation is getting better here. Seven, eight years ago it was easy. Power was predominantly dominated by which cpu you had right okay and 8051 is four times as many cycles as an avr avr is lower power

ti is a 16-bit efficient computer that's more efficient than an 8051 and you had like you did it very easily by core um last years, the gap has closed much more between the different CPUs. And also there's been many people going to ARM. There's a lot of ARM processors out there. So just saying, okay, an M0 plus is more efficient than an M0, but is that really where my power consumption difference will be? So the result is for many years, you saw what we call

benchmarking. It's like active mode, this number, 70 microamps per megahertz, but you're running a wild one loop. So you're just running from Flash, right? Or you're a bit more clever. Just from RAM. Yeah, just from RAM, sorry. We're a bit more clever and say, oh no, I'm not running a wild one, I'm running a Fibonacci algorithm. Well, it's recursive. Again, you're just running from RAM. So really you're not doing anything different than the wild one. And I think everyone in the industry realized this,

that just fighting on this benchmarking doesn't give a good benefit to the developer to actually make a good selection of the devices. So Embassy took an initiative to create a new benchmark. And Embassy already has the CoreMark, which is one of the more favored embedded processing benchmarks. Well, but it's embedded. But it's embedded for things like the Tegra chip and NVIDIA big chips, not our chips.

Exactly. And you're saying embassy, it's EEMBC? Yeah, EEMBC.org. But what they did is they put down a working group led by EEMBC. And everyone's there, like Atmel, TI, Microchip, Scilabs, ARM, ST. Basically everyone said, okay, let's try to agree on a benchmark for low power to at least give people the first traffic sign on where am I going, right? So the first version of it is called ULP Bench. It has a defined workload that you need to do.

And then you do it once every second, and you do it a lot of consecutive times. So it's a mix of active mode and power mode. You're allowed to tweak the code, but you still have to fulfill the task. So you can optimize it to your setup, but you have to complete the task. You can decide, I want to run fast,

sleep for a long time, I want to clock it slower, sleep for a shorter time. All these things you can decide do I want to run fast, sleep for a long time, do I want to clock it slower, sleep for a shorter time? All these things you can configure. So there is still some gaming. Well, it's gaming to optimize for your processor. And that's what you would do as a developer, right? This is my power budget.

How do I do my clocking versus my sleep period to get the performance and the battery life I need? And that's okay in the embedded world, because you're used to doing that. If it was a general purpose CPU that you were running Windows on and running a benchmark on top of that, then yes, gaming it to match the benchmark wouldn't really be appropriate because the application developer is not going to say, oh, I'm on an AMD processor, so I'll do it this way versus an Intel.

I do think CoreMarket's gamed a little bit. Yeah, but this is ULP bench, right? So it's a benchmark for low power. Actually, that's what it... ULP is Ultra Low Power Bench. But what's nice is, to avoid the real gaming,

which is the measurements, it's a defined measurement setup that some really clever guys from TI set up. And this is hardware you have to buy from Embassy to do the setup. So they control all the measurement setups. So you can't take your slightly out of calibration oscilloscope and measure that, right?

And it measures it really accurately and you run many iterations to find it. And you can find all the reports and everything on their website. The one strange thing though accurately, and you run many iterations to find it. And you can find all the reports and everything on their website. The one strange thing, though, is you're used to low power being the lowest possible number, but benchmarking higher is better, so there's like an inversion. So higher is better for ULP Bench. So the tool to monitor is called Energy Monitor?

It's called Energy Monitor, yeah. And it was only $75, so it wasn't a huge burden placed on people who want to try it out. No, and I think most people that buy it is actually going to be people that create the benchmarks, like companies, but also some journalists around. But for the average developer, you can get very good results just by running a nosy telescope right you don't want to have because this relies on having to do cycles and discharges and stuff to measure it okay so i want to go back and talk about some of the benchmark things um and i know you want to gloat some about some of the benchmark things. What?

Atmel did post some very nice numbers there. But let's talk about how to measure power on a system because when I choose my processor and I take it home and I put it in a system, I still have to figure out, am I using it appropriately? Should I be using a slower clock and staying on longer, or should I be using a really fast clock and waking up briefly and then going back to sleep? Yeah, and that ties back to your battery chemistry as well, right?

How high peak current can I sustain without doing a big discharge, right? Especially if I have a combination of a micro, some sensors, radio. If everything peaks at the same time and you have a rechargeable battery that current spike will kill your battery time as well so there's so what the things we are doing to address this is on our new low power products like the we have a new atmel smart product called the l21 which is m0 plus based and on our development kit there we actually put a power monitor that measures all the current going into the device. And the way it's set up, if you have a load to a pin, that will also be measured. Because that's important for your system, right?

You really don't care if the power consumption is from the chip or from a capacitive load or something you have on the pin. You want to see, when am I consuming? How can I get my total system power consumption down? Exactly. And the nice thing about this energy monitor is it gives you a real-time plot of your power over time. And you can mark it and get average current, peak current, all these kind of parameters. But the really nice thing is if you click a point on the graph, it's logged with a program counter and it takes you to the code.

So if you see a sudden spike and you wonder what caused this spike, you click on the graph just before it, you jump to the place in the code, and you can try to find out what settings did I do that triggered this spike. That's very nice. Perhaps I should do my A2D converter slightly slower.

I only needed two samples. I have to run at one mega samples. That way you can trace and find and optimize. When we are at the power levels, Atmel and many other vendors are now, it's no longer, it used to be just the CPU and the SRAM, right? But now we need to look at power

consumer number 2345, right? What's next? Is it the A to D? Is it my DAC analog comparator? And the only way to trace this is to have a way to find in your code what triggers what on your power curve. You said energy monitor, and that's the same name as the benchmark tool, but this is the energy monitor for the SAM4L21.

Yeah, SAML21. This is embedded on our, we call it the X-Plane Pro, which is our starter kit basically that was a very nice board it had a lot of features that you could use I didn't realize that you could monitor current that way yeah on the latest one you can

you should have mentioned up front I could have brought you one I noticed in my release notes from the last time you were on the show that at the end I demanded a dev kit before you were allowed to leave, and I wondered if you were going to remember that. Apparently not. I didn't, so I'll have to mail it over.

But, okay, so if I don't have that feature, which does sound cool, how do most people measure current? And I have various things I can suggest, too. I just wondered. So what we see most people do current? And I have various things I can suggest too. I just wondered. So what we see most people do is just plain old, either a scope, a real scope, or just one of those nice, all our FAEs just bought a nice USB scope

that they're using that's also a logic analyzer. The Celia. The Celia, it's so nice. Oh, we love those, yes. Oh yeah, I was envious at the FAEs when I realized they got their rollouts of them. I have one here, there's one over there. Yeah.

So that's what most people use. And then worst case, you overlap that with some kind of serial dump, right? So you have a log of what you're doing. Because the problem is the moment you turn on the debugger, especially if you turn on trace, you force on the entire clock tree in the device to be able to read all the registers.

So you no longer see the power consumption you'd see in a real application. That's why if you're really doing power debugging, you need to do a serial dump or some LEDs or something that's not forcing your clock tree to show where you are in your code. The occasional GPIO that shows you where you are in your state machine. Exactly.

Very familiar with that. So an oscilloscope, but you can't just hook an oscilloscope up to the thing unless you have... Do you use the resistor method where you put a resistor in serial and you have to calibrate your resistor to be right for your system? Yeah, so normally what our apps engineers do is they use a resistor and they put it on the ground side very often of the micro. Oh, I usually put it on the power side. Do you know why they do that?

No, I should check. Okay. They might do both, but I've seen it often on the ground side. I've seen a couple of these widgets around that I've got one here from TI that's a specialized reader, and somebody told me it was so that it could read more precisely and all i find is that i keep blowing it up so i'm totally going i'm going back to the resistor method later uh so i can yeah so what we saw especially when we did the work for the power analyzer is um and that's the the... The hard thing is your dynamic range changes so much

because you go into sleep mode over a couple of cycles and suddenly you're trying to measure sub-1 microamp, like hundreds of nanoamps. The next couple of clock cycles you wake up and you're at a couple of milliamps, worst case, if you have some big loads, right? You'll blow the gain stages of most A to D converters if you don't have a way to to prepare for that right exactly so if if you want to measure like

12 milliamps you usually want like a 10 ohm resistor but if you're trying to measure 12 microamps you want how was that 100 yeah, 100? Yeah, 100-ohm resistor. And then you still have to make sure your resistor is good enough for power. All the power that's going to go through it. Don't get these quarter-watt resistors if you're going to be pulling power. Yeah, you have to make sure your solder joints are nice and well and not a lab in a hurry solder joint. And so once we have a resistor in place,

and we know it's a decent resistor of the right size, which is tough if you're switching back and forth, then you put an oscilloscope probe on either side, and then you can view it. Yeah. So that's what your engineers do. Yeah, especially if you're doing, well, we have more advanced ways of measuring, right?

But that's normally how you'll do it. And on all our boards, we try to make a connector available so you can measure so basically you move a jumper and you can measure over two points and you can measure the current going into the system that's very nice that's very nice of you of course i look over here at my board i've got like 12 different connections and four power i've actually got four power supplies for this system i see you have an arduino over there as well which is actually that was not really connected okay well I would say the motorboard oh nice I'm very excited about it I would say for Arduino I think one of the things the community there needs to work on is low power because they're they focus a lot on making it easy

which is great but they don't use sleep modes and they force everything on so it really and you see people want to do an arduino based battery powered system it's like yeah they're you're running at like 8x what you could be running out of that micro just by the way the software is set up i like those people those are the ones who come to me and then i have to actually pay me because they don't know how to do it themselves okay so so let's let's talk me out of a job then. How should people look at the Arduino and figure out how to get it lower power? So first of all, unfortunately,

you have to go out of the Arduino framework so you can enable a bit more sleep modes. Yeah, ditch the IDE and go to GCC. Yes, go to GCC. In our tools, at Meld Studio, we have a way to import sketches into a GCC environment. Good idea. Yeah, and then try to read up on the data sheet

for a device you're using. You'll find an explanation of the sleep modes. In some modes, just the CPU, or everything's on. In other modes, the CPU is off, but everything is running. And then you have sleep modes where perhaps everything is off except your real time clock. And just try to make a state diagram of your code and understand what functionality do I need in which different states and map that against the sleep modes. And then enabling a sleep mode is actually two lines of code. It's setting up the bitmap for the sleep mode,

and then just sleep enable. Yeah, so you were saying different sleep modes. Yeah. So I can think, a lot of processors have the, I'm off. The only way to wake me up is a hard outside button. Yeah. A GPIO toggle has to happen before I wake up and do anything. Are we not talking about sleep modes without RAM retention,

like super deep modes? That one's super deep. But sometimes they're the ones that keep the clocks going, and so if I get an I2C message, it will wake me up. And those usually have some RAM retention. But the very lowest may not have any RAM retention, or if you want to be super exciting, you have the button go to a capacitor

and then the processor has that long, however big the capacitor is. To finish the task. To either finish the task or to pull a line so that it retains its power. That's one way to make your sleep current zero. Yeah. Well, instead of having a sleep mode,

you put a latch on the power line, right? And that's your wake up. Yeah, that's it. As a programmer, I don't like that because it means every time I wake up, I'm waking up cold. Yeah. And we see many people like to,

like those super, super deep sleep modes that we and other people promote like the sub 100 nano amp sleep modes for a big cortex m style processor they are more or less a marketing mode or a shelf mode that you use while you ship a product right yeah for for real applications normally you need at least a couple of registers so you know where in your state machine you should start executing when you wake up on the sleep mode wake ups though for for most micros uh well yeah not just atmel most micros you have you can wake up without any clocks on asynchronous events so pin change events that you talked about like a button but we have also have some nice technology called, we call it sleepwalking, which actually means that a peripheral

can request power and clock on demand. So it can be powered up. And if it recognizes a start of frame interrupt from a UART, it will request power and request clock from the device controller and be able to respond to the incoming data. I don't think I've seen that, but DMA is also one of those ways to really improve your power.

Yep. I think I got an email that said, what is DMA? So maybe I will, do you want to take that? Well, I can start at least. Sure. So DMA is a direct memory access controller. So it's something that offloads the CPU when you're just moving data around. So an easy example is,

you know you're reading some kind of MEMS sensor for your variable. So you have an activity tracker. So you don't need to need the accelerometer data every single sample for your CPU at the same time. So you set up your I2C to continuously pull the MEMS sensor. But instead of reading that data in the incoming data register, you set up the DMA to move that data into RAM. And then after a while,

you can tell the CPU to go out and read this entire area in RAM in one go. Another nice example is you want to do a USB to serial bridge, and you set up a DMA pipe from the USB to the serial, and you never have to use the CPU to move this data around. Yeah, because it just happens automatically. It's magic. Memory goes from one spot to another. It's even better than FIFOs because you can use a lot more data, although FIFOs are a nice way to get started on that. But power and DMAs is another thing, right? Because you need to set priorities to the bus access and priorities between

the different DMA events and priorities to the CPU. So efficiency of the DMA and priority levels of the DMA and the CPU to the data bus is another area that you have to tweak if you really want to really want to be the lowest power in the world that's one of those things that is a real step change in efficiency and and your code and being able to do many things at once but

it's very complicated and it's chip dependent. Each one has a different number of DMA engines. Some DMA engines can do certain types of transfers. Some can't do those kinds of transfers. And some can do all kinds of crazy features, two-dimensional and all this great stuff, which is great for screens. But it's not something that somebody who's coming from Arduino is going to be able to just say,

oh, I can make my code more efficient, because now you have to be keeping track of asynchronous events. You have to know, oh, I can make my code more efficient because now you have to be keeping track of asynchronous events. You have to know, oh, is this DMA transfer happening? I can't start another one yet. So you pay for it, but you get a huge benefit. Yeah, and especially if you come from a simple setup and suddenly you even have perhaps

a multi-layer bus matrix. So you have peripheral DMAs, you have the main DMA, and you have a multi-layer data bus. And that's when it starts. There's a reason why in school you have peripheral DMAs, you have the main DMA, and you have a multi-layered data bus. And that's when it starts. There's a reason why in school you have courses on software architecture and layers, right? You need to try to find a way to abstract away some details as you move through your program.

Okay, so if you are going from Arduino to a wearable sort of thing, lower switch compilers so that you can have access. Optimize for speed, right? Not optimize for memory size. Right, because the faster you run something, the longer you can sleep, which means that your floating point library,

just toss it, just toss it. Really, I tell you, toss it. But I need it. No, you don't. They want me to draw round things estimations and lookup tables yeah lookup tables are good uh um what's the next thing yeah the next thing is is checking like big power consumers after like the cpu is addressed with the sleep modes but look at your analog right what speeds do i need to run

at to get the performance I need? Not necessarily what's the fastest the analog peripheral can run. Well, and for most of these processors, for most processors, you can change the clocks. Either your processor clock by changing the PLL

and letting it run slower, but longer, but that's less power because we're talking milliamps or microamps per megahertz. Well, that depends, right? If you're doing something to a peripheral that takes longer, it might not work out in your favor.

There are a lot of things that don't work out in your favor because if you go to sleep at the wrong time, then you wake up immediately and there's this time that it takes to wake up. Yeah, but easier things that's easier to address than going to that detail level is something as simple as if i know i'm just running code i want to for almost all architectures i want to bang through it as fast as i can go to sleep run at your maximum clock speed for your voltage but then if i know i'm doing a transfer with this other board and i'm just waiting for the

uart to finish and i'm at like 115 kilobots or something clock your clock speed down while you're just doing the uart communications because you don't have to overclock to do the uart and then when the uart is finished and you're doing something else clock it back up i think it's a little complicated when you have timekeeping systems like for telling you know 10 milliseconds past now it depends on the clock speed well uh normally well i would recommend not to keep a time base with your processor clock if you have to have a time base have a an asynchronous timer that does that because i mean like an rtc an external rtc well yeah it doesn't have to be external it can be uh like our new atmo smart product most of them

have an internal 32 kilohertz. They actually have two. One that's low power and one that's accurate. So it depends on

how you're Yeah, you laugh. Was that really how marketing meant you to say that? We have one good one and one cheap

one. You never said good. You said low power. I said low power, yeah. But that's the

thing, right? How long do I need to keep the time? If I just need to time 10 milliseconds, use the low power one. Because the accuracy don yeah. But that's the thing, right? How long do I need to keep the time? If I just need to time 10 milliseconds, use the low power one because the accuracy don't hit you that much.

If I want to set my alarm for tomorrow morning, I probably want it to hit at six and not five, right? But again, where all this low power talk ends back to, it's always trade-offs, right? What do I want? Do I want the responsiveness for the wake-up time or do I want the lower sleep mode? Do I want the cold start? Do I want the responsiveness for the wake-up time or do I want the lower sleep mode? Do I want the cold start or do I want to hit the road running?

What other low power tricks? Let's see a classic thing is the same things you do for cold optimalization should I unroll this loop or should I keep it as a loop? Oh yes, that's one of the best parts for me for doing wearables Should I unroll this loop or should I keep it as a loop? Oh, yes. That's one of the best parts for me for doing wearables is having to do that code optimization because there's no good reason to have to unroll loops anymore. Compilers can do this for you.

But if you're trying to squeak out just the last little milliwatt, microwatt, yes, that's when you really... It goes beyond optimize all the way on your compiler into really smart designs. Yeah, and you can do even smaller things, right? Especially if you're coming from the Arduino that you talked about. If you're doing a loop,

always count down in the loop instead of counting up because subtract is one instruction and add these two or three instructions because that's a native instruction for the core. So it's all So you can always, if you're an expert on something, they can find some cycles. And I think if you do your comparison with zero every time,

so if you're counting down to zero instead of up to a number, that can be a more efficient instruction. I think what we're coming to here is that the first 10-20% of power optimization is easy. And after that, you need some sort of dork-like boffin to really get it down to that extra... 10-20%, as I said.

First 10-20% from a standard code is easy. From Arduino, it's actually, you can even half it. Yeah. Pretty straightforward. But that's the thing, right? Arduino is easy of use. It's fast to develop on. It's pretty cheap. It's pretty thing, right? Arduino is easy of use. It's fast to develop on. It's pretty cheap.

It's pretty cheap, yeah. But all vendors have decently good libraries, right? If you use those libraries, you'll get good power consumption. And then you can, of course, try to reduce overhead, optimize variables, all these things. But looking at clocks, dynamic clock scaling, sleep modes, make sure you have a good compiler and that you're not doing some of the at least classical mistakes

in the compiler settings. Yes, right. Moving the optimization bar up to four does mean it's very difficult to debug, but it does make your code a lot faster. Yeah, in GCC, actually, some places, if you don't run automatization, I don't know if they fixed it now,

it's a long time since I did this detail, but it would actually insert no apps, nops, some places. Yeah, which is just very strange. So do you, I have some experience with some RTOSs that actually help with power savings, which my initial interaction with them was, you've got to be kidding. An RTOS is so much overhead.

But it was with the TI RTOS and it integrates well with their chip and understands their power. And it looks ahead to see what it needs to do and how far down it can go. And so I like that. But I was wondering, do you think compilers are going to start looking at that sort of thing? Do you think we'll get an optimization that isn't for space or speed, but for low power, that groups activities together?

Yeah, there is. So I know it's on the roadmap for several vendors. It's things like the profiling, identifying areas to improve. It's trying to do not necessarily a full RTO, when there's things like the profiling, identifying areas to improve. It's trying to do not necessarily a full RTOS, but schedulers that do things. And there's also other things like hashing distances. So power consumption is larger if you jump far in your code compared to jumping short in the flash array.

So if you profile your code and you know how your code normally works, you can program it into the flash in such a way that the jumps are short instead of having long jumps, which will reduce your active mode power consumption. And people are working on profiling this. Is that really going to matter?

I mean, really going to matter? Yeah. All right. I guess if you're calling off to an RTOS, you're calling off to a scheduler or something, even to a math library, you might be doing that several times in a function. Yeah. And the other thing is trying to optimize the cache, right? All new low-power micros have some kind of instruction cache,

so you're reading out multiple addresses from Flash, because Flash access is actually very fast, but also consuming. So if you can fetch the Flash just every once in a while, you get lower power and you don't see the wait states because ideally the wait state will happen while you're executing from the cache. Actually, you know, we should talk about wait states because I'm not sure it's something people realize happen.

If you are executing from external flash and pulling in code, you're waiting a really long time for every instruction. But if you are from internal flash and pulling in code, you're waiting a really long time for every instruction. But if you are from internal flash, you're still waiting usually three or four instructions every time. Cycles. Every cycle. Yeah, if you're running really fast,

that's the worst case. And that's why you put this cache in. So if you put the cache in, you read out multiple sequential addresses. So let's say I want address one, and I'll read out one, two, three, four. And then I'll only have to go and do a new fetch after the third instruction, while I just have one left, or if I have a branch during the first two instructions.

So this way, you'll only have a hit if you have a branch in one of the first two instructions that you have in your buffer. And this sort of pipelining is really, really common with DSP algorithms. Yeah. And sometimes with the bigger processors do this, but... So is four

instructions realistic, or is it usually a lot more? How big are these caches? Does it depend on how many you can... I mean, you don't want to get too many and incur more waitstates. You kind of want to get as don't want to get too many and incur more waitstates. You kind of want to get as many as you can get with the normal amount of waitstates. I'm not sure what you mean,

because the cache is basically just a cost exercise. How big cache do I need versus the benefit I get from it? Because it's gates really close to the CPU. But then the waitstates, again, that's more of a process node issue. So it's how fast can I access a flash? You have to fill the CPU. But then the wait states, again, that's more of a process node issue. So it's how fast can I access a flashing? Right, but you have to fill the cache with a read that requires wait states.

Yeah, but the one read can read multiple addresses. Yeah, that's what I'm saying. So what that multiple is is going to determine how useful your cache is. If you can only get two, then okay, then you get two. Yeah, so let's want to read out, let's say you have an 8-bit controller, right?

So instead of just reading 8 bits on the bus to the flash, you read 32 bits on the bus to the flash, and you translate that to 8-bit in the cache for the next instruction. Very easily described. How big are your caches usually? Normally 4 to 8 instructions. Okay, so really you're trying to defeat the wait states to the flash. And to reduce power consumption, so it's

two benefits. Okay. But we went back to optimization where power and speed are very connected, although keeping the flash on is another power thing as well as a speed thing. Yeah, and you have to remember that doing the caching side of the optimalization, that's a selection that the designer of the chip does. The moment that's made, it's completely transparent to the end developer. He can't do anything to alter that. The only choice I get is to say I want a bigger cache.

Bigger cache, yeah. But you normally see what people do is they put larger caches on their really low power products and then they have them smaller on their general purpose products right which this all brings out another way of reducing your power if you're you know going arduino to wearable sort of thing run from ram yeah well you see the new um so inside all the um smartphones there's some kind of sensor centric algorithm that works with all the sensors does some pre-processing and then sends it to the application processor and the latest generation is there uh like for instance in the new iphone it's flash less so it's a-M4 with a lot of RAM, but it has external flash.

It just moves all the data to RAM and runs everything from RAM. It's funny, that's the way it used to be done, but for other reasons. It used to be that way, because putting flash on the die wasn't as easy as it is now. Keep going forward and then back,

and then forward. The other way to save power on small applications is actually as annoying as spending more money, which is what most people don't want to do. But for cheap design, you can always choose between power, performance, and die size, but you can only choose two. Oh, so if I was willing to have a larger die,

I could have low power and low price. No, high... Oh, sorry. Yeah. You throw price on the boat and you get low power and high performance. There was four. I had four, actually.

Okay, I see. So that's the trade-off that designers are always struggling with, especially when it gets more and more obvious in denser and denser process geometries. So the AVR is used on the Arduinos. If you fully optimize that code, they're at 100 nanoamps with full RAM retention.

And they're in 0.35, so what we today would call an agricultural process node, more or less. It's like really big instruments. you can almost see the transistors and then the more the newer like m0 products from are in the 100 and also 0.1 so 100 nanometer range like i think vendors today are from 0.09 to 0.13. And there you see leakage currents of low-digit microamps normally. So I don't usually care. I mean, as long as the chip fits within whatever the mechanical engineer wants to put it in.

I don't usually care about the chip size, the gate sizes. No. Because as a software engineer, that just doesn't affect me. But you're telling me it actually does because it is a power thing. And as a software engineer, I usually am the one being told to make it lower power. Yeah, so smaller process nodes like rule of thumb gives you higher speed, but also more leakage. And leakage relates to sleep current. Yeah, so there's two different power consumptions in a CMOS micro. It's switching consumption, which is from when you physically switch a gate.

And that's proportional to your switching frequency and the square of your supply voltage. So lower voltage is an easy way to reduce active mode power consumption. That's why 1.8 volts is so popular and and 3.3 is less, and 5 is really not that popular. Exactly. And then the other consumption is what we call leakage, which is the leakage from a gate when it's just powered and not doing anything. And that's because we like to think of transistors as switches. But as many people know, especially people that have done a lot of

embedded design, you can also use a transistor to be a resistor right, and that's kind of what's happening in the off-modes when they're powered, they're still leaking and there's ways to get around this as well on the chip level so

I know people that study not embedded electronics but electro electronics like transistor design they know like okay you can make the you can make the the gates longer which will make them leak less but it will also make them slower so there's and then that's also you see like they're working on fin fat for really really dense process geometries, that's to try to reduce the leakage. So there's all these kind of things. And previously, leakage was only from SRAM. You used to see like, oh, it's big SRAM,

that's why it's leaking so much in sleep mode. And that was always, yeah, SRAM was always more of a power consumer than like Flash for a little while. Yeah, but now we're seeing SRAM and logic gates are leaking, the combination of them. So that's why in the SAM L21 I talked about, our latest Cortex-M Zero ultra-low power product, sleep mode is traditionally just a gateway,

the clock from branches on the clock tree on the die. But in the L21, we're also turning off the power to different branches. We physically power off parts of the die, and that's to remove the leakage current. Okay, so let's talk about this chip. It was nice. 35 microamps per megahertz.

Running core mark, so not the wild one we talked about previously. So that's active mode. Yeah. And 200 nanoamps in sleep mode. Yes, that's the backup mode. So that means you have a handful of registers and your real-time counter. If you want to do the sleep mode where you have all your 40k of SRAM retained, that's about 900 nanoamps.

So that's going to mean that your small battery lasts quite a while. Exactly. And part of the reason we made this device is we need to take battery life from, we talked about smartwatches when I arrived, right? They're days trying to go to weeks. But the real success of Internet of things lies in things talking to things and not consumables talking to consumers which is what they sell today right so for things to talk to things you need to move battery life from weeks and months to years and decades like if you

have some sensors in your house you should probably replace it when you refurbish your kitchen or when you do a reno job that's when you want to change your batteries like a smoke detector can save your life and people forget to change the battery in it if you want iot to succeed you need something with significantly better battery life than a smoke detector has today and then you need to look at absolutely everything, the radios, the micros. And that's what we did. And that's why we made a low power product with large flash and large SRAM.

Because a low power device with 32K of flash doesn't help you for a connected device, right? You won't even have room to start your wireless stack on that. I hit that not too long ago, actually. Yeah, but we're really proud of that product. We spent a lot of time and a lot of engineers really put their sweat and blood and extra hours and weekends into this.

And we did the ULP bench on it, which is, you said I would gloat and i will so yes i believe st was announcing their super low power thing that was like 150 on the ulp benchmark remember lower is worse and higher is better here and you guys were instead off to the side publishing new numbers yes that's the thing i was i've been on the other side of this stick a couple of times it was nice to be on the on the winning side because as a marketing guy you kind of have to you can never rest on your laurels right only that there's a saying from the old intel ceo only the paranoid survive you have to assume that your competitor is at least as intelligent and has a better designers than you so as i was preparing the release i was doing press briefings the

journalists are like oh that's a good number when are you going public with that that's when you know someone else talked to them and gave a different number it's like okay i hope my number is better so then came the st launch like a month before us like like, okay, 120, 130, something like that. Like, really good score. The best that there had been. Yeah. And then, just as we were, like, getting our news release ready, TI launches their new MSP432 with FRAM and a Cortex-M4.

And they were, like, a 160 or something. Yeah, and they were pretty darn pleased. They were pretty darn pleased. And then we came with 185 a week later. And we and we to be honest we went down and had a beer at the bar outside of our office and we were all really happy we were for we were not the ti guy that had one week of uh it was very nice of you not to go have a bar outside the TI offices. It's all friendly competition, right? And to have several big companies now really actively chasing low power, TI, ST, Scilabs, they acquired Energy Micros, right,

to get the foot up there, Atmel. The real beneficiary is the developer and the maker. It gets more lower power products to choose from. Let's see how long we can be number one with the L21 and start working on the next generation, right? Competition is good. Competition is great. Especially when it's for other people.

I was going to say, as much as I hate it some days, overall it's good. From the outside it's great. Yeah. So do these numbers translate to anything? I mean, is it 185 days of life? I have to look up the definition. I think it's like 100.

You can do the workload and the sleep time 185 times in one discharge of the cap you're measuring against or something. I'll have to look up the details. Wow, that is so not useful to how will it work for me. Yeah, but that's the thing. I said when we started talking about it, it's the first traffic sign, right? Am I checking the right product family for this vendor for low power? Because still, ULP only measures the CPU, the bus, flash, SRAM, and sleep mode.

So no I2C, because there are I2C peripherals where I have to pull them. And then there are I2C peripherals where I can get a FIFO or have an onboard driver. And then there are the ones that you can do DMA. And those are all very different power. And that's the next step of ULP bench is to expand

it to something that includes peripherals. But if you put 20 people from 20 different companies in a room and agree, you need to do it. Small building blocks. How were those meetings?

Actually, they were really interesting. I think most people agreed on what we wanted to go. Just how do we want to go there? And one of the big discussion points is, how do we make sure that we don't do something that's only usable for a 32-bit processor, right? We want the MSP430 and the AVR and those that have low power 8051 ones like Scilabs, right?

You want to be able to have a benchmark that can actually be at least partially correct for everything, right? I'm sort of surprised ARM didn't push you to just go for Cortex's only. I mean, clearly they've been trying to win. But that's the thing with a consortium, every vendor has just one vote.

And it's based on people agreeing, right? And I have to say, I was in two of the meetings, it was actually really good. I was surprised how good and how well everyone wanted to reach something that would help the end developer. But the thing is, it's only the first selection point, right? You need to know what are the other things i need to do you mentioned like pulling the i squared c's perhaps having a independent i squared c that can do some work up by itself can save you some sleep wake up modes right oh yeah yeah i'll give an example we have the with the sleepwalking we talked about right let's say a traditional system let's say we're making a thermostat, right?

If I have my PC cabinet that I overclocked a bit too much, if the temperature gets too high, I want to start a fan in addition to my water heating or whatever I made in my garage. So normal setup, real-time clock encounter has a compare interrupt, wakes up the CPU, CPU wakes up the A to D converter, you measure the temperature, A to D completed sends an interrupt to the CPU,

and the CPU says, is it so warm I should turn on the fan, or should I just go into sleep mode? It is pretty inefficient. Yeah, the CPU is smarter than just walking around, kicking people, asking them to do their tasks, right? That's a middle management job, not a CPU job.

So what you can do with stuff like the event system and sleepwalking, you can tell the real-time clock and calendar to work directly with the A to D converter. Every second,

ask the A to D converter to do a conversion. Then the A to D converter can do a window and say, am I above or below, or in the window, however you configure it. They can say, oh, I'm below, I won't even wake up the CPU. And the majority of the time, you don't wake up.

And even the times you do wake up, you go from two interrupts to one interrupt. So you're making your logic a lot smarter, a lot more autonomous. A distributed system of small, low-power parts that can do their jobs without waking up the big power consumer. Exactly. And in some of our parts, we actually even put in small programmable logic blocks. So don't think FPGA. Think simple lookup tables with some combinatorial and sequential logic connected to IO pins and to the interrupt system.

So you can actually do just what you talked about, Christopher. Do some simple analysis and asynchronous block and don't use the CPU for that. So Chris, you had a question earlier and we sprung it on Andreas when you came in, but I wanted to do it on the show. Yeah, so I already asked you this, but... Pretend like you've never heard it before.

I work on some very low-power wearables. And I'm not going to say the client or the products exactly, but the desire is to have, as time goes on and the competition is more fierce, the desire is to have more and more sophisticated things happening on these wearables apart from just reading some sensors and taking that data and giving it to a phone over Bluetooth LE. It seems like there's a massive gap between the kinds of processors that we're using in low-power wearables and the kinds of things that are used on phones. And the phone processors...

Oh, iWatches. Well, that's where I was headed. The phone processors are getting pushed. Apple's taking the phone processors and putting them in their wearables and getting around a day of battery life. But the performance delta between those and the processors in the other wearables

is just huge. It seems like there's a valley between there where, on the one hand, the low-power wearables, you can. It seems like there's a valley between there where on the one hand, the low power wearables, you can use them for a week or two and the high power wearables, you can use them for a day. It doesn't seem like there's a middle ground

where I can get a processor and a system on a chip that might last for three days, but it might give me Apple phone one, you know, 2007 kind of performance yeah what am i what's the problem wow that's a good question i'm glad you asked that why can't i buy that so there are there are some middle grounds right um if you it's like a simple variable like the one i have on my wrist here like the

the fitbit it's called flex or something at least no that's not the flex that's the force yeah force i know these things yeah okay so the fitbit force that's a classical like cortex m style microcontroller everything embedded low power bluetooth radio right we can't say anything about fitbit sorry you can say whatever you want the teardown is on iFixit so there's no secrets um and when you that's get eight days nine days right so the next step for something without increasing the functionality you can go to a month relatively simply go to a lower power CPU go to a latest generation BLE with a lower advertising current. So we talked about this also when you asked it the last time.

So most Bluetooth wearables, they only use Bluetooth when they sync to your phone. But they need to be in the advertising mode so that the phone can see it when you want to sync all the time. And advertising current is... So Atmos has one that we just launched which is like one mic ramp and then i think dialogues at 7 and nordics at 14 or something roughly but that's like the biggest area to improve for everyone is the advertising current on the cpu side though if you want to run with a traditional cortex m3 m4 you're left at the the high end of your performance will be where the

original pebble watch was right that's kind of what you can get you won't get the colors you won't get the animations so you need to step it up one level and then what what i would recommend as the atmel sales guy then right i'd say well the next step up is a Cortex-M7, which is the latest core from ARM, which is a superscalar 300 MHz device with tightly coupled memories. You can actually partition parts of the RAM. I'm going to write this down. Part of the RAM can be allocated to data and instruction and closer to the CPU.

And you can use other parts of the RAM for your graphics library, which is what's starting to hit you, right? Because you need an update frequency on your screen. And then that will take you to a week ish of something, but you still won't have

the graphics speed that you'll have or expect from an Apple One phone. So then the next step up is actually going to an MPU. Then there's several options. You can do like Moto 360 did on their watch. They went with a slightly older cell phone processor.

They used one of the TIO maps that they've used in one of their previous phone platforms to build the Moto 360. Or you can go with something new but not the highest performance because we talked about this on trade-offs power consumption and performance is one of the most frequent trade-offs you do so instead of going for a dual core cortex a9 or something you can go with a traditional or older arm 9 or you can go with a traditional or older ARM9, or you can go with something like a new Cortex-A5, which has the TFT drivers built in.

It supports LPDDR RAM, right, which is important for power consumption here. And it has all those low power features you're used to seeing in micros, like scalable clocks and stuff. And it's still a single course. It's relatively easier to manage What was the A9?

A9 and A5 A5 These things do exist I would look into something like we have a product called SAM A5 D3, D4 and there's coming a lower power version of that as well

lower power and lower that as well. Lower power and lower cost, actually, which is a nice combination, which is coming later this year, which would both be excellent fits for that application. That leads into my next question, which is, what do you have coming in the future that you can tell us about? Or you could just tell us about that BLE chip, because I apparently totally missed it. Yeah, so I'll do it.

Since there are a lot of makers on this podcast, I want to mention that we are doing a lot of new Mega AVRs, which will be interesting for people to know. The AT Megas are the ones that Arduino is usually using. That's the one that Arduino is using. So they're coming out in a family that the part number has a B in the end. But benefits for makers is on the 32-pin packages,

which is used on the Arduino Uno, for instance, we're adding four more I.O. pins, which is huge for many makers. Where are you going to put them? If you look at the Mega 3-to-8, for instance, that's there today. On top. Yeah, on top. Well, we're doing wireless power. No, actually, there's two pins that are ADC channel 6 and 7,

which are not multiplexed with I-O. So we're adding I-O multiplexing on those. And also there's a power pair that's redundant in the later process nodes. So if you look on the east side of the die on that QFN, you'll see that there's like VCC ground, VCC ground, and we're taking one of those pairs away. Oh, more pins. More pins.

More shield incompatibility, but that is a separate rant. You can be compatible because we're not moving anything. Well, yes. I mean, that's a board design, not a chip design. Yeah, you just have to remember to pull the old VCC pin high and the old ground pin low and not the opposite way and you'll be good unless you want to build a radiator but that's better and also it has increased analog accuracy which is good and from a pricing point of view you'll actually see it priced below the old products if you're buying from digikey or rs components or whatever like most makers don't buy from the huge distributors they buy from

something that sells smaller quantities you should see some savings there good then the ble so we have a device called btlc1000 is that a system on a chip that's a processor I get to program for and an RF chip together? It's a system on chip with a Cortex M0 and a transceiver and you can either have it next to a chip with the code on it or you can

buy it with a flash stacked on top of it and then have the stack run on that and have some K left for you to program. But most use cases you'll see the BTLC1000 and the micro next to it. Oh, okay, so they're not on the same die. No, but the benefit here is since we didn't have to

implement a flash technology on the BLE chip, it's just the M0 core and the radio. The total die is about 2x2 square millimeters. Yes, but I still have to lay it out. I like the single chip solutions. But we will come. We also have it in both modules and what we call system in packages,

which will seem... You don't know if it's... For a developer, you don't care if it's monolithic or if it's two dies in a package. Right. So we will come with both a system in package and modules for it. Modules are great if you're building small series.

You don't have to go to FCC and all those things. You just put the module down. But that is, at Mel did, everyone talks about IoT. We believe in it as well. So we have a very good 802.15.4 or like ZigBee, six low-pan style radio offering.

We made two acquisitions over the last couple of years to really give us Wi-Fi, BT, and BLE. We also have Wi-Fi Bluetooth combo chips because in many applications you'll use the Bluetooth two times for one minute to set up

to connect to your access point and then you never use it again afterwards. But you still have to have it. So we've launched lots of those products and the BTLC1000 is also out there now. It is out there? I'm frantically googling as we're talking and doing poorly.

Is it for sale? No, it's not for sale. It's a sampling. It's going to be for sale after the summer. But you can get kits, you can get samples. Can I get a kit? Yeah, if you ask nicely, I'll get you one. People ask me, what wireless technologies do you think

will succeed for IoT? And we've put a lot of money behind where we are going. I think it's going to be 802.15 or sub-gig mesh, BLE, and Wi-Fi. And we're not even trying to do the access point side of the Wi-Fi. Oh, why bother? There's much bigger companies with really excellent products there. We want to do the nodes that connect into the access point. And low power nodes, because those are the cool ones.

And also something that is actually really cool is we support soft access points. So the initial time you can actually, from your phone, connect it on Wi-Fi to the setup, and then it switches to talk. Yeah, that's very nice. We've used that for a couple of products we've worked on. It's nice, and it's sometimes very unintuitive to the new user but it is the cheapest and simplest way if you're just doing Wi-Fi that's the challenge for IoT right? I think the three of us in this room and most of the listeners

are not a reference group for IoT right? we're happy to struggle a little bit to get things working, but my mom needs to get it to work, right? I've still had things that made me feel like an idiot setting them up, and I work on them. So to expect the average consumer to be able to do it is... Forget it. And that's where Philips Hue had their success

with the smart light, right? They built a bridge with one button on it, and they didn't try to make it more complex than that. And that's why they're successful, right? And yet there are lights in this house from Philips that I don't know how to turn on. It's because you haven't installed the app. Yeah, exactly.

You should buy, you know what? There's a really cool product. That's the light switch that you put on the wall for the Philips Hue. And it's powered, well well the thing is i think the box came today actually no no that's something else it's a different wall based wireless thing that's the fan controller oh right but the really great thing about this oh yes yes it's powered by the kinetic energy when you press the on off button so there's no battery inside it the force

that you use when you press the button is enough to power up the radio transceiver and turn on and off the light. It has like a couple of settings. It doesn't go to like 100% bright light. You can actually set it from the app that you need to install. You can set two or three settings. See, that is very cool. We're going to need more Internet of Things devices that are kinetic energy or vibration stores or something. Yeah. I'm looking forward to it. I bought a product from a Kickstarter. I sent them an email yesterday

because I saw they were shipping to the first 290. It turns out they're number 600 and something. So I have to, yeah. But it's called BloomSky. That's kind of like an area or environment surveillance monitor for outside of your house. It has a camera to the sky, measures rain, temperature, everything. It's a small

solar panel on it. That's enough to power the Wi-Fi link to the access point, so you never have to think about switching the batteries. You talked about batteries and very low usage, but Jack Cancel put out a couple of articles that said batteries don't last this long.

What are you talking about? I was about to say you're starting to run into the shelf life of batteries. Yeah, you're getting to the sub-discharge current of the batteries. Let's just cross our fingers that me and my competitors in the microcontroller industry do our part and the battery

chemistry guys follow us up. All right. That's where you have to go. I'll take that, because I can't really say that that's your problem. You just keep making me lower-powered chips, and we'll be fine. Exactly. Worst case, you'll have to switch to a gold cap and just live from that. It'll be dangerous if someone short-circuit it the first week or so, though.

Christopher, do you have any more questions? No, I don't think so. I think I need to go look up all those chips. Yeah, me too. We're going to have a long list for this week's show notes. Yeah, and also, if you want to do low power to the listener, there's lots of resources out there. And actually, most of what you read,

so I will, of course, recommend reading the Atmel app notes for the Atmel products but the principles you use for low power go down to the electrical properties of the transistors so what you learn for one micro in regards to skills as a programmer translates to all of them so don't be afraid that if I read up on this for this product I can't use it for something else and look there's good app notes,

like tips and tricks to reduce your code type app notes. You'll find that from most vendors. Also, most vendors will have some kind of trainings. I know at least we have for all our low power products, which is basically you start with, you get the code and you measure it with a multimeter or a scope and you go through the training

and you enable different sleep modes, different clocking scope, and you go through the training, and you enable different sleep modes, different clocking schemes, and you can see the power savings you do by going through those exercises. That's a really good motivation to try to find the same situations in your code to use it. Yes, and many vendors do that, and you often get to take the hardware home.

So if you are a maker wanting to get free hardware, that's one way. Yep. Can I end with some good news? Yes, yes, please. So Arduino versus Arduino has been going on in the maker community for a while. Oh, I hate that. Yeah, me too. They didn't, yeah.

Anyway, long story short, Mossimo is now working together with Adafruit to build boards in the US, which makes, we'll have Arduino CC boards again. It also means the Arduino Zero with the Atmel Cortex-M Zero Plus on it is going into mass production. Good. Very soon. That is great. Nothing as frustrating as seeing people, especially customers and partners,

struggling on the legal side, but at least now they've found a way to do it and boards are coming short. Massimo announced it at the Maker Faire a couple of weeks ago. Yes. Very cool. That is good news.

Well, I think we are all going to get back to work then. My guest has been Andreas Ireland, Director of Product Marketing at Atmel. Thank you so much for telling us about power things. Okay, thanks for having me. Really enjoyed it. I would like to point out that not only are the data sheets and app notes transferable somewhat across processors,

there is somebody who wrote a book who has a whole chapter about power reduction. I wonder who that is. That would be me. And it's Making Embedded Systems. The coupon on O'Reilly is AUTHD. And you can just email us at the show and I'll give it to you.

Our email is show at embedded.fm or you can hit the contact link on embedded.fm. Thank you, as always, to Christopher for co-hosting, producing, and sending me IMs at inopportune times. Also, thank you to Planet Labs for sponsoring our contest. Don't forget to send them your resume, embeddedfm at planet.com, or also you can send me your satellite ID to enter the contest.

I'm totally looking forward to it. If you like the show and use iTunes, see it's written in my notes. If you like the show and use iTunes, please give us some stars. We hit number 20 in iTunes software how-to a few weeks back and it was all thanks to you. It was also very neat. More reviews will get us there again. Please take a minute if you can. Our final thought for this week. Oh, I have a long one here from Philip K. Dick. Because today we live in a society in which spurious realities are manufactured by the media, by governments, and by big businesses, by religious groups and political groups. So I ask in my writing, what is real? Because unceasingly we are bombarded with pseudo-realities

manufactured by very sophisticated people using very sophisticated electronic mechanisms. I do not trust their motives. I distrust their power. They have a lot of it, and it is an astonishing power. That of creating whole universes, universes of the mind. I ought to know. I do the same thing. That was really long.