I am not aware of any intelligent library handling the 9-bit SPI mode that the data sheet calls 3-wire SPI.
UTFT however does have what it calls 4pin SPI which it bit-bashes without any concern for rules of a SPI bus.
UTFT has no concept of a Reset pin.
Fortunately, you can wire the Reset pin to 3.3V via a 10k pullup.
And use the ILI9341 Software Reset command.
I have never tried the UTFT 4p mode. I have not even looked to see if it understands Software Reset.
It will be very fiddly to use 9-bit SPI with the TFT and 8-bit with the SD card. The AVR hardware is not designed for this. Most ARM chips can.
You can tell if it is an ILI9340 or ILI9341 if you read register 0xD3. Most Chinese SPI displays do not enable EXTC. So you are not allowed to read 0xD3.
Are you still discussing the green pcb as shown in the Original Post from Feb 2016?
The link from misc.ws refers to Parallel Displays.
My reply from Feb 2016 (#2) said:
You can tell if it is an ILI9340 or ILI9341 if you read register 0xD3. Most Chinese SPI displays do not enable EXTC. So you are not allowed to read 0xD3.
Yes, you can read the ID from an ILI9340 or ILI9341. In any of the interface modes. Your 9-bit SPI is not supported by AVR hardware. The bit-bashed UTFT will be very SLOW.
If you are using an ARM, ESP8266, ESP32 it would be interesting to use the 9-bit SPI hardware.
There is a small chance that it would work with 2 8bit transfers on AVR. It might just ignore the extraneous bits.
I have one 9bit SPI TFT named TIANMA that works with 9bit transfers with ESP8266 (and another one named KeDei that I can't use, because I didn't find out the controller it uses, if it has any at all).
Adding 9bit SPI to my GxTFT library is still pending; if need is there I might reconsider priorities.
david_prentice:
You can configure ESP8266 for different SPI formats. Trailing garbage bits is not a good idea.
If you describe your Kedei or post a photo of the pcb, it should be easy to get going.
David.
I should have been more precise: the C/D bit value is in the first byte, most likely the last bit.
I may have a look at this quite soon.
The KeDei is not an issue for me, it is an opportunity kept for further investigation if ever I have nothing more interesting to experiment with or learn from.
I think I have posted about this in one of your topics; I will check.
The problem with Mega and Xmega is that the hardware SPI is only 8-bit.
The problem with STM32F103 is that the hardware SPI is only 8-bit or 16-bit.
I have a small STM8S board. I suspect it is only 8-bit SPI.
It looks as if you know how to level-shift the 5V signals from a Uno or Mega. So the AVR is usable but slow.
I will create a Branch on a GitHub project for you. I will tell you when it is ready.
I can support 3.3V ATmega328P and ESP8266. The 328P but-bangs 1-bit and then uses hardware for 8-bits. It works reasonably fast. The ESP8266 should fly.
If you are not familiar with ESP8266, I suggest that you start with your level-shifted Uno.
It is easier to stick with Arduino IDE.
Although my display works with the controller class for ili9341, the read register values look strange.
Reading graphics RAM seems to work, only the least significant bit seems stuck at zero.