 Now we've had a play around with the software using C and the direct register accessing of the memory locations. We're now going to have a look at what Cubamex and libraries can now bring to your software development. So firstly we're going to have a look at the Cubamex itself, what the tool itself can do. Then we'll have a look at the HAL, so the hardware abstraction layer and give you an overview of what that can do. Then we'll have a look at the low level libraries and then we'll have a see what they can do for you. So these are extra libraries to help you control the STM32 so that you can make your code more portable, more easier to read. So the STM32 Cubamex, so what actually is STM32 Cubamex? The Cubamex is a graphical configuration tool that allows you to configure your chosen STM32 with whichever peripherals you want on the device. It then also lets you set up the start-up conditions for each of those peripherals and it will then generate all your IDE project workspace or framework that you need so you can just launch your software IDE to then start writing your application code itself. As well as the Cubamex tool you will also need one of the library packs. There's ten different library packs now available to cover all the different families we have. We're using the F0 library pack in this particular example as we're using the F0 72 on our target board. So what do you see when you run the Cubamex? So there are four main tabs available to you inside the Cubamex tool. The first tab is the Pinout Wizard. So this is where you assign your chosen peripherals to the physical pins. So this is how you assign and help you with your hardware layouts. So hardware engineers will enjoy this because it means you can play around to make sure that you can bond all the physical peripherals to pins on your chosen package that you want to play with. Once you've got your pinout configured you move to the next tab which is the Clock Tree Wizard. This is where you go and assign the different clock frequencies to your chosen peripherals and to the core. So this is where you can assign the different values to the PLLs to give you your maximum speed if you want to run at maximum speed or some intermediate speed to save power. This is where you assign which clock source you want to use for your Cortex core and also where you assign which clock you want to connect to various periphery that can then wake the device up from sleep modes and stop modes. They don't all have to be the same clock source. You can have multiple clock sources connected to different peripherals. So we have four different clock sources available to internal to external usually and you can assign which ones you want for each peripheral depending on what type of power consumption you need in your whole application. Once you've configured your clocks then you'll move over to the third tab which is the peripherals and middleware wizard. This is where you can add peripherals that don't have any physical pins like the Watchdog, CRC as an example and this is where you can also add some of the middlewares so like USB libraries, Friartos as an example. Once you've added those peripherals you can then click on each of these peripherals that you've either added in the Pinout Wizard or from the peripherals and middleware wizard and then you can give them start-up conditions. So in the case of my screen there I think is a Usart and you can set the board rate, the word length, parity bits, stop bits, etc. Those first three tabs are what you need then to generate your project. I'll come to tab four in a second. When you generate your project it'll then go and look for these library packs so the F0 library pack and it will then pull out all the drivers and libraries for the peripherals that you've selected and then it'll generate your code and your template for your chosen IDE. So those first three tabs are what are needed to generate your code. Tab number four, the power consumption wizard. This is an extra benefit for those of you who want to analyse your current consumption specifically if you're wanting to run from a battery. So in the power consumption wizard you will define a battery source and then you will build up a power profile. So you will decide if you're in run mode, sleep mode and stop mode which peripherals are going to be running in those particular modes? What voltage you're going to be running the device at? What clock speed you're running the device at? There's even a window to add additional current consumptions for some of your periphery components on your target board and then eventually once you've built up your power profile of run modes, sleep modes, stop modes it'll then give you an average current consumption and an expected lifetime of the battery that you have chosen. If the battery is not included in the list then there is a way to edit a custom battery so that you can add your own custom battery to that list and that will help you build up an understanding of what type of battery you need or do I need to drop into low power modes more frequently. The parameters used for this power consumption wizard are from the data sheet so it saves you a lot of time rather than reading through the data sheet trying to find all these different values for run mode, sleep mode, stop mode etc. Also included when you download the library packs for the Cubemax tool, we have something called a repository. This repository is located on your hard disk normally in the default conditions under C drive, users, your account name STM32 cube repository. In this repository we get five subfolders so this is the repository for the F0 which you should have installed for this workshop. Documents is self-explanatory. There's some user manuals and some documents inside there. Drivers contains all the howl and low-layer drivers that we will cover in the coming few slides and the CMSIS drivers. Middlewares will cover add-ons like the FreeRTOS the USB libraries, if this was a graphics-based device it would cover the MWIN graphics libraries, FATFS if you wanted a file system and so on. So there's lots of different middlewares that we automatically include in the cube library packs. The key folder is the projects folder. Inside the projects folder we have a subfolder for each of the different boards available under this library pack. So in this particular library pack for the F0 there will be two eval boards, I think three or four discovery boards and about three or four nuclear boards. Once you select one of those boards there should then be a folder for examples. In these examples you will have an example for the timers, the ADC, the UARTs, all the other peripherals that are included on that particular board with example code on how to set the timer up as PWM, output compare, input capture, time base. So there's lots of different sections of example code using the libraries. There's also another folder at the example level and it's called applications. These are again examples that now these examples or applications are using elements of the middlewares. So there will be applications to show you how to use the free RTOS, how to use the USB in virtual comport in HID, mass storage device. So there's lots of different sections of code here that are free for you to use to play with. They should be ready made to run as an individual standalone project so that you can get up and running with the libraries, be it the how or the low layers. Not all of the examples are available in low layer by the way but it gets you up and running with our software and there are no license constraints for you recycling any of these examples that we have in this package. Finally we have utilities. Utilities contain some extra elements like fonts, extra add-on files that are needed for some of the USB demos and things like that that need to be on external memory sticks, things like that. But projects is a key one. It's worth going to see what's in there to help you understand how some of the configuration is used to configure the timers and the ADC, et cetera, et cetera. These examples are completely independent of the Cubamex frameworks. So these are just standalone examples. They've not been generated from the Cubamex graphical interface so there will be no graphical interface file to go with them. They're just purely written as C examples for you. The documentation. So for the different library packs, the most useful document is the description of the how and low layer drivers. So that particular user manual is for the L0, apologies not the F0 there. You can tell by the size that it's a fairly large document. So it's about over a thousand pages long. And it details every different how and low layer library command and all the different elements that need to make up that particular library command. So that is a very, very useful document to understand the how and low layer drivers. The rest of the other ones are very good application, getting started for how to use a free RTOS, how to use the FATFS, how to use the touch sensing libraries and so on. There's lots of different user manuals available for the Cube and the libraries that the Cube provides. So let's now take a look at these libraries. So we'll start with the how libraries, which are the hardware abstraction layer. So these are the higher level libraries. And these how drivers or how libraries sit quite away above the silicon, which is the red dotted line down at the bottom of the screen. So they're quite a distance away. The reason they've been produced that far from the silicon is so that any code you write using how drivers, it will mean that your code is portable. So they've been specifically written to be higher from the silicon so that you can move from different silicon to silicon. So you can move from an L0 device to an F4 device as an example. There's also lots of automation inside these how libraries as well. So there's lots of different extra features included inside these how libraries. So they've been designed for high portability. They've been designed to cover every single peripheral. And they've got lots of extra functions in there that are related to the specific peripherals that are being controlled below. The how libraries also hide some of this complexity because they automate some tasks. They will hide some of the complexity of how each individual peripheral is being used on each individual piece of silicon. And by default, the Cubemax tool will generate for the how libraries. The structure of the how libraries or the command structure of the how libraries is you will have a return value if it's appropriate. Then every command will start HAL. To signify you want to use the how libraries. LL if you want to use low layer libraries. Then it'll be underscore PPP. PPP is the peripheral name. So Tim, ADC, UART, etc. Then it'll be underscore operation, which will be start or stop. And then underscore mode, which will be one of our software application mode. So polling, interrupt and DMA that we saw earlier on. Some libraries will be PPP brackets EX. EX means that is an extended function which is unique to that particular family. So that means that that feature is not on every SDM32, but might be on most of the SDM52s or it might just be on this one particular family. So you will have to look to see what some of these extended features are. And these will be the unique features that are usually local to each peripheral family. So if it is an EX function, then your portability of code will depend on if that function is available in the device that you're porting to. The low layer libraries sit a lot closer to the silicon. As you can see, they come all the way down to this dotted red line at the bottom, which means they are more local to the silicon itself. In the unitary functions, you have got atomic register access. So you can do exactly the same as what you did in the previous hands-on where you can write direct to each individual registers. They also provide a lower memory footprint because they're a lot closer to the silicon itself. They're not designed to be portable. They are a lot smaller in physical size. So we have two functions of the low layer libraries. We have the initialization functions, which contain an additional C file, which is optional. You don't have to use this initialization function. Or you can use the unitary functions, which are the equivalent of using the direct register access or atomic operations. So you have the option with the low layer libraries, which of the two features you actually use depending on what you want to do, if you want to make your code portable or if you want to make it as small and compact as possible. Even with the unitary functions, you have three different options available to you. You can have the really low level, which is the basic registers for read and write. You can use the mid-level, where you've got more of the atomic operations, where the descriptions are a bit more meaningful. Or you can go for the highest level, where you can actually read each line of code and have a rough idea of what is going on inside that particular line of code. All of these options are covered by .h's. So there's no extra C files being added to your code, which is why it's the most compact memory format. It's down to now your personal coding preferences of how you want to write code. If you want to keep it small and short and brief and write your own comments, then you can use low level. If you're getting to the methodology of using the high levels, then it means you don't have to write as many comments yourself. So you can actually see what's going on within the code itself. If you choose to use the initialization functions, which is what the Cubemax tool does when you select low layer libraries, then all you gain is an extra C structure. So it's not a great deal of the code. It's just this one extra C structure which is there for your initialization. So this is what the Cubemax tool does when you configure each of those peripherals with the board rates, start, bit, stop, bit, etc. In the case of our screenshot here, it's the configuration of GPIO pins. And that is the only extra bit of C code that's added to your projects. So there's not much added to the size of your project by using the initialized functions of the low layer drivers. The structure of the commands is exactly the same format as the how. So you have a return value if there is one. Then rather than HAL, you've now got LL. Then you've got your PPP. There's no extended functions because low layer libraries are targeting this device family only. And then your operation is a bit more descriptive rather than just start and stop. It's now set PIM mode, Enable DMA Request. So it's a bit more descriptive now, your actual operation of what you're doing. The low layer libraries and the how libraries can be mixed. So you can select certain peripherals to be on HAL, certain peripherals to be on low layer. So you have that flexibility within the project. Not every peripheral is supported by the low layers. So there are certain peripherals, things like USB, Ethernet that are not supported by the low layer. Because normally you've got a big software stack that sits beyond it. So you don't get the benefits of being a low layer driver. So it makes no difference. We do say low layer drivers are intended for expert mode. That is questionable because it depends on what type of background you've come from, what type of software knowledge you have. You might want to read the data sheet from cover to cover, read the reference manual from cover to cover before you start playing with a device because that's how you've had to do it in 8-bit world. We say expert mode here because the HAL drivers are written so that you don't need to know all the ins and outs of the peripherals. You just send the commands in. The HAL libraries will manage the complexity of each individual peripheral. The low layer drivers do not have that luxury. You have to know all the ins and outs of each peripheral before you can use them. So it depends on what you've done in the past and how you approach the specific project that you're using the low layer libraries for. And as I've highlighted, HAL drivers are completely the opposite to low layer. They're distant from the silicon. They're designed to be automatic, add extra features. Whereas low layer drivers are more dedicated to the silicon and you need to know how that particular feature works on the device. So, summarise. Portability. HAL was designed for portability. Low layer libraries were not. Memory optimisation is the other way around. Low layers libraries have been designed for optimised memory. The HAL layer libraries, because of the portability, are a bit fatter. Ease of use. That's again, it's a questionable statement. Once you get used to either of those libraries, they're probably just as easy to use. Readability. The HAL libraries are quite easy to read and understand what that particular line of code is doing. Depending on which version of the low layer libraries you're using will depend on how descriptive the line of code is actually going to say. And hardware coverage. So the HAL libraries cover every single peripheral. The low libraries don't always cover all the peripherals on the SDM32. So what have we learnt? So you've got an understanding now of Cubimax. You're going to have a play with this in the next section. So I'll give you more of a guided tour in the next chapter as well. You've seen the hardware abstract layer, the HAL. So the high level libraries that we have. And the low level libraries you've had an introduction to. You're going to get that in the hands-on, which is coming after this presentation.