I'm looking at using an LCD display that uses a HiMax HX8369 controller. Does SEGGER currently support that controller?

Here's the datasheet for that controller:
newhavendisplay.com/app_notes/HX8369.pdf

Adrian,

I understand that I would use this:
pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_FLEXCOLOR, GUICC_565, 0, 0);

However, which driver do I select here?
GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66708, GUIDRV_FLEXCOLOR_M16C0B16);

I am currently using the above driver with the display that comes with the STM3220G-EVAL evaluation board but I'm wanting to move to this larger 480x800 4.3" diagonal LCD display:
newhavendisplay.com/specs/NHD-4.3-480800EF-CTXP.pdf

With this controller chip:
newhavendisplay.com/app_notes/HX8369.pdf

For our project we eventually plan to move to a 4-bit grayscale ePaper display with approximately the same resolution. Ideally, I would also like to only store 4 bits per pixel grayscale to reduce RAM requirements for my GUI even though this nice fancy display supports up to 16.7M colors. Is there a nice way to accomplish that as well? What I mean to say is that I am developing a user interface on this display that only needs 4 bit grayscale so I don't want to have the RAM hit for image buffers that would be required to support a full 480x800 16.7M color display.

-Scott

Adrian,

The datasheet for the Himax HX8369 shows that for operation code 2C (RAMWR) there are 3 8-bit data writes when writing pixels to the display memory. The data sheet for the HX8357 shows only a single 8-bit write for that same operation. When I use this:

GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B16);


The graphics I am displaying is shown in triplicate -- in other words I am seeing three side-by-side images and the color rendering is not correct.

Which FLEXCOLOR driver should I being using with the HX8369?

-Scott

Ok, but which FlexColor driver should I use?

I tried this and this does not function properly:
GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B16);



The GUIDRV_FLEXCOLOR_F66709 is for the HX8357. If you look at the RAMWR operation for the HX8357 is only has 8 bits of data. The HX8359 RAMWR operation requires 3 8-bit data writes.


-Scott

Adrian,

I have successfully implemented my own driver for the HX8369 based off a template driver example I found on the internet after much experimentation. I don't think any of your drivers are suitable for the HX8369 since its command set is different than the other Himax parts that are in the supported driver list. I set the part into a 5-6-5 RGB 16 bit per pixel mode and I'm using a 16 bit wide data interface to the part. When I want to draw a bitmap I just set the drawing window using the CASET (0x2A) command and PASET(0x2B) command and then I issue the RAMWR (0x2C) command followed by the 16bit 5-6-5 RGB pixel values. To match the emWin pixel format to the pixel format used by the HX8369 I am using the GUICC_M565 format:

// GUICC_M565 RRRRRGGGGGGBBBBB to match format used by display
pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_HX8369, GUICC_M565, 0, 0);

One thing that's not quite working right is when I turn on the arrow cursor using GUI_CURSOR_Show(); and then move it across the screen (I have a touchscreen) it leaves behind a trail of black arrows (rather than the background image that should be shown) and occasionally the screen will repaint and that trail goes away. Do you have any idea which operation in my driver may not be working correctly based on what emWin does when moving that cursor?

I set a breakpoint inside this code within my driver so that I could see when small rectangular regions on the display are being repainted:
static inline void _DrawBitmap16BPP(GUI_DEVICE *pDevice, int x0, int y0, int width, int height, int stride, U16 const GUI_UNI_PTR *pData)
After pressing my touchscreen I see that the cursor is slowly painted in its new location and cleared out of its old location on the display using a sequence of _DrawBitmap16BPP() calls. I don't see any drawing flaws as I run through the drawing procedure which looks to update only one horizontal row of the arrow at a time -- one call to this function draws a horizontal row of the cursor in the new location and the next call undraws the cursor at its old location to reveal the correct background image. So I guess what I'm saying is that _DrawBitmap16BPP() looks to be doing what it is supposed to. So when I drag my finger across the display I'm not sure why I'm seeing a trail of black arrows? I didn't see this behavior on the display that used the ili9325 display controller IC so I'm guessing I have done something wrong in my driver for the Hx8369.

-Scott

Don't worry about the 4bit grayscale that's something I will take on later to reduce RAM usage if necessary. For now I'm going to use the display with 16-bit color.

I am using this code in my LCD_X_Config() but see nothing painting on the display:

// configure FlexColor driver for HX8369
GUI_PORT_API PortAPI = {0};

// Set display driver and color conversion
pDevice = GUI_DEVICE_CreateAndLink(GUIDRV_FLEXCOLOR, GUICC_M565, 0, 0);
// Give driver access to the functions
PortAPI.pfWrite16_A0 = lcdWriteReg;
PortAPI.pfWrite16_A1 = lcdWriteData;
PortAPI.pfWriteM16_A1 = lcdWriteMultipleData;
PortAPI.pfReadM16_A1 = lcdReadMultipleData;
GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B16);

I have attached my files so you can see what I'm doing. I know you don't have one of my displays there but is there something I'm obviously doing wrong to make use of the FLEXCOLOR driver with this display? When I use my own driver (HX8369_FSMC.c/HS8369_FSMC.h) the display is functional but when I move the cursor arrow around the touchscreen it leaves behind black arrow droppings. I'm not sure if maybe I don't have enough memory allocated -- I have only configured for 600kB in GUIConf.c.

Appreciate any advice you can provide on this as I would really rather make use of the FLEXCOLOR driver if I can get it working.