OLED display issues, gLCD_SH1106_I2C1, Arduino Nano

[mnfisher]

I think I know why...

Try:

gLCD_SH1106_I2C_Fast.fcpx

(11.92 KiB) Downloaded 778 times

Compiled and running with your sample...

[pmgreene01]

Martin,
Thank you, this works and makes the display much faster than before. The information display that I originally created was updating at 2.5 fps and now it is closer to 15 fps. This is exactly what I needed.

Thank you again for the work you put into this. Your component should replace the standard component.

Phil

[mnfisher]

Hi Phil,

Glad it works okay - it's not quite as flexible as the original component - but the speed up technique is quite simple so
all the 'missing' features could be implemented. The user just has to remember to actually display the image too

MArtin

[pmgreene01]

Hi, it's me again. This display component worked well on my Arduino nano, but I tried it on an ESP32 (Lolin D32 Pro) and it take much longer to execute.

My test program consists of a loop where I set a timer and measure the time from the loop start until I finish all my "print" commands and then a timer around the "display" command.

On the Arduino nano, it takes about 20ms to read the timer and create the output strings and then 30 ms to update the display.

On the ESP32, the first timer takes only 1 msec to execute, but then about 180ms to perform the "print" and update the display.

I attached my two test programs. I am running the same 1mHz I2C rate on both controllers and I looked at my I2C waveforms and optimized the pullup resistors on SDA and SCL.

[mnfisher]

The esp32 version is probably getting wdt issues - try opening a com port using putty or other terminal program..

Or add a delay to the loop - say 100ms and see if improves things..

Martin

[mnfisher]

I got your program running on an esp32 - though I have a wroom board.

So - a couple of issues. It is necessary to use software i2c - hardware mode doesn't have the single byte writes I used in display. I'll have a fiddle and see if I can get it to use transaction_write. This means the i2c might not be running at 1MHz in the sample?

Also - the wdt is indeed kicking in - and this outputs an error message to the USB port every time it overflows.

Martin

[mnfisher]

Try this - seems to get tDisplay down to 13ms (running i2c at 1Mhz and 27ms at 400kHz) (in hardware mode - channel1)

As a fudge - I use an extra 132 byte buffer in Display and copy the data to this (with a leading control byte) - and then do a transaction write..

gLCD_SH1106_I2C_Fast.fcpx

(12.06 KiB) Downloaded 649 times

Martin

[pmgreene01]

I tried both the delay and the updated component. There was no change in the performance.

For the updated component, I just dragged it to my component library folder and replace the file that was there. Is there an additional step?

Thanks

[mnfisher]

Yes - you need to change the i2c channel to channel 1 in properties

The software one is slow!

[pmgreene01]

Yes, that was it. I originally didn't use that channel because it wasn't clear which pins were linked to Channel 1. It lists $PORTA.0 FOR SDA and $PORT0.3 for SCL. These correspond to GPIO0 and GPIO3 on my chip diagram. I found the right pins using a scope after I uploaded the program.

Now it flies at 11msec for the display update. Thanks again for all your help. I am kind of new at this.

Phil