Waveshare 1.5" OLED grayscale display

MagIO2

Not so much flesh yet, but I am happy to be back in Propeller land. A lot to catch up with, I see.

Still, starting with the Propellers is so easy when Objects are available. For this display I used the existing JonnyMac's ez SPI driver - lets start ez ;o). Just a little glue code around because the display has a SPI interface with D/#C line.

Tweaking the grayscale table and converting an image took more time than the rest.

So, to learn the next lessons I'll probably create a specific object for driving the display. Changing the full screen take somewhat below half a sec. Driven correctly this device should be able to show 90 frames per sec.

But one question I have:
In the main loop I initialize the images array. If I comment those out, the display shows rubbish and I don't understand why. In the DAT block the images array is initialized with the same @ operator. Why does that make a difference? For me it would be logical if those 2 ways produce the same result.

MagIO2

OK ... more than one month passed by ... I am still not where I want to be with the P2 and this driver - even if I have some code which runs a loop of several tests. Drawing pixels, text, lines, boxes, circles, images. ( Is it possible to upload a 120MB video? )

But to be honest I expected this to happen. What do I mean?
Well ... the P2 is a whole new beast. It really does not make sense to 'waste' a COG for things like drawing graphics or sending the pixels to the display. At least not in usual uC scenarios where you want a human to see and recognize some changing numbers or some graphs, maybe having some simple animations.
In the post above I stated that the display should be good for 90 fps ... well ... I think something was wrong in my calculations. Close to it's limits, the display is ready to receive the data at a rate which would equal 180 fps. So, even if you want to show some animated things, 30 fps would be enough, which means that only 1/6th of the compute power is needed to send the screen to the display.
And I did not figure out yet, how to make use of the streamers -which is next on my todo-list- but that means even more free-time for other things.

So, currently the route I go is:
1. Have a display buffer for those kind of small displays. The one I have does not allow reading back it's display RAM. But having access to the data already written would allow more sophisticated functions like blending pixels for transparent overlays.
2. Sending the screen buffer to the display is triggered by the code and there should also be some kind of support for update-windows (as available on most STxxxx display chips)
3. Convert all low level functions to inline PASM, which means that even a fully packed screen can be generated in fractions of the COGs clocks
4. Separate the graphics code from the display-driver
5. Scrolling should also be handled by the display-driver

Why do I want to separate the graphics code from the driver ... well ... looks like I really like displays. Recently I ordered a 1.1inch and a 1.3inch display. Both SPI as well and driven by a ST
7789. And I simply like the idea of running the same graphics code for all displays - no need to copy, paste and adapt per display ... simply use the object.

P2 / SPIN2 / PASM2 is so amazing!

... to be continued ...

MagIO2

OK, even if nobody seems to be interested ;o) ...

Now the code is in a state clean enough to post it here ... and maybe in the object exchange as well????
At least it shows the following:

• the real hardware driver and the graphics code are separated in different objects
• while separated, the graphics code can directly call the pixel function (some PASM in COG-RAM) of the hardware driver
• should be possible to have different hardware drivers (or multiple instances), which can be used at the same time by the graphics object
• fonts are separate objects. The graphics code can make use of different fonts.

Current functionality of driver:

• Set the color of a pixel in paint buffer
• Write content of write buffer to the display
• Support of double buffering prepared ( display buffer != paint buffer )
• set a window for pixel function ( won't draw pixels outside of these boundaries )

Current functionality of graphics:

• line with different values for start color and end color
• box with border color and fill color ( or -1 )
• circle with border color and fill color ( or -1 )
• text with a font that needs to be setup by the main program

Next todo's:

• implement the hardware 'window' support ( with that you can set the coordinates of a window and the display writes the stream of pixels coming in into it's internal RAM matching those coordinates )
• do a first test with another display
• convert the circle and line functions into PASM
• Make fonts more flexible - currently fonts are fixed to 8x8 pixels

Somewhen in future:

• hardware driver also implements the scrolling functionality
• maybe it makes sense to move the pixel function into LUT RAM?
• try using streamer

Cluso99

There is a Quick Bytes for LCDs that will probably work with this LCD too. All the driver chips seem to use the same registers.

MagIO2

@Cluso99: Thank you for the pointer. Actually I used your 8x8 font for the first tests ;o)
... but from an object called LCD_ST7796_V2.0.spin2. Is that the same than the ILI driver from the Quick-Byte?

Later I found those nice font files in one of the P1 drivers called AiGeneric written by Doug, Hippy, OBC and Baggers.

I think I use a slightly different approach, which might only be feasible for smaller displays due to the fact that I keep a screen buffer in HUB-RAM. (At least as long as the screen buffer is not externalized to some other RAM.) But the "beauty" of these drivers is, that the setPixel function is actually implemented by a hardware driver. So the graphic functions don't need to know anything about the physical layer behind ( HUB-RAM vs. external RAM, how a pixel is represented ... ). In one of the next iterations I will switch to a fixed color scheme for the graphics-part - RGBA (32 bit).

In the end, I waste some memory ( 8kB for this 128x128 greyscale display), while you are "wasting" a COG. With P2 we got more memory but we did not get more COGs ;o)

You know how it is with hobbies, you spend a lot of time for re-doing things which are already there ;o)
My goal is to find ways, which allow to share the per COG power. And I think most of the drivers shared in ObEx need a totally different design, than the drivers used to be developed for P1.

Cluso99

@MagIO2
Yes, the thread and the quick bytes are basically the same. All the lcd chips (ILI and ST) seem to be totally compatible.
Yes, if you see the comment on the 8x8 font you will see I state they were derived from hippy’s AI font. IIRC the bits are reversed as I recall writing a program to do this years ago.

The idea with a driver is that it be self-contained. This is why drivers are usuallly in their own cogs.
But you’re welcome to combine multiple drivers into one cog. I’m sure others will be happy if you do this.

BTW my driver can use different resolutions. Currently tested from 128x128 to 480x320. I just received a 1.5” 240x240 color SPI but haven’t had time to verify it.

MagIO2

@Cluso99 said:
BTW my driver can use different resolutions. Currently tested from 128x128 to 480x320. I just received a 1.5” 240x240 color SPI but haven’t had time to verify it.

I now switched to adding the next hardware driver for my 1.3inch 240x240 display and gave your driver a quick try. I can confirm that your driver works perfectly.

Cluso99

@MagIO2
Thanks for confirming it works.
I may have the same 1.3”, not 1.5”. I am interstate atm so cannot check.

MagIO2

To be continued here: https://forums.parallax.com/discussion/173278/display-driver-architecture