Arduino for STM32

HI All.
I'm using the U8G2 library to run a little SH1106 screen on my STM32L07 variant board.
When I turn on the board, There's a boot screen to let some internals load and some values settle.
However, before the boot logo appears on the screen, there's a very uncomfortable 2.1s delay.
Peppering the code with Serial.println(millis()); shows that the culprit is U8G2.begin();

I've set up hardware I2C1 on PA9 and PA10 and it appears to be working fine.
By setting the U8G2 screen constructor to software I2C, U8G2.begin() completes in a relatively zippy 1.3s (but obviously causes the screen update to slow to a crawl). These both seem like very long times to me, and it seems strange that Hardware I2C would take longer to load than software I2C.

I want to try and figure out if I misconfigured something? Maybe in the configuration of my variant? Does it take similar amounts of time for you guys? Has anyone come up against a problem like this before with slow begin on U8G2 or maybe some other I2c communication?

Many thanks,

My guess is that when using hardware SPI, the library configures more structures, perhaps an array to mimic the screen pixels.

Software SPI is generally a byte transfer (transaction) to the screen repeated to fulfill the update. Hardware SPI generally is implemented on a memory transfer. The memory transfer on the STM32F1xx can be further enhanced to utilize DMA for ultra-fast performance.

Thing about libraries, authors often try and cover a large hardware configuration and make general assumptions which allow the library to be incorporated, but does not necessarily enhance performance. Great for quick prototyping, not so good for production.

Madias explains more in this thread from the old forum.
I recommend you hunt for and try alternate display libraries.

Ray

If you used the STM32 Core, for STM32 L0 and some other series,
it is required to compute the I2C timing to get the best one depending of the system clock config. It is computed each time you start your board and depending of the MCU you used can take some times (maybe the one you seen).
Anyway it is possible to define those timings to avoid to recompute them at each reboot:
https://github.com/stm32duino/wiki/wiki ... i2c-timing

Wow. What a pull. Outstanding advice.
back down to 1.3s with the i2c speed defined in.
Perfect. Thank you.

It makes sense to that the rest is in the library loading (as you said Ray), but the load time improved as it is is much less obtrusive.
Many thanks fpiSTM. As usual.