This GLVD is a 0.49 inches OLED display module of 64x32resolution OLED
Working without backlight, the OLED display module works great.
In low ambient light conditions such as a dark room, an OLED screen can achieve a higher contrast ratio than an LCD.
The display with small dimension is suitable for MP3, function cellphone, smart health device, etc.
Specifications:
* Display Size: 0.49in
* Resolution: 64*32
* Text Color: White
* Driver IC: SSD1306
* Interface Type: IIC
* Pin Quantity: 4Pin
* Pixel Size: 0.155*0.155mm
* Operating Temperature: -40~85℃
* Working Voltage: 3.3V-5V
Interface:
GND: Ground
VCC: Power supply+ 3.3~5V
SCL: IIC clock
SDA: IIC data
Library
Use the standard GLCD library with the GLCD_TYPE = GLCD_TYPE_SSD1306_64x32 All the standard GLCD commands are supported.
Got one of these and is eager to try it. First time with a GLCD.
I can't find my USB-Serial thingy so I can't scan the I2C. I tried 0x78 and 0x3C without seeing any signs of life from it.
Do you remember what I2C address yours had? If not, don't waste time finding out. I will wait for my new serial-thingy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You need the latest build for this tiny display.
GCBASIC uses the 8bit address, so, 0x78 is the standard address.
Try with two 4k pullup resistors in the DATA and CLOCK lines.
I did try with pullups.
I have the "February 2023 (version 1.76)" "Update 1.76.2"
The glcd.h is dated Jan 9.
The terminal said with my code :
GCBASIC (2025.02.15 (Windows 64 bit) : Build 1465)
...
Finding source files:
C:\GCstudio\gcbasic\include\glcd.h: found
C:\GCstudio\gcbasic\include\glcd_ks0108.h: found
Is that right? ks0108.h?
Running your example now, I get Syntax Error: [{
"resource": "/c:/GCstudio/gcbasic/include/glcd.h",
"owner": "gcb",
"severity": 8,
"message": "Syntax Error (Library Include)",
"source": "gcb",
"startLineNumber": 1259,
"startColumn": 1,
"endLineNumber": 1259,
"endColumn": 2147483647
}]
1259 : GLCDDrawChar GLCDPrintLoc, PrintLocY, LCDPrintData(GLCDPrint_String_Counter)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is a release error. The build is missing a file update.
My fault I had overlooked this specific file.
So, to fix.
Open GLCD.DAT in the include folder.
Add at the bottom the followling line. 38,GLCD_TYPE_SSD1306_64x32,glcd_ssd1306.h
Save and Test - and let me know if this resolve.
The GLCD.DAT file is the control file for the GLCD library. This line tells the compiler to load the correct library for this specific GLCD config.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DINKY: (of an object or place) attractively small and neat.
I have a new project where I am embedded one of these.
I was a pain to figure out how this little device worked but once I understood the memory map. I added the supporting code to handle the memory map. It was just same as the other SSD1306s.. just a lot smaller.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Half way there. A tiny Pong Trainer test game. A pongish clone seems possible after all. I started making a bouncing ball inside the four walls. What a mess handling the ball bounce/directions and stuff. Now I opened up one wall, adjusted the ball direction/angles to suit pong and the wide screen (really, it is so...well...not wide... :) and then inserted a paddle controlled player. There are three angles per quadrant (not counting straight back and forth).
I thought I should try low memory mode and see what effect it has on RAM use, but I get:
"Error: GLCD_TYPE_SSD1306_64x32 in low memory mode not tested"
Can I test it or is it not implemented?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried #define GLCD_TYPE_SSD1306_LOWMEMORY_GLCD_MODE
But then realized it is probably not for the 64x32 version.
Trying this instead: #define GLCD_TYPE_SSD1306_64x32_LOWMEMORY_GLCD_MODE (which may be nonsense) the compiler accepts it, but the RAM use is still over 300 bytes, so I guess I am not doing it right or it is not implemented.
My new and wild attempt: The pixel is drawn, but RAM use is not affected. The compiler probably have no idea what I'm asking for... :)
Post a program with the minimum code to get it to compile and draw line. It may not draw the line but the intent is to draw a line. Draw from top-left corner to bottom-right corner: This is a good test program.
I would get the program working in normal mode then add the low memory mode.
Then, I can have a look to see what is going on. I need to remind myself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure if more is needed. I took some example from the help to start testing.
The compiler says this and does not produce a hexfile.
Error: GLCD_TYPE_SSD1306_64x32 in low memory mode not tested
I now tested the above on a SSD1306 128x64.
(#DEFINE GLCD_TYPE GLCD_TYPE_SSD1306)
It worked fine. 1.1kB of ram shrunk to 200 bytes in LOWMEMORY_GLCD_MODE.
-WOW! This screen is huge!!!
:)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I went and temporarily edited out the warning for 64x32 in glcd-ssd_1306.h
It compiles and seem to work, but it seems not practical for drawing many pixels, since it quickly eats up program memory.
One pset in the normal way:
Program Memory: 565/16384 words (3.45%)
RAM: 304/2048 bytes (14.84%)
One pset in low memory mode:
Program Memory: 598/16384 words (3.65%)
RAM: 178/2048 bytes (8.69%)
I'm not sure if this can be made more efficient for the 64x32 and RAM or this as low as it gets.
While comparing I learned that each pset in code costs 8bytes of program memory, so it is a good idea to plot as much as possible through a routine using one pset rather than lising a bunch of separate ones. I guess that this is due to the architecture of the SSD1306 and that there is no easy way around other than using the pset sparsly and I guess that makes low memory mode not so good for plotting a bunch of things.
I think I will stay with the Full GLCD mode for now (focusing on using pset).
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Testing new hardware for the tinyscreen. A sandwich with a PIC 16F17115 and programming socket on the back of the screen. One idea is to use the programming socket as game paddle inputs. The whole package measures 15x16x10mm.
New GLCD ... 12mm/0.49inches ... yep is is tiny
Features:
This GLVD is a 0.49 inches OLED display module of 64x32resolution OLED
Working without backlight, the OLED display module works great.
In low ambient light conditions such as a dark room, an OLED screen can achieve a higher contrast ratio than an LCD.
The display with small dimension is suitable for MP3, function cellphone, smart health device, etc.
Specifications:
* Display Size: 0.49in
* Resolution: 64*32
* Text Color: White
* Driver IC: SSD1306
* Interface Type: IIC
* Pin Quantity: 4Pin
* Pixel Size: 0.155*0.155mm
* Operating Temperature: -40~85℃
* Working Voltage: 3.3V-5V
Interface:
GND: Ground
VCC: Power supply+ 3.3~5V
SCL: IIC clock
SDA: IIC data
Library
Use the standard GLCD library with the
GLCD_TYPE = GLCD_TYPE_SSD1306_64x32All the standard GLCD commands are supported.Works great but very small.
Some photos.
Enjoy
Last edit: Anobium 2025-01-08
Got one of these and is eager to try it. First time with a GLCD.
I can't find my USB-Serial thingy so I can't scan the I2C. I tried 0x78 and 0x3C without seeing any signs of life from it.
Do you remember what I2C address yours had? If not, don't waste time finding out. I will wait for my new serial-thingy.
Hm... 0x78 vs 0x3C - 8 vs 7bit?
Anyway. Is there more needed than this to get it started?
Last edit: Roger Jönsson 2025-03-19
I would go with this.
You need the latest build for this tiny display.
GCBASIC uses the 8bit address, so, 0x78 is the standard address.
Try with two 4k pullup resistors in the DATA and CLOCK lines.
Good to see someone using the library!
I did try with pullups.
I have the "February 2023 (version 1.76)" "Update 1.76.2"
The glcd.h is dated Jan 9.
The terminal said with my code :
GCBASIC (2025.02.15 (Windows 64 bit) : Build 1465)
...
Finding source files:
C:\GCstudio\gcbasic\include\glcd.h: found
C:\GCstudio\gcbasic\include\glcd_ks0108.h: found
Is that right? ks0108.h?
Running your example now, I get Syntax Error:
[{
"resource": "/c:/GCstudio/gcbasic/include/glcd.h",
"owner": "gcb",
"severity": 8,
"message": "Syntax Error (Library Include)",
"source": "gcb",
"startLineNumber": 1259,
"startColumn": 1,
"endLineNumber": 1259,
"endColumn": 2147483647
}]
1259 : GLCDDrawChar GLCDPrintLoc, PrintLocY, LCDPrintData(GLCDPrint_String_Counter)
There is a release error. The build is missing a file update.
My fault I had overlooked this specific file.
So, to fix.
Open GLCD.DAT in the include folder.
Add at the bottom the followling line.
38,GLCD_TYPE_SSD1306_64x32,glcd_ssd1306.hSave and Test - and let me know if this resolve.
The GLCD.DAT file is the control file for the GLCD library. This line tells the compiler to load the correct library for this specific GLCD config.
That did it! Thanks!
So happy to finally see the "hello" on the tiny screen.
So easy!! Sorry, for my little error. It will be fixed in the next release.
Post a picture!!
Last edit: Anobium 2025-03-19
Here it is!
So dinky!!
DINKY: (of an object or place) attractively small and neat.
I have a new project where I am embedded one of these.
I was a pain to figure out how this little device worked but once I understood the memory map. I added the supporting code to handle the memory map. It was just same as the other SSD1306s.. just a lot smaller.
If I had the skills and time I would love to make a "Dinky Pong" game.
(with two tiny paddles, of course).
I made a simple bouncing pixel and the screen updates fast and smooth enough.
Half way there. A tiny Pong Trainer test game. A pongish clone seems possible after all. I started making a bouncing ball inside the four walls. What a mess handling the ball bounce/directions and stuff. Now I opened up one wall, adjusted the ball direction/angles to suit pong and the wide screen (really, it is so...well...not wide... :) and then inserted a paddle controlled player. There are three angles per quadrant (not counting straight back and forth).
Last edit: Roger Jönsson 2025-03-30
Impressive!!
Can I save memory by not loading fonts GLCDCHARCOL3.....7? Or how does that work?
I only need to draw pixels (maybe lines).
(TinyPong now has two players and sound. )
Duh! -By not writing any text the fonts are not loaded.
I thought I should try low memory mode and see what effect it has on RAM use, but I get:
"Error: GLCD_TYPE_SSD1306_64x32 in low memory mode not tested"
Can I test it or is it not implemented?
:-) At least I was on honest to have the library tell the truth.
No tested means that I have no looked at the capability. Would mean that it may or it may not work...... As you found out. :-)
I tried #define GLCD_TYPE_SSD1306_LOWMEMORY_GLCD_MODE
But then realized it is probably not for the 64x32 version.
Trying this instead: #define GLCD_TYPE_SSD1306_64x32_LOWMEMORY_GLCD_MODE (which may be nonsense) the compiler accepts it, but the RAM use is still over 300 bytes, so I guess I am not doing it right or it is not implemented.
My new and wild attempt: The pixel is drawn, but RAM use is not affected. The compiler probably have no idea what I'm asking for... :)
Post a program with the minimum code to get it to compile and draw line. It may not draw the line but the intent is to draw a line. Draw from top-left corner to bottom-right corner: This is a good test program.
I would get the program working in normal mode then add the low memory mode.
Then, I can have a look to see what is going on. I need to remind myself.
I'm not sure if more is needed. I took some example from the help to start testing.
The compiler says this and does not produce a hexfile.
Error: GLCD_TYPE_SSD1306_64x32 in low memory mode not tested
I now tested the above on a SSD1306 128x64.
(#DEFINE GLCD_TYPE GLCD_TYPE_SSD1306)
It worked fine. 1.1kB of ram shrunk to 200 bytes in LOWMEMORY_GLCD_MODE.
-WOW! This screen is huge!!!
:)
Very funny!!
I went and temporarily edited out the warning for 64x32 in glcd-ssd_1306.h
It compiles and seem to work, but it seems not practical for drawing many pixels, since it quickly eats up program memory.
One pset in the normal way:
Program Memory: 565/16384 words (3.45%)
RAM: 304/2048 bytes (14.84%)
One pset in low memory mode:
Program Memory: 598/16384 words (3.65%)
RAM: 178/2048 bytes (8.69%)
I'm not sure if this can be made more efficient for the 64x32 and RAM or this as low as it gets.
While comparing I learned that each pset in code costs 8bytes of program memory, so it is a good idea to plot as much as possible through a routine using one pset rather than lising a bunch of separate ones. I guess that this is due to the architecture of the SSD1306 and that there is no easy way around other than using the pset sparsly and I guess that makes low memory mode not so good for plotting a bunch of things.
I think I will stay with the Full GLCD mode for now (focusing on using pset).
Testing new hardware for the tinyscreen. A sandwich with a PIC 16F17115 and programming socket on the back of the screen. One idea is to use the programming socket as game paddle inputs. The whole package measures 15x16x10mm.
Very good work!
Really nice photos.