 So, if we go back into our cube project, we want to go into the clock configuration and we need to make sure we maintain our 48 MHz for USB and our 11.29 MHz for our SAI. We want to reduce our system clock here down to 16 MHz. Therefore, we need to have a look at the PLL N and R values so that we can drop this down to 16 MHz. So if we have a look down here, if we reduce that one down to about 16 MHz and then increase that one to a divide by 4 MHz, therefore we get our 16 MHz for our core, but we still have our 48 MHz here and our 11.29 MHz there. So I want to go project and generate code. So again our Cystic warning comes up again so we'll carry on because we know about the Cystic so we'll say yes again and it'll now go and generate my code. So if we now open our IAR project, we can now go into our main.C and you can see the changes that we've just made there where our N is now divide by 16 and our R is now divide by 4. So we can now build the project and we can go project, download and download Active Application for the last time and if we reset our target board. So I'm getting about 4.3 mA in play mode and about 2.1 mA in stop mode which is slightly better than my screen captures here so I'm about 4.2 in run and about 2.1 in stop mode. So therefore again we've said another substantial amount of current consumption compared to what we had previously after the compiler optimization. So if you now look at the difference between the original state up at 17.3 mA in stop mode 17.8 in play mode to what we've got now which is about 2.1 in stop mode and about 4.2 in play mode that is a substantial amount of current consumption we've managed to save on our specific application. Every application will be different but you can tailor the power saving modes for each application as you go through your optimization process when you get near the end of each individual project. So just to prove if we put the tickless mode or if we disable tickless mode again then our current consumptions will go up. Those readings that we have on the screen are approximately to what I get on my multimeter here so you can see that the tickless mode makes a substantial difference mainly to the stop but not as much now to the play mode as it did at the start of the process. The reason why we ran at 80 MHz originally is because we didn't know what type of application audio we'll be processing so if you were doing MP3 or WMA or anything to do with graphic equalization you might need to run the device at 80 MHz but you can seamlessly switch between 16 and 80 MHz easily in the software now so it doesn't take much to actually change the processing speed to match the demands of the application at any part that you need to do so. So what you need to do is analyze your application. You always have an initialization period at the start of every application then chances are you'll be running for so long sleeping for so long and that's how the process will go for up to five years as the picture is showing there on the screen. So each single instruction executed over those five years is a substantial number so if you can find one way of removing only one instruction you start adding one, two or three days of power saving over that five year window so it can start adding up quite nicely every time you play around removing individual instructions as I say every application is different you will have to analyze it based on what you're doing in your particular application. So the whole goal is we need to optimize the code reduce the code therefore you can lower your power consumption due to less instructions being executed. So this was the optimization flow that we've been through so we've gone through all the low power modes so we've dropped it into sleep mode we've used the compiler optimizations switching between size and speed you can optimize as I said file by file if needed rethink the use of the peripherals to my maximize the DMA usage what the cause of sleep if you can do in your application execute from SRAM therefore you can put the main flash to sleep to reduce the size the low level drivers are now available for the STM32 L4 device and that's now in the repository pack for the L4 so you can use low level drivers that will remove lots of excess code that's in the how you will need a very good understanding of the architecture inside the device because the how manages lots of the functionality that you don't really have to so beware of switching to low level drivers and you can always reduce the frequency as and when you can in every application to match the demands of the application. So what we've managed to do there using all those four guiding factors we've managed to maintain the best performance but now at the lowest power consumption thank you very much for joining us on the STM32 L4 workshop we hope you've enjoyed the training and there'll be more trainings to follow thank you.