I will be exclusively working at the HAL level (the stm32f4xx_hal in particular).
#Nucleo f401re led blink series#
Reflecting on my experience, in this post, and the upcoming series of posts, I will be working with the STM32F401 microcontroller to present and walk through examples for different peripherals. It used to happen that for certain methods where proper descriptions were missing, I would either find myself experimenting to understand or looked at similar HALs to figure out how they work. Secondly, the HAL documentation was hard to navigate at first, and in some cases, it was not as complete as I would have expected. Through leveraging the language features, the HAL is constructed in a way that incorporates techniques to ensure the safe operation of embedded devices. Firstly, the HAL probably is more involved in using certain features of Rust like generics and traits. After some time and work with the HAL, I feel that there were two main contributors to that experience. Interestingly enough, when I set out to work with embedded Rust, I found that dealing with the PAC was easier for me to achieve what I want. Board crates, although sit at the highest layer, are more specific to a particular development board. The HAL, on the other hand, probably allows for less control over fine details in a particular microcontroller but is much more portable. The PAC is much closer to the register level and allows for much control but at the cost of portability. Finally, at the highest layer sits the board layer crate (more detail in the Embedded Rust Book). On top of the PAC sits the hardware abstraction layer (HAL), accessed via the HAL crate. Peripheral access layer features can be accessed via the peripheral access crate (PAC). While doing nothing but flashing a led that is of course OK, but typically one would want the processor to do "other things" and if that is the case the actual LED frequency will be even more unpredictable.In embedded development with Rust, the layers in which an individual can program a microcontroller include the peripheral access layer. While that is running, the processor is tied up in doing "nothing". Sure, it will only be "off" by a few micro seconds, but it will be off! In reality, this approach has at least two problems.įirst of all, the call of both HAL_GPIO_TogglePin and HAL_Delay are not single instructions, so the actual time spend in the loop will be "a tiny bit" longer than 500 ms resulting in a frequency which is slightly below the intended 1 Hz. I made the claim earlier that this approach was generally misguided and that is part of the problem. The keyword in the above description is "approximately". The result will be approximately 1 blinks per second: It will toggle the led, not caring what the previous state was, and then wait for 500 ms. The approach is simple and easily understood. Using Stm32CubeIde and it's HAL libraries, the main loop will look something like: In this approach, the led is simply toggled in the main loop of the program, with an appropriate delay. This approach, while quite misguided, is often seen in examples, particularly Arduino based ones. This is the frequency at which the timers will operate (in this case 72 MHz - remember this value for later examples).
Also important to notice is the value of the APB1 Timer Clocks. The important values here is the value of the external crystal (in this case 8 MHz), the value of HCLK, which is the frequency the processor will run at. Second step is to configure the CPU to enable the external crystal:įinal step is to configure the various clocks:
#Nucleo f401re led blink serial#
First step I configure the Serial Wire debug (including the trace): When starting a new project in Stm32CubeIde, I generally go through some common settings. Stm32CubeMx is used to "configure" the processor. These are discussed in the following sections.įor these examples, I will be using ST's Stm32CubeIde, which includes Stm32CubeMx. Using the STM32 HAL from ST there are a number of different ways to blink a LED.
0 kommentar(er)
