ILI9341 weirdness in rotation

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In writing an assembly language variation using the ILI9341 of a working HX8357B terminal emulator I am experiencing some weirdness in the rotation control known as MADCTL.

 

The screen is defined in cells of 8x16 pixels.   There are 40 columns by 16 lines of text that is buffered in sram.  The Sram points to the character generator in flash.  The SRAM address also determines the display address that is sent to the address window of the TFT.

 

Here is the weird part.  The display is configured landscape MADCTL = 28.  When cells on the left side with an X or column address greater that 0x100 are smashed into a line on the right side.  If the address is less than 0x100 then the character displays as expected.  Now if I set the SPI speed doubler on for a faster redraw, then the effect is reversed.  With the 2Xbit,  the cells addressed over 0x100 are drawn and the right side is blank.   Changing the SPI speed to a lower speed, the weirdness persists.  Behaves one way with the SPI2X off and the other when it is on.  Single stepping through the SPI transmissions makes no difference.

 

In some ways it looks like the display clipping is swapped.  Yet changing the coordinates, the data does not seem to write into the expected area.

 

I have looked at a bunch of Drivers, they all seem to derive from the ADAFruit one.   It is after 2AM and this has been blithering me for the last few hours.  If it is something wrong in the clipping region setup, then why does changing the SPI speed make it fail in a completely different way?

 

 

 

 

 

This topic has a solution.
Last Edited: Sun. Mar 4, 2018 - 08:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've never done much with these displays so don't take my advice too seriously.

You've been warned.

 

I've heard vague rumours that different TFT controller chips have different bug's.

On some you can rotate the display when writing, but when reading your data it's never rotated...

But that may also be a bug in the driver software. You may need to configure different registers to also read the data back rotated.

 

"Rinkydink" aka Utft is a driver different from Ada fruit's.

There are also some open source drivers for the "mbed" platform, and though "mbed" is for ARM processors most of the code is written in C and pretty portable.

 

Also if you look at small linux boards such as the Odroid from hardkernel you also see small TFT's. Maybe you can trace that back to some (open) source code.

 

If you go to the sites of the vendors of commercial C compilers for avr's you'll notice those compilers often come with libraries for TFT lcd's.

Manucacturers of TFT's of course also have drivers for the display's they sell. You can find them easily by following links from Mouser / Digikey / Farnell / RS / etc.

Octopart is a search engine for electronic parts. You might have success there:

https://octopart.com/search?q=tft%20lcd&start=0

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rotation on a ILI9341 works fine.   i.e. just like any MIPI-compliant controller should work.

 

When you change the MV bit,   you change the window coordinates too.

Which means that you can continue to use logical coordinates e.g. X as 0..319 and Y as 0..239 in LANDSCAPE versus X as 0..239 in PORTRAIT

 

No,  not all libraries work the same.    UTFT has no concept of intelligence.   "Some" Adafruit implementations do not use MADCTL properly.

 

A nice pot of tea at breakfast will make everything clear.

 

David.

Last Edited: Sun. Mar 4, 2018 - 11:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you adjusting the ILI9341 Column Address Set and Page Address Set registers for each 16x8 block?  Or are you setting a single entry point in the display RAM of the 9341 and simply sending data and letting the controller place it at the right screen location?

 

The Adafruit TFT drivers write the Column and Page addresses with each pixel write, along with having the frame size is set for one pixel.  This approach makes them robust, but rather slow.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A few hours sleep and a cupa tea, and I found the bug.

 

Most of the assembly code is converted from 8080.  I mapped the 8080 registers to the upper registers 25 through 30.  There is a nice overlay of the index registers where X maps to BC, Y to DE and Zto HL.  The only caveat is that while A maps to r24, r25 maps to the flag register.  So in the 8080 code I use r25 as a trampoline to  push or protect the carry flag in the emulation macros.

So when I went to use a register in the SPI code I decided to use r25 as it was handy and pushed  the stack and protected.

 

The gotcha is that I also use r24:r25 as a pair which I call ACC in most of my code over the last 20 or so years,  So my incrementer for the column address set, was pointed at ACC using an adiw instruction following a multiply of the screen cell coordinates.   Since R25 got set to the state of the SPSR register after the first command write,  This meant it was usually 0x80. When the SPI2X was set it was 81.   The ILI9341 can be set to ignore out of bounds addresses (probably for window scrolling)  So this is why it was acting so weird.

 

I found the problem when I attempted to simply fill the screen with a background rect.   The loop never exited as the column index was never less than 0x80.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Porting ASM from one CPU to a very different CPU seems a bad idea.

 

But at least the tea helped !!

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

 

How did the changing of the SPI speed change the result on the screen?....Scary!!

 

Does the changing of the SPI speed still change the results on the screen!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jporter wrote:
Most of the assembly code is converted from 8080. I mapped the 8080 registers to the upper registers 25 through 30.

 

Is that you Mel???

 

https://www.avrfreaks.net/comment/reply/366001/2423441?quote=1#comment-form

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

Last Edited: Fri. Mar 16, 2018 - 01:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mikedb;

Not sure I follow the question as to changing the SPI speed.  Changing the speed affects something called persistence of vision. What makes motion picture films work.  If it is too slow one sees the refresh update.  I think this relates to Nyquist sampling which is Alising when there is not enough data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

jporter wrote:
Most of the assembly code is converted from 8080. I mapped the 8080 registers to the upper registers 25 through 30.

 

Is that you Mel???

 

https://www.avrfreaks.net/comment/reply/366001/2423441?quote=1#comment-form

 

cute story.  I think Atomic Zombie has us all beat when it comes to ASM code.

 

As for my project it is now mostly working.   An example of machines programming machines.  The translation is done in postscript. (Yest the printer page language.)  There are a few places where the code has  to be tweaked due to status flag mapping.

 

-jP