Thank you very much for your valuable comments.
Probably, I may have misunderstanding and my graphic driver may have some faults.
The color format is set to be RGB565, because the graphic controller ili9327 may not accept the RGBA8888 and/or RGB888 format(s). When the color format is set to be RGBA8888 in the Graphics Composer, the bad image appear as expected on the LCD screen (see fig1.png).
Should I need to convert the data with the RGBA8888 format into the one with the RGB565? How should the “A” information be kept in the firmware in this case?
As for the alpha blending, you make me notice that I must implement a read function (following pixelGet function, for example) in my graphic driver (see drv_gfx_ili9327.zip). I will do that. Than you.
static GFX_Color pixelGet(const GFX_PixelBuffer* buf,
const GFX_Point* pnt)
i=2; // <-- the break-point is set here
//for debugging with 0 optimization-level
You think that the RAM of ILI9327 is enough for the “Cache” background drawings.
Are the background data read from the RAM of ILI9327 by using the read function (such as pixelGet)?
However, it seems to me that the read function of this type is not needed, because the firmware does not stop at the break-point set inside the read function (see the codes shown above).
Moreover, the firmware repeats “reset” if the frame buffer is not set in the PIC's internal SRAM. It seems to me that the firmware cannot find the pointer to the frame buffer.
post edited by yts - 2018/01/08 19:21:01