I don't know if this is relevant but I use an ili9481 but with mmbasic and picomite and there's problems with miso, a 680R needs wiring in and I used a diode as well for the display to work.
For the ILI9488 it says
"Initialises a TFT display using the ILI9488 controller. This supports 480 * 320 resolution. Note that this
controller has an issue with the MISO pin which interferes with the touch controller. For this display to work the
MISO pin must not be connected"
Thanks for the info. Just to clarify, which pins are the diode and resistor connected across. Will try.
I have emailed the seller for more details/data sheet. I am not using the touch controller.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Re the diode and resister. In all the GLCD development I have done... that is new to me. I would not be using that solution without a lot more proof of the root cause.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it's an ili9488
in5819 between sdo and touchdo
10KR between reset and touchDin
I did use a 680R between sdo(miso) and touchdo
this is only for picomite not gcb
ili9341 works fine on picomite
ili9488 works fine also now and is swap-able
For gcb this is probably not relevant. You don't need miso for display unless you want pixel read. reset can be tied high.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The likey cause is the setting for the COLMOD parameter in the GLCD CPU register. Without know the exact CP of the GLCD we would be guessing. I know the current color definitions work on a proper device ( I have just tried three of them).
So, next step is the GLCD discovery.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another major insight. The ILI9488 driver uses 18bit color. It is my latest driver.
The ILI9488 and the GLCD CPU that we test ONLY use 18bit color coding. The GLCD CPU would not support the typical 16bit color coding - the chip refused to accept any parameter changes.
So, if your GCLD CPU supports the 16bit colors, or, the GLCD CPU is hard codeed to use 16-bit color then your experience of colors being incorrect makes total sense.
To resolve, if the GLCD CPU is an ILI9488, I need the register dump using the discovery program. Then, with a test program will need to try and set a specific register to 16bit, then, dump the registers again. If the GLCD CPU supports 16bit then a small change to the library will be required ( add the setting of the register(s) and some control logic to support 18bit and 16bit color).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Examination of the GLCDDiscovery Test.txt file at register 0x00D3 reveals no meaning full information. It read as reg(0x00D3) FE FE F0 FC FC 66 CC f.k
I was expecting 94 88 xx xx xx xx
I do not think the readreg() operation is incorrect as you are getting different values across all the registers. If the readreg() was failing they would all be 0x00 or 0xFF. So, reading all the ILI9341 registers will ensure the read is working.
So, I have looked at how Arduino handles this. They have a constant for the ILI9488 which converts all colorcodes.. I am not surprised as these clone ILI9488 are not very good clones. There are also other hacks to get the GLCD working.
So, I suggest the following.
Dump the ILI9341 - I want this as a reference.
Then using the ILI9488 ...
Add this to the dump program before main loop
// ILI9488_CMD_COLMOD_PIXEL_FORMAT_SETSendCommand_ILI9488(0x3A)// Interface Pixel Format SendData_ILI9488(0x55)//16 bit
Then run the dump again.
If register 0x3A does not change then we know the configuration of the color control is controlled by the hardware configuration not software.
Send me th new dump
If register 0x3A changes (by the method above) then we can change the colors in the .H to the 16bit standard colors (I will need resolve a few other things). Or, if 0x3A does not change then I will implement color control on some constant we define.
Either way. This will be fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tell me that the GCLD CPU is a clone and it has read only registers. Nornally, I would change the registers to match the RGB color scheme.
OK.
Using the library ( drop the discovery program). Create a program that sets the background to TFT_BLACK using GLCDCLD( TFT_BLACK) and add four filled boxes. TFT_White, TFT_Red, TFT_Green, TFT_Blue.
What do you see? Which colors? A photo will help me.
I will change library now to support this new/different GCLD.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please post that program you are using. I want to try it here.
There must be an issue in the string write routines. The basic colors are correct in terms of the boxes - this use a method called PSET(). The string handler uses PSET() there is a lot handling from the source to PSET().
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The GLCDPrint method ( there may others) is not supporting the 18bit color scheme of the ILI9488. So, the compiler calls 8bit color scheme code. There is already code for 16bit color scheme (this uses a Word for color definition). This is an error I made when testing.
Re the color.
Are you using
ILI9486l_BLUE
orTFT_BLUE
? Those colors are examples. UseTFT_color
I don't know if this is relevant but I use an ili9481 but with mmbasic and picomite and there's problems with miso, a 680R needs wiring in and I used a diode as well for the display to work.
For the ILI9488 it says
"Initialises a TFT display using the ILI9488 controller. This supports 480 * 320 resolution. Note that this
controller has an issue with the MISO pin which interferes with the touch controller. For this display to work the
MISO pin must not be connected"
Thanks for the info. Just to clarify, which pins are the diode and resistor connected across. Will try.
I have emailed the seller for more details/data sheet. I am not using the touch controller.
Re the diode and resister. In all the GLCD development I have done... that is new to me. I would not be using that solution without a lot more proof of the root cause.
it's an ili9488
in5819 between sdo and touchdo
10KR between reset and touchDin
I did use a 680R between sdo(miso) and touchdo
this is only for picomite not gcb
ili9341 works fine on picomite
ili9488 works fine also now and is swap-able
For gcb this is probably not relevant. You don't need miso for display unless you want pixel read. reset can be tied high.
I am using TFT_Color
Re the Color issue.
The likey cause is the setting for the COLMOD parameter in the GLCD CPU register. Without know the exact CP of the GLCD we would be guessing. I know the current color definitions work on a proper device ( I have just tried three of them).
So, next step is the GLCD discovery.
Another major insight. The ILI9488 driver uses 18bit color. It is my latest driver.
The ILI9488 and the GLCD CPU that we test ONLY use 18bit color coding. The GLCD CPU would not support the typical 16bit color coding - the chip refused to accept any parameter changes.
So, if your GCLD CPU supports the 16bit colors, or, the GLCD CPU is hard codeed to use 16-bit color then your experience of colors being incorrect makes total sense.
To resolve, if the GLCD CPU is an ILI9488, I need the register dump using the discovery program. Then, with a test program will need to try and set a specific register to 16bit, then, dump the registers again. If the GLCD CPU supports 16bit then a small change to the library will be required ( add the setting of the register(s) and some control logic to support 18bit and 16bit color).
this works picomite, any use?
const WH =RGB(255, 255, 255) 'WHITE
const YE =RGB(255, 255, 0) 'YELLOW
const LI =RGB(255, 128, 255) 'LILAC
const BR =RGB(255, 128, 0) 'BROWN
const FU =RGB(255, 64, 255) 'FUCHSIA
const RU =RGB(255, 64, 0) 'RUST
const MA =RGB(255, 0, 255) 'MAGENTA
const RE =RGB(255, 0, 0) 'RED
const CY =RGB(0, 255, 255) 'CYAN
const GR =RGB(0, 255, 0) 'GREEN
const CE =RGB(0, 128, 255) 'CERULEAN
const MI =RGB(0, 128, 0) 'MIDGREEN
const CO =RGB(0, 64, 255) 'COBALT
const MY =RGB(0, 64, 0) 'MYRTLE
const BL =RGB(0, 0, 255) 'BLUE
const Bk =RGB(0, 0, 0) 'BLACK
const Gy =RGB(128, 128, 128) 'GREY
const Lg =RGB(210, 210, 210) 'LITEGREY
const Og =RGB(255, 165, 0) 'ORANGE
const PK =RGB(255, 160, 171) 'PINK
const Gd =RGB(255, 215, 0) 'GOLD
const SA =RGB(250, 128, 114) 'SALMON
const BE =RGB(245, 245, 220) 'BEIGE
Helps. As this helps to confirm the WHITE, RGB and BLACK values.
It does not help in terms of determining the color format of 5-5-5, 5-6-5, or 6-6-6.
Tested the discovery program found the ILI9341 with no problems
Please see attached for unknown display.
Do you have a discovery program for the ILI9341 ?
Examination of the GLCDDiscovery Test.txt file at register 0x00D3 reveals no meaning full information. It read as
reg(0x00D3) FE FE F0 FC FC 66 CC f.k
I was expecting 94 88 xx xx xx xx
I do not think the readreg() operation is incorrect as you are getting different values across all the registers. If the readreg() was failing they would all be 0x00 or 0xFF. So, reading all the ILI9341 registers will ensure the read is working.
So, I have looked at how Arduino handles this. They have a constant for the ILI9488 which converts all colorcodes.. I am not surprised as these clone ILI9488 are not very good clones. There are also other hacks to get the GLCD working.
So, I suggest the following.
Add this to the dump program before main loop
Then run the dump again.
If register 0x3A does not change then we know the configuration of the color control is controlled by the hardware configuration not software.
Either way. This will be fixed.
Adding above lines causes errors. see attached.
I figured that you would have to adapt the program.
I used the private methods in the library. Post your test program. I will adapt in a few secs.
Attached
I have removed the space in the filename. See attached.
0x3A no change.
Tell me that the GCLD CPU is a clone and it has read only registers. Nornally, I would change the registers to match the RGB color scheme.
OK.
Using the library ( drop the discovery program). Create a program that sets the background to TFT_BLACK using GLCDCLD( TFT_BLACK) and add four filled boxes. TFT_White, TFT_Red, TFT_Green, TFT_Blue.
What do you see? Which colors? A photo will help me.
I will change library now to support this new/different GCLD.
Box colors look OK. Text colors not displayed correctly. Their is text above the white and red
box's.
That is a total surprise to me.
Change the background to TFT_WHITE. I need to see the colors of the text.
These colors means the color scheme in the GLCD is 18bit. Which is what the library is set to. So, the color scheme is correct.
The issue is elsewhere.
Post the new picture with the white background.
Attached.
Please post that program you are using. I want to try it here.
There must be an issue in the string write routines. The basic colors are correct in terms of the boxes - this use a method called PSET(). The string handler uses PSET() there is a lot handling from the source to PSET().
Attached.
Perfect. I walked the ASM to see the issue.
The GLCDPrint method ( there may others) is not supporting the 18bit color scheme of the ILI9488. So, the compiler calls 8bit color scheme code. There is already code for 16bit color scheme (this uses a Word for color definition). This is an error I made when testing.
So, add the following code to your test program.
Test, provide resullts please.
Evan