Thanks for reading! To your comment, there has probably been a change in the interface, however, it makes sense. Resetting the interrupt enable is not unusual.

Your welcome! If you check the pin name column in table 8 in the datasheet I shared there should be all the pins listed there. There also should be a column titled “alternate functions”. These are all the functions that each pin supports. If you look up the PA9 for example, you’ll see that TIM1_CH2 is one of the functions it supports. You’ll need to find the same table for the F3 device.

juebanlin I have created a full STM32 strictly hal-based series in the past that you can find here . There is also a series using the STM32 with embassy. The closest example to what you are looking for is probably the ultrasonic measurement with timers. Regarding more examples, that is always a goal, but time is always tight, and I am always trying my best to generate more. As for the FG input, I don't have such hardware readily available but the concept of how to measure is largely similar to examples I already developed. For example, the earlier example I shared about the squarewave generator input connected the ESP, that would be exactly the same logic you would utilize to measure the frequency of an FG signal.

Hello juebanlin and thanks for reading. There are several ways to achieve that. I Ideally, I would use something like input capture mode in a timer. However, the last I used the STM HALs most, if not all, did not support input capture mode yet. I figure you can implement using the PAC, but that might be a bit of a hassle. Another way around it is by using GPIO similar to something in this post. Although using ESP, it should map more or less in a similar manner to the STM. Also, you can achieve the same using GPIO interrupts if you want to avoid polling. The ISR would instead inform you that the event happened.

Thanks for pointing it out. I actually haven't tested for that case, however, it seems that dividing by zero in floating point (f32 or f64) does not panic in Rust. Instead, it results in a NaN (Not a Number) and continues operation. Here's where I found some insight: https://users.rust-lang.org/t/how-should-i-handle-f64-division-by-zero-panic-elegantly/32485 https://internals.rust-lang.org/t/should-x-0-be-an-error/2252

Hello, rain silent I am glad you liked it. One thing I wanted to do in the past related to your request is input capture to measure the frequency of external clock sources. It turns out at the time that the feature was not yet supported in various STM32 HALs. Nevertheless, it can still be done with software and GPIO. A very similar post you might find useful is the ultrasonic distance measurement, as it achieves something quite similar. Here is the link: https://apollolabsblog.hashnode.dev/stm32f4-embedded-rust-at-the-hal-timer-ultrasonic-distance-measurement

Thanks Christian Foucher , I will adjust this. It's an artifact left over as I was experimenting with floating point before. I decided to avoid floating point operations but forgot to adjust this.

Thank you for your contribution Christian Foucher ! Actually, yes, given all the different types in embedded and the singleton pattern, setting up function parameters can take a while to digestive. This is why I try to avoid them in beginner tutorials. Maybe it's a topic for a separate blog post. I revised your refactor and yes, I am printing the value regardless of the update. I will update the post and repo to incorporate this as an optimization.

Thank you! I hope that you’ll find it better. Rust has a steeper curve for sure, especially in embedded, though I feel it’s getting better as the ecosystem, including educational material, is growing.

Thank you for reading Mariusz Białończyk ! Your doubt is in its place. Since I hooked up the sensor to 5V power then the TTL output levels of the ECHO pin will reach 5V. While pins typically have internal protection, this would still expose them to potential damage. No need to mention, it didn't matter in the simulation. As such, there are two options to address this; either a voltage divider like you indicated to shift the 5V range to a 3.3V range or use a 3.3V compatible device. However, for the latter, I think the accuracy is not as good as the 5V sensors. I adjusted the diagram in Wokwi to include the voltage divider.