Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Working libraries, libraries being ported and related hardware
User avatar
RogerClark
Posts: 6415
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by RogerClark » Sun Jan 08, 2017 11:11 pm

@stevstrong

I had a feeling that 72Mhz may be faster even though the transfers are slower. So it would depend quite a lot on your application, to as to whether 72 or 48 was faster

For most things, including low power operation, it usually seems to end up, that running the CPU as fast as possible is best, and for low power operation, put the processor into standby / low power mode when not processing.

(In my case of low power project, it wasn't worth the effort of going down the low power / standby method, as the programming to calculate the constantly varying sleep times, depending on the incommoding pulse frequency, ended up being very complicated, and not worth the headache for 1 or 2 mA power saving ;-)

david.prentice
Posts: 107
Joined: Wed Nov 16, 2016 8:52 am

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by david.prentice » Mon Jan 09, 2017 10:36 am

stevestrong wrote:The funny part is, some of the graphicstests (text, lines and all outlines, where many single pixel writes take place) runs better with lower SPI clock but higher CPU frequency, than vice versa. OTOH, obviously, large block fillings are faster with higher SPI clock, where the CPU frequency does not really count.
So it really depends on the application, which variant one should use.
A horizontal or vertical line is only a narrow filled rectangle. Requires virtually no maths. Can benefit from DMA.

Angled lines, curves, ... require calculations and end up by drawing one pixel at a time.
The setup statements for DMA might take as long as polled SPI since these are short data sequences.

My experiments with ESP8266 illustrate the difference for faster clock speed (calculation performance) and faster SCK speed (bus traffic). If you have a slower SCK, DMA execution is longer than the setup.

Looking at the datasheet for 74VHC595 or 74AHC595, these shift registers can be clocked much faster than the regular HC parts.

I am surprised that problems started at 28MHz since I bet that your desk is likely to be 10C to 30C. In practice, many devices are "better" than the official spec.

David.

stevestrong
Posts: 1450
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by stevestrong » Mon Jan 09, 2017 10:50 am

David, I agree that the optimal solution would be the maximal CPU freq. combined with max. supported SPI clock. Unfortunately, this is not always possible, as in case of generic F103.
My desk is at ~20°C.
The HC chips would work fine at 28MHz, the problem is rather the signal propagation delay through the ICs, not the clock frequency as such.
The higher the SPI clock, [the longer the delay] the stronger the influence of the propagation delay so that the self-generated WR signal by the 4040 chip is shifted too much relative to the output of the 8 bit serial->parallel shifting 4094 chips. This timely mismatch causes actually the trouble above 24MHz. I could maybe try to replace only the 4040 chip by a faster one, and see what happens.

EDIT
Btw, regarding your recommendation for faster shifting ICs (74VHC595), I think this is not pin-compatible with 4094, which would be a mandatory requirement.
Last edited by stevestrong on Mon Jan 09, 2017 2:10 pm, edited 4 times in total.

User avatar
Squonk42
Posts: 63
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by Squonk42 » Mon Jan 09, 2017 1:35 pm

stevestrong wrote:The higher the SPI clock, the longer the delay so that the self-generated WR signal by the 4040 chip is shifted too much relative to the output of the 8 bit serial->parallel shifting 4094 chips. This timely mismatch causes actually the trouble above 24MHz. I could maybe try to replace only the 4040 chip by a faster one, and see what happens.
Another possibility would be to adopt the solution used for the HX8352, where an RC network and 2 inverters are used to generate the WR signal:
https://github.com/notro/fbtft/issues/84

stevestrong
Posts: 1450
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by stevestrong » Mon Jan 09, 2017 1:47 pm

@Squonk42, sorry, but I don't see how this RC combination could produce a "negative" shift...
Once the signal is too much delayed, I don't think this network can bring it back couple of nanoseconds. Or do you have some simulation results which would proof the contrary?
EDIT
I think the scope of the RC is to bring the two delays (from the 4040 and from the 4094) again in sync.
According to the specifications, the 4094 has higher typical propagation delays at 25°C (CP->QPn = 63, 23, 20) than the 4040 (Clock->Q1 = 47, 17, 14). This means, the signal from 4040 must be extra delayed.
I could maybe lead the output signal from 4040 through 2 additional inverter gates (74hc04 on board).
One HC04 gate has a typical propagation delay IN->OUT of (25, 9, 7). Meaning, one gate would cover the difference between 4040 and 4094.
But I need two gates to have the right polarity of the WR signal... :(
I think I will buy an extra 74HC4050 (hex non-inverter gates), having the same delay as the 74HC04 on-board, this would equal the delays and bring the right polarity for WR.
:idea: The second inverter would compensate the delay from the first 4094 to the second 4094...maybe...
Anyway, I'll give it a try.
Last edited by stevestrong on Mon Jan 09, 2017 4:18 pm, edited 1 time in total.

david.prentice
Posts: 107
Joined: Wed Nov 16, 2016 8:52 am

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by david.prentice » Mon Jan 09, 2017 3:46 pm

Unless I have lost the plot, the rising edge of WR clocks the parallel data into the ILI9486.
The 4040 is creating the rising edge on the 16th SCK pulse.
The 4094 is shifting all bits into their final stable position on the 16th SCK pulse.

tDST = 10ns which means that you need the 4040 propagation delay to be >= 10ns beind the 4094 propagation. In other words, you would either use a faster shift register (or slower counter).
Or deliberately delay the 4040 by an extra 10ns through gates or RC.

David.

stevestrong
Posts: 1450
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by stevestrong » Mon Jan 09, 2017 4:07 pm

David, sorry, what is tDST? I couldn't find it in the specs of 74HC4040, and 74HC4094.
I was talking about tPD, tPLH/tPHL (propagation delays) between clock input and data output.
The minimum pulse width tW, which would limit the input clock frequency, are for both 4040 and 4094 around 10ns (typical value, which, I admit, can be critical since the minimum value is much worse :( ) at 3.3V, which means they should work with frequencies up to (10^6)/(2xtW) = 50MHz. So 36MHz could be theoretically, in typical case, possible.
david.prentice wrote:In other words, you would either use a faster shift register (or slower counter).
Or deliberately delay the 4040 by an extra 10ns through gates or RC.
Exactly this is what I intend to do, delay the output of 4040 using two inverter gates in series.

david.prentice
Posts: 107
Joined: Wed Nov 16, 2016 8:52 am

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by david.prentice » Mon Jan 09, 2017 5:01 pm

Sorry. tDST is the data setup time before the active edge of /WR in the 8080 parallel interface. (ST7789 nomenclature. The ILI9486 datasheet might use a different acronym)

As far as I can see, a stock HC4040 is going to produce the WR signal before the HC4094 has loaded the shift register. i.e. it will be wrong for the ILI9486 and also wrong for the HC4094 to latch the shift register.

Whereas there is a tolerance on timing values, the order of signals must be obeyed.

David.

stevestrong
Posts: 1450
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by stevestrong » Mon Jan 09, 2017 9:25 pm

OK. Forget the spec...

The scope clearly shows that the 4040 has huge propagation delay (around 40ns !!), which is an SPI clock period at 25MHz!
Thus, we should not wonder that everything above 24MHz will not work...

Now I used some of the free inverter gates from the on-board HC04 chip to delay the clock and MOSI signals with ~20ns (2*10ns, 10ns being the delay of one inverter gate), and...voila... it is getting much better.
Now at least the coordinates are correctly transmitted, which was not working before.

Still, there is one clock period delay at 36MHz between WR and data. That means, the color data is sampled as being is shifted one bit left. For example, if I want a red color (0x8000), the display controller will get 0x0001 sampled because of this one clock period propagation delay of WR edge relative to the parallel shifted data.

As a workaround, I can only imagine delaying the SCK and MOSI signals another ~20ns, using another pairs of additional inverters. For this I have to use an extra chip.

Does anyone have a better idea except an RC circuit?

david.prentice
Posts: 107
Joined: Wed Nov 16, 2016 8:52 am

Re: Lib for ILI9486 - 3.5 inch 480x320 touch TFT for RPi

Post by david.prentice » Mon Jan 09, 2017 11:37 pm

If you have got a two-channel scope, you can observe the SCK clock and the /WR latch signal.

I presume that you have the SPI set up to wobble /CS every 16 bits.
This resets the 4040 to count up to 16 again.

Or do you send a continuous SCK and just hope that the /WR latch works every 16 bits?
As long as the latch operates before the next SCK you should remain synchronised.

You should be able to put in an adjustable delay with an RC. If you feed the RC output into a buffer, it will clean up the edges.

David.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest