[SOLVED] Adafruit_ILI9341_STM – hardware scrolling broken

Hello,
I don’t know much about the changes in this library for ~ 2 years, but sadly hardware scrolling is totally broken:

It was easy to set it up with:

//new scroll commands
#define ILI9341_VSCRDEF 0x33
#define ILI9341_VSCRSADD 0x37
void scrollAddress(uint16_t VSP) {
tft.writecommand(ILI9341_VSCRSADD); // Vertical scrolling start address
tft.writedata(VSP >> 8);
tft.writedata(VSP);
}

void setupScrollArea(uint16_t TFA, uint16_t BFA) {
tft.writecommand(ILI9341_VSCRDEF); // Vertical scroll definition
tft.writedata(TFA >> 8);
tft.writedata(TFA);
tft.writedata((320 - TFA - BFA) >> 8);
tft.writedata(320 - TFA - BFA);
tft.writedata(BFA >> 8);
tft.writedata(BFA);
}

hi Matthias

FYI

There are some open PRs and discussions about bringing the graphics library up to date, which may partially fix this.

And there is also a discussion on GitHub about the problems with the graphics library functions leaving the SPI bus in 16 bit mode, which may also be the cause of this problem.

I think everyone is happy with the solution to update the graphics library and keep backwards compatibility, but there is not a consensus on leaving SPI in 8 bit mode, as this slows down the graphics library if it has to switch to 16 bit and then back to 8 bit for a lot of the functions

Also people are not convinced that 8 bit should be the default mode for SPI, but I have compatibility problems with libraries which assume AVR style SPI which AFIK does not have a 16 bit mode

Hi Roger!

Ok, it was also my fault, because I didn’t implement the HW-scrolling functions in the library in the past. So I still think these functions got lost (and/or forgotten).
—> Solution next post, thanks for the right hint, Roger!

Ok, this was just easy, solved!

New code:
void scrollAddress(uint16_t VSP) {
tft.writecommand(ILI9341_VSCRSADD); // Vertical scrolling start address
tft.spiwrite(VSP);
}

void setupScrollArea(uint16_t TFA, uint16_t BFA) {
tft.writecommand(ILI9341_VSCRDEF); // Vertical scroll definition
tft.spiwrite(TFA);
tft.spiwrite(320 - TFA - BFA);
tft.spiwrite(BFA);
}

Well, you see @madias, 16 bit mode has its advantages , everything is much more simple to code…

[stevestrong – Fri Mar 23, 2018 10:29 pm] –
Well, you see @madias, 16 bit mode has its advantages , everything is much more simple to code…

I see it, steve
Just gossip: Now I can remember, why I (and everyone) didn’t work with HW scrolling:
First: The function is quiet useless, because moving the area is “relative”, so you won’t be able to scroll 1px left and put the new output to x=319, because the most right position is now “0” – so it’s not “fire and forget”.
Second: HW Scrolling is very ugly, because of the display refresh latency.

Gossip #2:
I now have found the perfect code/library for the XPT2046 touch-display-driver:
https://github.com/PaulStoffregen/XPT2046_Touchscreen
It works with IRQ and pressure measuring so you can easily set an offset and no more interpolations (getting at least 10-20 samples without too much errors) are needed.
https://github.com/PaulStoffregen/XPT2046_Touchscreen
Works out of the box.

[madias – Fri Mar 23, 2018 10:48 pm] –
I now have found the perfect code/library for the XPT2046 touch-display-driver:
https://github.com/PaulStoffregen/XPT2046_Touchscreen
It works with IRQ and pressure measuring so you can easily set an offset and no more interpolations (getting at least 10-20 samples without too much errors) are needed.
Works out of the box.

Thanks for letting us know.
I’ll try it when I have some spare time.

with this library start with this code:
if (ts.tirqTouched()) {
if (ts.touched()) {
TS_Point p = ts.getPoint();
xaxis = map(p.x, 251, 3731, 0, 320);
yaxis = map(p.y, 257, 3803, 0, 240);
if (p.z > 1200) < do something > (...)

I had no problem accessing the SD card in the on-board slot of LCD.
Can you post a picture of your LCD board? Maybe is different from my one.

As I can see, that the actual 2.8 touch ILI9341 are slightly different as mine:

Compare:
https://www.aliexpress.com/item/240×320 … 43434.html

The SD-Card resistor R1-R3 are 102, so 1k.

I just checked my board, it seems that i have replaced those resistors with wires and it works .

You hit the point, Steve!
I bridged all SD card resistors and the onboard 3.3V regulator and it worked!
The circuit is really weird, not really 5V (because of 3.3V only TFT data inputs) and too much circuit for 3.3V. Only the “designer” know the secret about that….
Now I’m testing all devices (TFT, SD-Card, XPT2046) on one SPI port. It’s really nasty adding all those extra lines you posted in another thread:

[stevestrong – Fri Mar 23, 2018 10:50 pm] –
There is a PR on GitHub about the problems with the graphics library functions leaving the SPI bus in 16 bit mode, which is most probably the cause of this problem.
You can try to execute
SPI.beginTransaction(SPISettings(18000000, MSBFIRST, SPI_MODE0, DATA_SIZE_8BIT));

[madias – Sat Mar 24, 2018 11:14 pm] –
It’s really nasty adding all those extra lines you posted in another thread…

Well, if you group the LCD related routines in one function, you call one beginTransaction() at the beginning and the other at the end of that function. Is that really sooo nasty?

Guys

I did the same thing with the SD card interface, unsoldered the resistors and replaced by small pieces of wire.

Also supplied 3.3V to the output of the regulator ( I think ) . Or I may have ended up feeding the board with 5v as I used a Blue Pill, and reconfigured it to use the regulator on the display board.

I would need to check the hardware I made for the OV7670 camera module, as I used the SD to save images from the OV7670

Here is the circuit draw of the MCU-Friend ILI9341:
https://drive.google.com/file/d/1AsquTx … sp=sharing

It’s also totally unclear if we need a small resistor for the LED-backlight. For my logic I would say we need one because it’s not in the schematic, but even with low resistance (~40) the display is too dark.

I suspect these boards were constructed (designed is too nice of a term) during the old days of Arduino when 5.0 Volts was the defacto standard. The old AVR chips could sink and source significantly more current so the series resistors and stray capacitance did not significantly screw with the waveforms. That is not true of uC’s that are 3.3V by design.

When I salvage old logic boards and scrap them, I use my hot-air station to recover 0 Ohm SMT resistors. While little nips of wire work, the short-resistors look far better… if that matters!

Ray

The SPI ILI9341 LCD that I have doesn’t work with Arduino at 5V (they are all white) but works with STM32 at 3.3V despite that they were announced as Arduino compatible. I never tested the SD card adapter but I believe that I have the resistor too.