SSD1963 8-bit interface

[Rafael Zingler]

Hello.

The display I´m using is based on the SSD1963 controller, with an 8-bit data interface to the host processor (ARM Cortex-M3). When I draw pixels directly to the display, using some basic routines I wrote, the colors were OK. However, calling the uGFX functions, the colors don´t seem to be right.

 

I think, accordingly to the topic bellow, the problem is that the current SSD1963 driver don´t support the 8-bit data interface. 

I´ve seen, by reading back the configuration registers from the controller, that after calling gfxInit() my previous configurations have been modified. For example, the pixel data interface I´ve previously configured to 0x00 (8-bit) is changed to 0x03 (16-bit 565 format).

Have someone already worked on an 8-bit driver for the SSD1963 controller?

Thanks!!

Edited July 4, 2016 by Rafael Zingler

[Joel Bodenmann]

Hello Rafael,

The SSD1963 is known to work well in 8-Bit mode. There's really no difference besides that you have to do two write transitions instead of one if you need to write a 16-bit value - everything else stays exactly the same. The only thing that you have to change to use the display in 16-bit instead of 8-bit mode are the write_index() and write_data() implementations in your board file. Please consult the datasheet to figure out how the data has to be packed on the bus. When I remember correctly, the driver initialization code stays exactly the same as the SSD1963 is configured for 8- or 16-bit mode via jumpers.

This is a video of an SSD1963 running in 8-bit mode on an ARM-Cortex M3 using µGFX:

 

[Rafael Zingler]

Joel,

 

I´m doing only one write cycle (as an 8-bit value) in my write_index() and write_data() functions, even being the bus between my LPC1768 and the SSD1963 only 8-bit wide.

Do you think this can be wrong? Must I write the high and low portions of the received value in 2 write cycles (high an low bytes)? Making so, how can I know when I must write the received value in only one cycle (command, for example) or 2 cycles (pixel data)?

Edited July 4, 2016 by Rafael Zingler

[Joel Bodenmann]

Yes, you definitely have to write the entire pixel value! Otherwise you are missing parts of the pixel data which leads to incorrect colors. You specify the pixel format in your driver configuration file (eg. RGB565). From that, the pre-processor determines the correct type to use and puts a typedef on color_t for that. This means, if your pixel format is set to RGB565 the color_t will be a 16-bit type. Your board file must put the entire (pixel) value on the bus according to the pixel data packaging stated in the datasheet (somewhere around page 15 depending on the revision). So to summarize: Yes, you must write the high- and low portions of the received uint16_t in two write cycles if you are using the display in 8-bit mode.
Without remembering all the details of the SSD1963: Usually all transitions will be either 16- or 8-bit. As in: When you set your SSD1963 to RGB565 mode (16-bit pixel values) and use an 8-bit bus, then you always have to do two write cycles - at least for the data.
All the information specific to the SSD1963 are off the top of my head. Please consult the datasheet for more precise information. I have a feeling that the SSD1963 only works in RGB666 (at least by default) which requires you to do three write cycles with an 8-bit bus. Please just look all that stuff up in the datasheet.

[Rafael Zingler]

Hello, Joel.

 

It´s finally working. I have made the following changes on my system: 

• in gdisp_lld_config.h, changed the pixel format from GDISP_PIXELFORMAT_RGB565 to GDISP_PIXELFORMAT_RGB888.
• in gdisp_lld_SD1963.c, changed PIXEL DATA INTERFACE configuration from SSD1963_PDI_16BIT565 to SSD1963_PDI_8BIT (in function gdisp_lld_init()). In the same file, gdisp_lld_write_color() function now calls the board function write_data() 3 times sequentially, shifting the color parameter appropriately on each call (R, G, and B).
• My board functions, write_index() and write_data() remains unchanged, writing a single byte at a time.

 

Grateful for your immediate reply, and congratulations for that very nice and powerful framework.

[Joel Bodenmann]

Glad to hear that you got it working!

Sorry for not being more specific about the SSD1963 driver implementation. There are many drivers in the library which evolve over time and some which we haven't written ourselves. It's sometimes hard to keep stuff separated