cancel
Showing results for 
Search instead for 
Did you mean: 

How can i reduce the OLED display clear time?

Wju.1
Associate II

I have use STM32F0 microcontroller.

I try to integrate the stm32 with OLED(SSD1306:128*64).

It's an I2C communication. The issue is while clearing the display takes some seconds(like 2sec.).

How can I make it faster?

I have attached the issue portion image.

Is there any way to solve the issue?

I think the issue in I2C_TransferHandling function, because its repeatedly call in loop. But no idea about how to solve this issue.

0693W00000AOJNDQA5.png 

 void Display_Clear(void)
 {
  int i = 0;
 
  Write_inst_oled(SSD1306_SET_COLUMN_ADDR);
  Write_inst_oled(0);
  Write_inst_oled(127);
 
  Write_inst_oled(SSD1306_SET_PAGE_ADDR);
  Write_inst_oled(0);
  Write_inst_oled(7);
 
  I2C_TransferHandling(I2C1,(SlaveAddr<<1),1, I2C_Reload_Mode, I2C_Generate_Start_Write);
  while(I2C_GetFlagStatus(I2C1, I2C_FLAG_TXIS) == RESET);
  Display_SendByte(SSD1306_DATA_CONTINUE);
  delay_ms(1);
 
  for (i = 0; i < 1024; i++)  // Write Zeros to clear the display
  {
      I2C_TransferHandling(I2C1,0, 1, I2C_Reload_Mode, I2C_No_StartStop);
      while(I2C_GetFlagStatus(I2C1, I2C_FLAG_TXIS) == RESET);
      Display_SendByte(0);
      delay_ms(1);
  }
    
  I2C_TransferHandling(I2C1, (SlaveAddr<<1), 0, I2C_SoftEnd_Mode, I2C_Generate_Start_Write);
    
  Write_inst_oled(SSD1306_SET_COLUMN_ADDR);
  Write_inst_oled(0);
  Write_inst_oled(127);
 
  Write_inst_oled(SSD1306_SET_PAGE_ADDR);
  Write_inst_oled(0);
  Write_inst_oled(7);
 
}

7 REPLIES 7

All those milli second delays add up.

I'm using SSD1306 and 1309 displays​ more efficiently.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Wju.1
Associate II

Without delay Display_SendByte function not work.

Something is very wrong with your implementation, I'm writing entire lines to the display using HAL_I2C_Mem_Write()'s with no delays.

Perhaps you can use a delay with finer granularity, or do some bus analysis to see why it is failing. How fast are you clocking the I2C?

1024 ms is over a second.. want it to clear quicker, you're going to need to delay less.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Wju.1
Associate II

0693W00000AOMllQAH.png Timing value is default load as 0x00210507.

After change this timing value, there are no improvements.

0693W00000AOMoQQAX.png

>>After change this timing value, there are no improvements.

I'd expect the duration of 1ms to remain roughly the same.

Are you clocking the APB here at 8 MHz?

Running an STM32L0 here at 32 MHz, with a 400 KHz I2C. Not sure what the display has for pull-ups, guessing 4K7 from the schematics.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Wju.1
Associate II

In STM32F0 I2C clock derived from 8Mhz(HSI) by default.

Could you can suggest some solutions to overcome the current scenario.

Is there any problem in I2C_TransferHandling function?

So you need to determine a) why you need these delays, and b) get them into the sub-ms range

As I recall the display has some reset/initialization time, but not to write the display buffer. Should be able to update that around 39-40 Hz. My application I'm probably updating the screen a couple of times per second.

Get a scope or bus analyzer and try and figure out why you need these huge delays for everything. Refactor the code to use more efficient I2C transaction modes.

Check what the rise/fall times actually look like for the pins, and the pull-ups used. I'd probably lean toward 2K7 or 1K5

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..