Hey all, was just wondering:
I see support for SSD1325 and SSD1327 on u8glib and some other libraries, but I can't find one with support for SSD1326.
I'm wondering about writing a driver on my own for this but I've never had to. Is it straightforward using the binary commands, or is it something that I won't be able to do on my own? Has anyone interfaced with an SSD1326 display before?
Thanks in advance for any thoughts~
Hi
Good, you started a new thread.
First thing, you should do: Collect all information about the display itself and its controller. In the previous thread, there had been some doubts and finally the display did contain a SSD1322 not a SSD1326 controller.
With u8glib, maybe some existing constructors will (partly) work. If so please provide pictures. If there is something which partly works, maybe cloning and updating an existing driver could be an option.
Oliver
Right, according to the datasheet this display does indeed have an SSD1326 chip. However, I tried a few other constructors and the display remained blank. I'm not entirely sure what else to try, or even if there's some extremely simple way to make sure the displays themselves aren't both bad or if it's just the code that needs to be tweaked.
Where to best start?
Sequence is this:
If you say, that the display remains blank, why do you think, that this is a software issue? Can you share a picture of your current setup and the datasheet of your display?
Oliver
I can take a picture of the rig when I get home, but it's essentially the display on a ZIF breakout board that's jumped over to a breadboard with some capacitors and resistors on it. I followed the exact schematic that the manufacturer provided, so I'm not sure why absolutely no pixels would be lighting up even when trying various constructors. That's why I was kind of wondering if there was even a simple test to see if the displays were both DOA on arrival. (it's possible)
I'll post pictures in a few.
Also send some documentation to crosscheck the hardware setup. Also: How did you connect the Arduino and what are the u8glib constructor arguments?
Oliver
So, right now I have it hooked up to a Teensy board for testing. I hooked up an SSD1306 display and that worked fine with u8glib.
I've tried a bunch of constructors... most recently this one:
U8GLIB_SSD1327_96X96_GR u8g(SETTING_DISPLAY_PIN_SCK, SETTING_DISPLAY_PIN_MOSI, SETTING_DISPLAY_PIN_CS, SETTING_DISPLAY_PIN_A0, SETTING_DISPLAY_PIN_RST);
These pin parameters worked with the SSD1306 and that constructor, but not with the SSD1326 display.
Attached are a photo of the testing rig, and the datasheets + sample code.
Attachments: Dropbox - Error - Simplify your life
Is the OLED configured for SPI? BS0, BS1 and BS2 all connected to GND?
Writing the software driver: You could use the ssd1327 constructor as a starting point.
Locate file u8g_dev_ssd1327_96x96_gr.c and have a look at the init sequence:
static const uint8_t u8g_dev_ssd1327_2bit_96x96_init_seq[] PROGMEM = {
U8G_ESC_DLY(10), /* delay 10 ms */
U8G_ESC_CS(0), /* disable chip */
U8G_ESC_ADR(0), /* instruction mode */
U8G_ESC_RST(1), /* do reset low pulse with (1*16)+2 milliseconds */
U8G_ESC_CS(1), /* enable chip */
0x0fd, 0x012, /* unlock display, usually not required because the display is unlocked after reset */
0x0ae, /* display off, sleep mode */
0x0a8, 0x05f, /* multiplex ratio: 0x05f * 1/64 duty */
0x0a1, 0x000, /* display start line */
0x0a2, 0x060, /* display offset, shift mapping ram counter */
//0x0a2, 0x04c, /* NHD: display offset, shift mapping ram counter */
0x0a0, 0x046, /* remap configuration, vertical address increment, enable nibble remap (upper nibble is left) */
//0x0a0, 0x056, /* NHD: remap configuration, vertical address increment, enable nibble remap (upper nibble is left) */
0x0ab, 0x001, /* Enable internal VDD regulator (RESET) */
0x081, 0x053, /* contrast, brightness, 0..128, Newhaven: 0x040, LY120 0x053, 0x070 seems also ok */
0x0b1, 0x051, /* phase length */
0x0b3, 0x001, /* set display clock divide ratio/oscillator frequency */
0x0b9, /* use linear lookup table */
#if 0
0x0b8, /* set gray scale table */
//0x01, 0x011, 0x022, 0x032, 0x043, 0x054, 0x065, 0x076,
0x01, 0x011, 0x022, 0x032, 0x043, 0x054, 0x077, 0x077, // 4L mode uses 0, 2, 4, 7
#endif
0x0bc, 0x008, /* pre-charge voltage level */
0x0be, 0x007, /* VCOMH voltage */
0x0b6, 0x001, /* second precharge */
0x0d5, 0x062, /* enable second precharge, internal vsl (bit0 = 0) */
#if 0
// the following commands are not used by the SeeedGrayOLED sequence */
0x0ad, 0x002, /* master configuration: disable embedded DC-DC, enable internal VCOMH */
0x086, /* full current range (0x084, 0x085, 0x086) */
0x0b2, 0x051, /* frame frequency (row period) */
0x0b4, 0x002, /* set pre-charge compensation level (not documented in the SDD1325 datasheet, but used in the NHD init seq.) */
0x0b0, 0x028, /* enable pre-charge compensation (not documented in the SDD1325 datasheet, but used in the NHD init seq.) */
0x0bf, 0x002|0x00d, /* VSL voltage level (not documented in the SDD1325 datasheet, but used in the NHD init seq.) */
#endif
0x0a5, /* all pixel on */
//0x02e, /* no scroll (according to SeeedGrayOLED sequence) */
0x0af, /* display on */
U8G_ESC_DLY(100), /* delay 100 ms */
0x0a4, /* normal display mode */
U8G_ESC_DLY(100), /* delay 100 ms */
0x0a5, /* all pixel on */
0x0af, /* display on */
U8G_ESC_DLY(100), /* delay 100 ms */
0x0a4, /* normal display mode */
0x015, /* column address... */
0x008, /* start at column 8, special for the LY120 ??? */
0x037, /* end at column 55, note: there are two pixel in one column */
0x075, /* row address... */
0x008,
0x05f,
This sequence has to be modified for your display. Best would be to take over commands from your sample code.
For example change
0x0a8, 0x05f, /* multiplex ratio: 0x05f * 1/64 duty /
to
0x0a8, 0x01f, / multiplex ratio: 0x01f * 1/64 duty */
because this is what is used in the sample code.
All in all, you have to take over the init code from the example to the u8glib driver.
Assuming the hardware is correct (which i can not check), then you may see some activity.
It is also a good idea to use the all pixel on and off commands to check proper functionality.
Oliver
Oliver
So, I basically copied and pasted the init() segment from the sample code into the 1327 file and adapted it to compile, but no luck. It's still just black.
I've double checked the wiring and I'm stumped. As mentioned, I copied the demo schematic circuit, and could maybe try to reach out to the company... but is there anything else that we can do to try and get one of the two displays to at least do something? Hard to tell if they're DOA or if it's a code issue.
Hi
Agree... It sometimes took me weeks to bring a display alive. A scope is often very helpful to debug the hardware. Signals must be available with the correct voltage level.
Oliver