spectre Posted November 20, 2016 Report Share Posted November 20, 2016 (edited) Hello friends, I am driving a 320x240 color tft with the SSD1963 on board controller and a 8-bit only bus interface.It works, but the colors are weird: I am using the default 16BPP_565 pixel data format (I don't want to use the rgb888 mode to solve the issue,is too slow). I have done the following modification WITHOUT success: on the file gdisp_lld_SSD1963.c I have modified the following function as below: LLDSPEC void gdisp_lld_write_color(GDisplay *g) { //write_data(g, gdispColor2Native(g->p.color)); old function call write_data16(g, gdispColor2Native(g->p.color)); new function call } In the way above when I have to write a 16bbp_565 color the function write_data16 splits the word into 2 bytes(in order to work with a 8-bit data bus).But I still continue to see wrong colors. Looks like that nothing is changed. Awaiting your kind reply, thanks! Spectre P.S. the function write_data16 is embedded with the ugfx library Edited November 20, 2016 by spectre Link to comment Share on other sites More sharing options...
cheater Posted November 20, 2016 Report Share Posted November 20, 2016 (edited) hey, i had the same problem as you.if you want to use 24bit color depth, you need 3 write cycles of 8 bytes. just look into the ssd1963 specs. gdisp_lld_SSD1963.c gdisp_lld_config.h Edited November 20, 2016 by cheater Link to comment Share on other sites More sharing options...
inmarket Posted November 20, 2016 Report Share Posted November 20, 2016 There are two likely reasons... 1. When you output the 16 bit word you are outputting the bytes in wrong order. This is the most likely issue. 2. Your color format is really bgr565 instead of rgb565. Link to comment Share on other sites More sharing options...
spectre Posted November 20, 2016 Author Report Share Posted November 20, 2016 (edited) 5 hours ago, inmarket said: There are two likely reasons... 1. When you output the 16 bit word you are outputting the bytes in wrong order. This is the most likely issue. 2. Your color format is really bgr565 instead of rgb565. Dear friends, I am just looking at the ugfx bootscreen and the black default background is orange , not black. To put the two bytes on the gdisp_lld_write_color o function I use the default write_data16 :so I suppose that the order is correct. I really don't understand the reason as the ssd1963 is correctly configured to 16bpp 565 mode. Awaiting your kind reply, Spectre PS thanks Mr cheater,but I need the 16bpp565 for speed needs. The 3bytes solution sadly is too slow on my mcu. Edited November 20, 2016 by spectre Clean-up Link to comment Share on other sites More sharing options...
spectre Posted November 20, 2016 Author Report Share Posted November 20, 2016 Dear friends, may be that the 16bpp_565 mode is not possible on the SSD1963 controller if the data bus is 8-bit only, (also shifting the values) For now I've solved using the rgb888 mode transmitting 3 bytes. Slower, but at least it works. If someone had a similar issue please write to me a reply. Thanks in advance, Spectre p.s. meanwhile thanks to Mr inmarket and cheater for the quick answers Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted November 22, 2016 Report Share Posted November 22, 2016 Hello @spectre and welcome to the µGFX community! The datasheet of the SSD1963 display controller shows the following table: Link to comment Share on other sites More sharing options...
spectre Posted November 22, 2016 Author Report Share Posted November 22, 2016 (edited) Thank you Mr. Bodenmann! I've seen that table on the SSD1963 datasheet: about the 16bpp565 mode, writing two bytes with a 8 bit bus ,also If I put a simple 0xFFFF(white) or a simple 0x0000(black) I see wrong colors. I am using the write16 function as the first post I've submitted. Is a strange problem.. If you have any suggestion it will be appreciated :-) Seems that If I write two bytes consecutively to set the color on the 8 bit bus the controller expect to read from a 16 bit bus.. I've tried the same driver with a 16bit bus tft module and It works. For now I've solved with the rgb888 but it is a bit slow for my application.. if you have any hint it will be appreciated. The code is exacly the one posted above. nothing more/nothing less :-) thanks in advance, regards, Spectre Edited November 22, 2016 by Joel Bodenmann Removing unnecessary quote Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted November 22, 2016 Report Share Posted November 22, 2016 Hello Spectre, The table from the datasheet tells you that you cannot use RGB565 mode with an 8-Bit interface. The very first column is named "Interface" and refers to the actual interface that you are using. In your case you are using the 8-Bit interface which means that you are forced to write three bytes per pixel as shown in the table. Theoretically this is RGB666 but because the two least significant bits are ignored (the 'X' in the table) means that you can successfully use RGB888. Unfortunately that table tells you that you are not able to use RGB565 with an 8-Bit interface. To do that, you'd have to use a 16-bit interface and that is why the 16-bit one that you tried works fine. This information might also be interesting to @cheater as he didn't seem to have understood why only RGB888 with three writes work for him. Link to comment Share on other sites More sharing options...
spectre Posted November 22, 2016 Author Report Share Posted November 22, 2016 (edited) Dear Sir Bodenmann, you are right! I've seen now the table header.. thanks a lot. Regards, Spectre Edited November 22, 2016 by Joel Bodenmann Removing unnecessary quote Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now