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);
}
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
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!
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);
}

[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.
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 > (...)
Can you post a picture of your LCD board? Maybe is different from my one.
Compare:
https://www.aliexpress.com/item/240×320 … 43434.html

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?
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
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.
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