I have a monochrome SSD1306 128 x 64 OLED GLCD and basically I would like to know how I should interpret the hex array such as that shown in the screenshot?
My understanding is that 0x tells the Compiler that the next two characters that follow are hexadecimal. And in this case it is two 4-bit hexadecimal. And that each set of characters (eg 0xff) determines the X-Address (page), followed by the Y-Address (column within the page) which holds the pixel Data array (D0 to D7).
The fact it is all laid out in groups of 16 and that a lot of the hex characters are 0x00 is throwing me.
The logo16_glcd_bmp contains raw display data. Its only copied to the SSD1306.
I think its a good idea to take a look at the datasheet of the SSD1306 in section 8.7 (Graphic Display Data RAM (GDDRAM) there is a description on how each bit maps to a pixel.
Thank you for the info spec sheet. I should have looked at that first but it pretty much reinforces what I read here about GLCDs.
But unlike this GLCD I don't think the 1306 uses two controllers, only one.
I'm still unclear what the 0x "really" does but I would have thought that it tells the compiler to expect a hexadecimal value as x (itself) is not a hexadecimal value.
From the user point of view, you just need to know which library to use and what format the bitmap should be.
Whereas PC images like .BMP, .PNG, .JPG all follow a well documented format, monochrome bitmaps on an Arduino are not standardised.
They tend to be horizontal bytes describing the pixels on a horizontal row.
Or bytes that describe 8 vertical pixels per column.
And the pixels might be in MSB or LSB order.
It is wise to quote your display (e.g. link), library (e.g. name) and logo (PC image e.g. .JPG)
Then someone might advise you (or even create the logo C array for you)
You have been a member for 5 years. I am sure that you know what a hexadecimal number looks like.
Of course I know a hexadecimal values when I see one. And I am not after any help creating a picture or for any code. I was merely curious from an academic point to understand how this array (matrix) works and why it is like it is and what the 0x00 is and how it gets interpreted as it ALWAYS precedes the two hex characters.
Reading this website GLCD 128x64 | Sensors & Modules did explain it in an elegant and logical way but then it wasn't for the SSD1306 per se. But looking at the datasheet for the SSD1306 which Rintin kindly pointed me to, I believe it to be the 8 vertical pixels (LSB to MSB) per page multiplied by 128 segmented columns. Hence for the full 8 pages, we get 128 x 64 pixels.
Even though I have been a member for 5 years, I don't code very often, so my knowledge is pretty novice to say the least and although I thank you for your response, I don't appreciate your patronising remark.
Yes, that explains how the memory is organised in a SSD1306 or KS0108.
The library will set or clear pixels in the SSD1306 according to this memory layout.
The topic is fairly academic. You only need to use drawPixel(x, y, color) or appropriate graphics method e.g. fillCircle(x, y, radius, color) or drawBitmap(...)
There is little need for knowing exactly how the library does it.
Yes, you can do some things faster by directly manipulating the Adafruit_SSD1306 display buffer.
For example, you can memcpy_P() an image directly from PROGMEM to the display buffer.
This lets you do fast animations. But it does require you to have the data in the correct format.
If you are using hardware SPI, the animations may be too quick for your eyes.
I2C is slower. But you can get respectable animations.
