pixel data for ILI9341

[madires]

Currently I got a lot of fun with a ILI9341 based LCD module (240x320). From the documentation I've learned to set an address window to send pixel data to the display controller. If I got it right, I have to send the pixels row-wise, i.e. all pixels of the first row, then 2nd row and so on. But when I set the address window to 100x100 and simply send 100 pixels, I get a vertical line. So I have to send the pixels column-wise. And that works the same for all possible orientations (X-flip, Y-flip, XY-exchange).

The next strange thing I've found is that I have to swap X (columns) and Y (pages/rows) for the address window to place my drawing box, e.g. for a character, at the correct position. That means start/end column goes into the page address set command and start/end page into the column address set command. Otherwise the next character wouldn't be drawn right of the last one, but beneath it. Again, the same for all display orientations.

I've tripple-checked everything, so I'm a little bit puzzled. Is the documentation wrong or is my Chinglish too bad? Or is there anything else I've missed?

[amyk]

What is the setting of the MV bit in Memory Access Control (36h) command? See section 9.3 of the datasheet.

[madires]

What is the setting of the MV bit in Memory Access Control (36h) command? See section 9.3 of the datasheet.

I get the same effect with MV set and unset. WIth MV set the display's orientation changes to XY swapped, but everything stays the same, just rotated.

[amyk]

Are you sure it's an ILI9341? The ILI9341 and ILI9342 are very similar but the latter is configured for 320x240 (960 x 240 outputs) instead of 240x320 (720 x 320 outputs). You can inspect the subpixel arrangement to determine what the "natural" orientation of the display is, and thus determine this.

[briselec]

sounds like a simple bug in your code.

[Chris C]

But when I set the address window to 100x100 and simply send 100 pixels, I get a vertical line.

That you listed only TWO coordinates in your window makes me wonder if you've missed something.  There are FOUR coordinates in the drawing window.

Set register 0x2A with X1 and X2 where X1<=X2, then 0x2B with Y1 and Y2, where Y1<=Y2.  This defines a rectangular region, which will be filled (assuming default MAC settings) from left to right, then top to bottom.

Also, make sure you send the most significant byte of each coordinate first, then the least significant.  This is NOT how most MCUs store variables in memory, so if you attempt to send X1 by coding something like "send two bytes over SPI, beginning at the address of X1", you will not get proper results.  Swap the bytes first.

While I'm at it - if you ever try reading pixels back from the ILI9341, after reading the pixel data, you may find it necessary to toggle CS twice (to de-select then re-select the chip) before trying to issue another command.  Doesn't seem to work right if you don't, and it wasn't documented in the datasheet so far as I could tell.

[FreddyVictor]

While I'm at it - if you ever try reading pixels back from the ILI9341, after reading the pixel data, you may find it necessary to toggle CS twice (to de-select then re-select the chip) before trying to issue another command.  Doesn't seem to work right if you don't, and it wasn't documented in the datasheet so far as I could tell.

been messing around with this LCD for a month or so..

I did notice that after setting DC pin Hi, I have a 50us wait before the 1st dummy read:

Code: [Select]

    LCD_SetAddress(pos_x, pos_y, pos_x+width-1, LCD_HEIGHT-1);
    writeCommand(READ_MEMORY_START);

    digitalHi(LCD_DC_PORT, LCD_DC_PIN);
    delay_us(50);

    spi_GetByte( lcd_spi ); // dummy read to remove initial 0x00
<read data into array>

probably faster to toggle your CS pin instead tho' ! 

as for the OP, they need to post some actual code....

[Chris C]

I did notice that after setting DC pin Hi, I have a 50us wait before the 1st dummy read:

Hmm.  I send the read command, raise DC, and can immediately read the dummy byte and pixel data.  The dummy byte's sole purpose is to provide the necessary delay, so no further delay should be necessary.  And I usually run it past rated spec, at 24Mhz SPI clock speed.  The CS double-toggle is done only after reading all pixel data.  I switch between reads and writes frequently when alpha blending is being used in my render engine.

But folks seem to get different results with the ILI9341, especially regarding the max possible clock speed.  I wonder if the Vcore setting has something to do with it, or maybe there's some not-quite-perfect counterfeits being used.  I should get two more from different sources and do some comparative testing.

[FreddyVictor]

oh right, I just set CS pin hi after reading the screen data, seems to work.
I also do lots of screen reading, currently have a ram buffer of 32Kbytes

BTW, I have 3, all different sizes and from different sellers (AFAICR)

currently run SPI bus @ 21MHz, any faster & it becomes less reliable, but this is with hookup wires so not an ideal setup!

[amyk]

maybe there's some not-quite-perfect counterfeits being used

The command set has been around for a long time, this is known as a "wide Philips" controller and originated around the time of the PCF8833 and the widespread Nokia LCDs, if not earlier. I wouldn't be surprised if what claims to be an ILI9341 is actually something very similar, e.g. a Sitronix ST7787.

[madires]

Are you sure it's an ILI9341? The ILI9341 and ILI9342 are very similar but the latter is configured for 320x240 (960 x 240 outputs) instead of 240x320 (720 x 320 outputs). You can inspect the subpixel arrangement to determine what the "natural" orientation of the display is, and thus determine this.

That could be possible and would also explain the column/page issues.

[madires]

That you listed only TWO coordinates in your window makes me wonder if you've missed something.  There are FOUR coordinates in the drawing window.

Set register 0x2A with X1 and X2 where X1<=X2, then 0x2B with Y1 and Y2, where Y1<=Y2.  This defines a rectangular region, which will be filled (assuming default MAC settings) from left to right, then top to bottom.

Also, make sure you send the most significant byte of each coordinate first, then the least significant.  This is NOT how most MCUs store variables in memory, so if you attempt to send X1 by coding something like "send two bytes over SPI, beginning at the address of X1", you will not get proper results.  Swap the bytes first.

I meant the size of the address window, not the absolute coordinates. And yes, I'm doing it exactly the way you've described.

While I'm at it - if you ever try reading pixels back from the ILI9341, after reading the pixel data, you may find it necessary to toggle CS twice (to de-select then re-select the chip) before trying to issue another command.  Doesn't seem to work right if you don't, and it wasn't documented in the datasheet so far as I could tell.

Thanks for the hint!

[madires]

as for the OP, they need to post some actual code....

In this case it would complicate things, because my question is about the datasheet and not the code. I haven't checked it yet , but I think amyk is right about the ILI9342.

[FreddyVictor]

as for the OP, they need to post some actual code....

In this case it would complicate things, because my question is about the datasheet and not the code. I haven't checked it yet , but I think amyk is right about the ILI9342.

pretty sure it would clarify that OP is doing it correctly !

as Sherlock Holmes would say
eliminate the impossible ..... and what remains must be the truth
 

[Chris C]

The command set has been around for a long time, this is known as a "wide Philips" controller and originated around the time of the PCF8833 and the widespread Nokia LCDs, if not earlier. I wouldn't be surprised if what claims to be an ILI9341 is actually something very similar, e.g. a Sitronix ST7787.

That's good to know, thanks!

[madires]

Sorry for that late update, I was quite busy. I can confirm that it's an ILI9342, and not an ILI9341 as I was told. Thanks for your help!