Hi @DerekR,
There are several different conversations about different displays up on this thread:
The hopefully
reasonably standard ILI9488 boards (not sure yet how different ILI9486 are).
Hardware: Some of these boards appear to probably have tristate on the MISO pin and some don't, i.e. they don't work well with other SPI devices. Which I believe includes the aliexpress. Some may have it. And of course some of them have different touch screen options.... So different libraries and the like would need to be used depending...
Which is why @mjs513 created a simple tristate board...
Software(
https://github.com/mjs513/ILI9488_t3): I believe was working pretty well. It has most everything of my ILI9341_t3n, including frame buffer, Asynchronous updates, ... with some caveats.
Note: at one time @PaulStoffregen was looking into producing or sourcing a board. Not sure if that is a possibility or not.
a) There is no way (that I know of) to use 16 bit colors with these displays in SPI mode. So we map colors from 16 bits to 18 bits, when we do graphic operations. So while on ILI9341 when we output a color: it is 16 bits that get sent over SPI(565 format). But for these displays it is 24 bits that get sent. This also implies by simple calculations that updating the display takes a lot longer than ILI9341. 320x240*2=153600 to 320x480*3=460800 (i.e. 3 times slower)
b) Currently the software in frame buffer mode, is using sort of a built or defined color pallet as, up until T4 (beta 2 board), there was not enough memory on any board to easily make frame buffer. And to do dma to these devices I am needing to do some extra work to make them work. That is I have the Frame buffer, then I define two buffers to use with DMA, where 32 bits per pixel, and then the DMA code round robins between the two, and the DMA isr, when it completes one of these buffers, goes out and translates the frame buffer values through the pallet to fill in the buffer again with the next set of pixels....
...
Again this software so far is mainly been done as an experiment and while I believe things are working well, there could be issues. As with all things no guarantees of anything... But I am pretty sure that several of us will try to resolve issues if you run into them.
Then there is the
KeDei RPI boards V6.3
Hardware:
A really strange beast. You can get them pretty cheap:
https://www.ebay.com/itm/263427102486
Again same size display as ILI948x boards, but they are screwy! That is instead of having the display with normal display processor doing SPI, it uses 3 shift registers. It also has an XPT2046 chip on board. This communications with this board are really screwy. If you want to know more details, they are scattered in this thread. Some of which are in the readme file of my github project:
https://github.com/KurtE/KeDeiRPI35_t3
Software(
https://github.com/KurtE/KeDeiRPI35_t3) : We probably spent 10 times as much time as these displays warrant. But we were too stubborn to give up.
a) They are slow! That is for each thing we actually output, they are 4 bytes output and for each of these 4 byte groupings, we have to pulse the Touch screens Chip select pin, so we can not buffer these in FIFO queue.
b) as such while we started from the ILI9488 code above, it does not support the asynchronous updates (DMA), As sort of pointless, as would probably have to interrupt for each pixel....