SSD1306 I2C with STM32F030C8T6TR - slowing down the controller

[Sbag]

I am using the above library to display simple text msg on the OLED display. It works. 

However the controller slows down - while(1) loop works as if delay(5000) is implemented. At first the internal HSI clock running at 8Mhz was being used. Thinking that increasing the clock speed might help , activated the PLL so as to increase the clock to 48MHZ. But still the SSD1306 somehow pulls down the speed. 

If the code for SSD1306 are commented out , rest of the operation runs faster. The controller is used to read only 2 ADC channels with DMA, which is not much of a task. Nothing else. 

 

Has anyone encountered such an issue ? What could be the likely issue ? 

[Andrew Neil]

---

@Sbag wrote:

I am using the above library  

---

What library? You haven't mentioned a library.

 

---

@Sbag wrote:

the OLED display. 

---

What OLED display?

Please review: How to write your question to maximize your chances to find a solution

[Tesla DeLorean]

With the SSD1306 probably 1" diagonal white ones via I2C

You shouldn't need to continuously paint the screen. The display has it's own frame buffer. Check how much you need to change.

Check I2C comms speed, hard delays you might have in that. That you don't repeatedly reinitalize or resend entire screen. 

[Sbag]

Yes it is 128X64 white OLED display. 

There is nothing to set. The height and width is already defined in the header file 

 

In the main() 

it only need to initialized  ssd1306.init(&I2c-handle)

 

in the while(1) loop

 

it only requires setCursor() , .writeString () and .after sending all the data ( only three lines )  finally updateScreen()

what I found is with each use of ssd1306 setcursor or writestring, the controller goes on slowing even before sending the updatescreen command. 

Could be it be due to controller not having enough memory ? . 

 

 

[ahsrabrifat]

You can try this library.

https://github.com/afiskon/stm32-ssd1306

[Sbag]

Thank you. I shall check. 

[TDK]

> Could be it be due to controller not having enough memory ?

No.

The program is slow because you are updating 128x64 pixels over I2C, apparently every loop cycle. That takes a while. Find a way to update less or optimize the code or increase bus speed.

Debug the code, step through and understand where it's spending most of its time, and why.

[Sbag]

I am not sure. 

I did the same program in ESP32 and it runs like hell. I had to slow it down enough to read the display. 

But on STM32F030C8T6, even adding a single line for ssd1306 slows it down. The code has hardly 4 lines of simple text to display. and it seems like adding a delay of 4000 to 5000. 

I even tested changing the I2C speed to Fast mode. It doesn't help either. Fast Mode Plus doesn't work. 

I changed the display to LCD and it is fine. 

Sometime back , I had tested the same library on BluePill and it worked fine. But on this controller... 8k vs 32k I wonder... 

I shall do some more tests or change the library as suggested by ahsrabrifat 

Thank you for responding. 

[Tesla DeLorean]

>>The code has hardly 4 lines of simple text to display. 

Yeah, that's YOUR code, the problem is apparently in the library code you've chosen to use.

You haven't provided the project or the library. Present the problem in a way people, other than you, might be able to understand what you've actually built and replicate the software build.

Likely either your I2C settings, or some delay that's expecting micro-seconds, and delivering milli-seconds.

>>But on this controller... 8k vs 32k I wonder... 

The problem you're complaining about is in the TIME domain, not that the code fits in memory or not. The display doesn't care.