Arduino for STM32

Greetings,

I'm posting this in case it might be useful to somebody - how to avoid the "mistakes" I made.

Years ago I got a few STM32F407VET6 "Black boards", which are as described here:

https://os.mbed.com/users/hudakz/code/STM32F407VET6_Hello/shortlog/

I have not used them for any serious ...

some of the features of the USARTs (from the reference manual of your G431, a very interesting document ! ) :
• Separate enable bits for transmitter and receiver
...


I don't know anything specific about G431, but there are many hardware features that STM32DUINO does not support, even for F103 ...

I've seen that there are STM32F411-based boards https://fr.aliexpress.com/item/1005006127461676.html?spm=a2g0o.productlist.main.1.29b3UriPUriPFg&algo_pvid=6335e4ed-da8e-47b4-9bd1-d188e2c38ab2&algo_exp_id=6335e4ed-da8e-47b4-9bd1-d188e2c38ab2-0&pdp_npi=4%40dis%21EUR%215.88%210.99%21%21%2145.34%217 ...

If you have a spare ADC capable GPIO, maybe you could connect VBAT to that and then periodically enable the pull-down (to give it some load) and then read the voltage.

This is not something I have done though.

For some other processors GPIO pins may not have symmetrical output capability. For example, they might be able to sink more current than they can source, and that could influence the way you might connect a LED to them.

However for the STM32 processors that I have used, the datasheets indicate ...

All white is an indication that the pulse durations are too long, resulting in every bit being interpreted as “1”. I looked at the Adafruit library some years ago, and the timing was a bit out, but the pulses were actually on the short side, which could cause the opposite problem of all LEDs off. In ...

Try

Dannyf, I missed your updates on the second page previously.

It is a very different situation if you can avoid the STM32DUINO and maybe HAL code as well, but this could be easier said than done depending on what other parts of STM32DUINO need to be used in the final project. Maybe your "cut down ...

for around 5µs

that's too long. your ISR overhead will be 20 ticks. Hard to imagine this thing goes over 100 ticks end-to-end. I will do some testing later on as well.


I would be interested to see what you find. I've done tests like that before, and the result is not out of line with what I ...

I would approach the problem this way.

1. Set up an input capture on falling edge. No interrupt.
2. Set up one input capture on rising edge, interrupt enabled. In this isr, you will need to calculate the timer count elapsed between two isr invocations, and the difference between the count ...