ILI9341

[Ivano]

Good evening,
i am experimenting with a 320 x 240 display with ILI9341 chip and UGL library and a pic 18F2550.
All working.
My display in addition to the "mosi" pin also has the "miso" pin but I am not sure if the UCL manages it. I guess it serves to get an answer from the display if we have to read the status of one or more pixels.
Thanks in advance for the clarifications.

[John Drew]

Greetings Ivano,
I use the ILI8341 and use Les's excellent library. The MISO is there to read acknowledgements from the display. SPI (PIC is master) sends on MOSI and at the same time loads data from the MISO into the same buffer but one bit behind.
For more details check the WIKI.
The MISO pin is used to access the touch display too. Some of the displays don't have the touch chip on board but the latter are easily obtained.
I always make sure I buy the board with the touch provision.
The touch uses another set of SPI connections and seem to be grouped at the far end of the connector.
The touch adds another dimension and works well.
John

[TimB]

I would add that unless you are overwriting constantly you need to read what is on the display to then add/remove data. EG with line drawing. As you do not have a big chunk of ram in the device you need to use the display ram as the memory

[Ivano]

In my post I have misspelled UCL instead of UGL. Universal Graphic Library by Atomix.
I just started with these lcd and I understood how to draw on the display but I did not understand if I can also read the status of one or more pixels and my doubt is that to read I need the miso pin.
I also used the Les x library to write on a display with ST7735, but again it does not include miso pin.
In the libraries that I have tried there are commands like "get_pixel" or "get_window" that I imagine go to read the display, but I don't understand how missing the miso.
Sorry for my ignorance but I have just started with these displays and I wanted to understand how they work.

[John Drew]

Hi Ivano,
I can't help with reading pixels. Have you read the ili9341 data sheet? Better still, Atomix will have a good understanding and may comment on possibilities.
John

[atomix]

The UGL library uses the same pin in SPI mode (LCD_DAT) to write and read data.

See GRam.bas and GRam.pdsprj example (simulation for Proteus 8.13) in UGL.zip

[Ivano]

Hello Atomix
I have tried the GRam example on a ST7735 and it works fine.
On the display ILI9341 has separate mosi and miso so it does not read with mosi as you can see from the attached photo.I got the idea of connecting mosi and miso together maybe with a resistance, I don't know if it is feasible

[atomix]

Try it, it should probably work. I haven't tried that option...

[Pepe]

From what you see on the screen the procedure read record shows FFFFFF, as if the mosi does not send data, look with an oscilloscope if it returns data because in the simulation of proteus the atomix library works well

[Ivano]

The Atomix library certainly works well, tested on other displays.
In this display the mosi does not return data because there is miso x this, which is not provided in the UGL library.
The SDA pin of other displays probably has MISO and MOSI together so it works fine.
I will try to join them together, with 1K x resistor to avoid any damage. I'll let you know.
Thanks to everyone for the info, now everything starts to become clearer

[flosigud]

The connection of miso is irreverent until you read the display. Most of the time you don't need that. I see no reason to read modify write. The only instance I can think of is when you want a screendump. One interesting thing is that reading needs to be 18bit, regardless of mode. I once wrote a routine to read this display but lost it. I will write it again one day.

[Ivano]

Flosigud,
Mine is curiosity to understand the various commands of these displays that I have recently started using.
It is true that data is generally sent to the display, but sometimes it can happen, albeit rarely, the need to have to read the display to restore small parts of the screen, perhaps by moving a text to another area, without drawing it completely.

[Pepe]

Demo proteus to read pixel

[Pepe]

Connection with MOSI

[Pepe]

You have to see on the screen how the IM[3:0] pins are connected. To use MOSI you must connect the 1110 mode and for sdi/sda the 0110 mode as shown by the examples in proteus

[Pepe]

Example in Proteus of connection with Atomix UGL library on screen ILI9341 with SDI and SDO

[Ivano]

Good morning,
I solved the problem in 2 ways:
1) I connected the MISO to the MOSI via a 1K resistor (max 1.2K bigger doesn't work)
2) I modified the Atomix LCD_IFC.inc library by adding the LCD_MISO pin
Both solutions work.
I haven't tried Pepe's attachments yet because on my pc I have network problems and I have to transfer them from smartphone to pc and for the same reason I don't attach modified LCD_IFC.inc.
I am using the smartphone.
Thanks Pepe for the files and the interest and thanks to the whole forum

[Ivano]

My display with separate mosi and miso pins probably already has IMs set to 1110.
In fact it works perfectly using both of them in the two ways described in the previous post.

[Stephen Moss]

Are you certain connecting MOSI and MISO together with a resistor actually works, rather than just appearing to for now?

In true SPI one is clocked out on one edge (say rising), the other Clocked in the other edge (say falling), that is why the Input and Output need to be be on separate line as both can have data simultaneously.
If it is software (Bit-bashed) rather than hardware it would be possible to switch the pin form input to output but I would think that even if contention on the line was somehow avoided by tying MISO and MOSI that you risk clocking output data in and at some point it all going horribly wrong.

Consequently, keeping the input and output signals separate as they are meant to be would be better 

[Ivano]

I tried with the Gram.bas example present in the UGL library. Without the miso when you move the text to another area of the screen, in the previous area it leaves the background of the text as per the image attached in a previous post, a sign that it does not read the display ram. No problem with displays that have SDA in / out pin. By linking the miso in the two ways described above, the Gram.bas example works perfectly.
Probably the fact that they work on different fronts do not interfere with each other.
The program reads or writes, or one or the other, not at the same time, but perhaps I am mistaken in reasoning.
Of course I am doing some experiments to understand how it works and the ram reading will probably be rarely used.
Thanks Moss for the info, I am doing some beginner reasoning with my little in-depth knowledge on the Spi transmission and I have to check them on the hardware.