OLED display issues, gLCD_SH1106_I2C1, Arduino Nano

[mnfisher]

Need to change the 'background_color' to 'backround_col_var' (in cleardisplay2) for the colour to change.. It's monochrome?.

Sorry - don't have the hardware here to test on...

It 'might' need a command to change into 'data' mode.

[mnfisher]

Well - don't I feel silly - I actually clear the display buffer 8 times !

Just reading the data sheet - it might need a control byte to put the display into 'write' mode.
(I've ordered a display from Amazon) - But clear should definitely be much faster than draw rectangle!

[mnfisher]

Take 2:

glcd_mod.fcfx

(182.33 KiB) Downloaded 930 times

This can be much improved by writing the data in a single transaction_write. I hope that multiple 'writeData' macros work though!

[pmgreene01]

I downloaded it, but it didn't clear the entire screen, just the top edge of the display.

I appreciate the the response, but I only clear the display once when I wake up, so that isn't as big an issue for me as the slow update rate on my 3 numeric values. If 2.5Hz is the best I can do, then I need a different approach. I have been using a 1602 display in my prototype, I just thought this OLED screen would look more elegant.

I have had issues with SPI because I am writing to some SPI DAC chips in an interrupt routine, so I get conflicts if I use SPI in the main routine due to the interrupt. With I2C in the main routine, I have had no issue with the interrupts.

[mnfisher]

We can use a similar technique (if it works) to speed up everything.. Draw to the buffer then copy everything to the display in one lump...

[mnfisher]

I think the reaspn display is so slow is that for each pixel multiple bytes must be sent (GotoXY - data for each pixel). My theory is that the display is 'refreshed' by the driver from top left to bottom right - and that if you send try to change too much data this way it takes multiple refreshes to ourput all the data.

By drawing the display and then updating - makes the data transfer snaller and hopefully limits it to a single refresh period.

See viewtopic.php?f=10&t=1569&p=9134&hilit=blood#p9134 - for a demo, albeit using a different display,,,

Martin

[mnfisher]

Okay - so a cold wet windy day. So I had a little go.

The display I got doesn't have a reset pin.

Much quicker (if I say so myself!) - Here drawing a 'rotating' string and a frame count (and also clearing and drawing a box around) each frame.

I tried and failed to get the Print macro from the component to work (to allow fonts) - but it didn't and I ran out of time to fiddle. I used my own print (& font) from my ST7789 component - here called Print2 (the Print macro is still there if anyone can see what I've forgotten to do for GLCD_Base to work) . So no scaling or other niceties.

Looking at the Adafruit code - it looks as though it would be possible to run the i2c at 1MHz for data transfer (display data - not commands) - a SetSpeed macro would be good (maybe) . Also - could just mark section of display as dirty and just redraw that.

Also my Plot isn't quite right - only goes to pixel_width - 3 - strange. But as proof of concept it will do. Initialisation code is also smaller There is no rotation, no simulation, DrawRect/Circle etc either... Sorry. There is DrawLine!

I also couldn't get it to work using TransactionWrite - so use MasterTxByte which might limit it on some MCUs?



Martin

[mnfisher]

Fixed the 'missing column' issue.

Added a DrawRect (filled or outline)
Added a benchmark - Draws a rotating cube (and frame count) and a ''sliding rectangle' over text.

Can I suggest this technique may be better for displays with 'slow' interfaces and a buffer of the display on the MCU. Drawing the entire display out is a lot quicker than the multiple writes needed to draw characters / shapes to the display. It should be easy to add a 'dirty' flag for each of the 8 pages for this display - and similarly a Clear that just clears specified pages. (Possibly a byte with each bit corresponding to a page?)

I did attempt to get the Cube demo to work with the standard component for comparison - but filming the display doesn't seem to work well with my camera (rolling due to the display refreshing) - whichever frame rate I use on the camera...

glcd.fcfx

(90.44 KiB) Downloaded 907 times

Martin

[mnfisher]

Tried 'overclocking' and seems to work at i2c speeds of upto 850000Hz (custom) - 900000Hz doesn't. Other displays might vary on this? There is a noticeable speed increase (particularly on the scrolling string demo - rotating cube requires more calculation time.)

MArtin

[viktor_au]

Hi
I saved this pdf a few years back.
I hope it will be useful.
I am not sure who is the author.