To set up the system clocks we need to first promote the RCC struct from the PAC and constrain it using the constrain() method (more detail on the constrain method here) to give use access to the cfgr struct. The stm32f4xx_hal crate to import the STMicro STM32F4 series microcontrollers device hardware abstractions on top of the peripheral access API.Įnter fullscreen mode Exit fullscreen modeĢ️⃣ Configure the system clocks: The system clocks need to be configured as they are needed in setting up the timer peripheral.The panic_halt crate to define the panicking behavior to halt on panic.The fugit crate for the handling of time in embedded systems.The cortex_m_rt crate for startup code and minimal runtime for Cortex-M microcontrollers.In this implementation, three crates are required as follows: Let's now jump into implementing this algorithm. It's worth noting that interrupts are not affected by blocking delays unless preemption is disabled. Again, if we were using interrupts this all wouldn't matter as we would have an interrupt service routine that would inform us that the button got pressed. This means that for a polling approach like ours where we need to check on the button being pressed while time passes, a non-blocking approach is required. The code will keep returning to check (poll) the timer if the delay ended. Non-blocking on the other hand means allowing operations to resume and the controller can do other things meanwhile. Blocking means that the controller will sit idle (operations blocked) until the delay finishes. Let's incorporate these adjustments into the flow chart to see how it would look like now.ĭelay methods come in two forms, blocking and non-blocking. Here instead of updating a loop variable to check if it had reached the maximum value I instead poll a timer/counter and check if it reached the desired delay value. The application in this post adopts the same algorithmic approach as my previous post, however, with minor modifications. User button connected to pin PC13 on the microcontroller.LED is connected to pin PA5 on the microcontroller.On-board connections will be utilized and the include the following: There will be no need for external connections. Note that if the code on the git repo is slightly different then it means that it was modified to enhance the code quality or accommodate any HAL/Rust updates. Familiarity with the basic template for creating embedded applications in Rust.Īll the code presented in this post in addition to instructions for the environment and toolchain setup are available on the apollolabsdev Nucleo-F401RE git repo. To understand the content of this post, you need the following: Again, I will not be using interrupts and instead would be polling a timer/counter for the elapsed time. This will make the delay more deterministic and scalable among different platforms. In this post, I will be enhancing the previous code by instead leveraging a timer/counter peripheral to manage the delay. It was mentioned as well that using software is not ideal to create delays as it does not scale and hardware methods (ex. Even delay was created algorithmically, meaning that there was a piece of code (loop) that generated the needed delay. In the previous post, the focus was on the GPIO peripheral and I had controlled the rate of flashing of an LED connected to a GPIO output using a button connected to a GPIO input. In this post, I will enhance the GPIO button-controlled blinking project in my previous post by using a timer/counter peripheral instead. If you liked this post, please make sure you subscribe to the newsletter here to stay informed about new blog posts. Please be aware that certain concepts in newer posts could depend on concepts in prior posts. This blog post is the second one of a multi-part series of posts where I explore various peripherals in the STM32F401RE microcontroller using embedded Rust at the HAL level.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |