Maybe I’m doing things wrong, but I wonder if people have found the RP2040 to work better than STM32’s? Just some of the peculiarities I’ve noticed:
- I couldn’t quite get an oled display working with an STM32L432KC, and resorted to bit-banging
- although the L432 has NSSP for SPI, the STM32F411 does not. The NSSP setting enables the clock pin to high between each byte/word of transmission. Some devices require this. So you may not be able to use SPI DMA (depending on device). The RP2040 just works.
- I could get my oled to work on the STM32 using libopencm3. It works OK until I enable systick. I did some LED flashing using systick, and the mcu used to freeze, or something, after about 20 minutes. I’m not sure about the precise nature of the problem. I don’t think there’s any data races introduced, so that couldn’t be the cause of the problem. I tried using a timer instead, with similar results. I then simplified the systick/timer to only increment a tick count. The MCU then froze after approx 2h30m. Bizarre. The same project on my RP2040 is still going, even after 3h30m. A lot of the code is shared.
I must presume that I’ve been doing something wrong somewhere. I mean, the chips can’t be as unreliable as I’m making out, right?
Update 2022-05-11: I rewrote my oled/ds3231 code using the stm32 hal. My libraries remained the same, I just used the HAL to initialise the I2C and wrote a simple 2-line replacement for libopencm3’s i2c_transfer7() function. The MCU is still working after 2h54m. Hmm, I wonder what’s going on here. A bug in my code, perhaps, but basically nothing changed in it. Perhaps a bug in the way libopencm3 calls the standard library? Some subtle software or hardware bug in libopencm3 itself? It’s difficult to know what to say about that.
Mark Carter's blog 