Arduino TFT libraries compatibility

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

Re: Arduino TFT libraries compatibility

Post by stevestrong » Thu Jun 29, 2017 8:36 am

Regarding the touch, some TFTs have the resistive touch pins on different display data pins. The best modality to find out on which display pins is mapped the touch is to measure effectively the resistance between different pins.

I can imagine a thin wrapper layer between the touch lib and user API which could unify the resistive with capacitive touch.

ChrisMicro
Posts: 308
Joined: Fri Mar 24, 2017 4:51 pm
Location: Germany

Re: Arduino TFT libraries compatibility

Post by ChrisMicro » Fri Jun 30, 2017 4:46 pm

daniel wrote
You are limiting yourself waaay too much with those adapters.
I don't know what the best way is.
For instance id you just take the Adafruit_ILI9341 examples:

Code: Select all

  tft.fillScreen(ILI9341_BLACK);
But in the F746 driver all colors are defined like

Code: Select all

  tft.fillScreen(LTDC_BLACK);
and nothing fits together. Therefore the adapters or wrappers are useful.

In the Flappy-Game with I hat to edit all color definitions which seems to be a lot of unnecessary work.

ChrisMicro
Posts: 308
Joined: Fri Mar 24, 2017 4:51 pm
Location: Germany

Re: Arduino TFT libraries compatibility

Post by ChrisMicro » Fri Jun 30, 2017 4:54 pm

stevestrong wrote
I can imagine a thin wrapper layer between the touch lib and user API which could unify the resistive with capacitive touch.
Yes, good idea.
It is probably the best to seed the ILI9341 resistive touch API as standard and to make for all other touch screens a conversion layer.

User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Arduino TFT libraries compatibility

Post by Pito » Sun Jul 02, 2017 12:13 pm

Except GUI compatibility there is an issue with "low level" TFT interfaces drivers.
For example Steve's nice 8bit stm lib uses 8bit approach across his library. So not easy usable for 16bit..

Q to experts: why we cannot create a "low level driver layer" for adafruit/utft/whatever lib, where the "DATA BUS" (8/16/SPI/I2C) will be accessible via 2 single functions/methods called for example:

Code: Select all

uint8_t Write_TFT_Data_Bus(uint8_t mode, uint8_t parH, uint8_t parL);
uint16_t Read_TFT_Data_Bus(uint8_t mode);
where
mode = SPI or 8bit or 16bit or I2C, and
parH, parL are the usual high and low bytes (not nibbles as called in Steve's lib) of the command/data.

And we also need a few simple macros like

Code: Select all

#define TFT_Pulse_WR
#define TFT_Pulse_RD
#define TFT_DC
#define TFT_RS
#define TFT_Pulse_RESET, 
#define TFT_Enable_CS
#define TFT_Disable_CS
to define.

So with those only 9 elements, which needs to be adjusted according to the MCU and TFT interface used we can cover any architecture and TFT display interface easily.
Last edited by Pito on Mon Jul 03, 2017 9:18 am, edited 1 time in total.
Pukao Hats Cleaning Services Ltd.

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

Re: Arduino TFT libraries compatibility

Post by david.prentice » Sun Jul 02, 2017 12:59 pm

Be realistic. No one is going to change from 8080-8 to 8080-16 at runtime. Likewise, you are not going to change from SPI to parallel at runtime.

There is nothing much that changes from a high level point of view. e.g. drawCircle(), fillScreen(), ...
even readID() or writecommand() is the same at high level.

In other words, you choose your wiring and interface. Your decision is known at compile-time.
The binary that you have built will only run on a correctly wired TFT.

Adafruit did a brilliant job of providing Adafruit_GFX library. Arduino provided Stream and Print classes.
Authors of TFT libraries (or OLED, GLCD, ...) simply provide the hardware methods.
Punters can port a program from Steve, Adafruit, Bodmer, Marek, ... almost painlessly.

Yes, there might be small syntax differences between pushColors(), pushColor(), begin(), ...
In an ideal world, they would be identical.

I have just considered the "popular" GFX style libraries that inherit (or mimic) classes.
An argument could be made for the UTFT approach. i.e. no inheritance, unintuitive methods.

Oh, most TFT libraries make the lowest level methods private. Some might be protected. Very few are public.
Note that you can modify/glue different behaviour or extra methods by extending an existing TFT class. And have access to protected variables and methods.

David.

ChrisMicro
Posts: 308
Joined: Fri Mar 24, 2017 4:51 pm
Location: Germany

Re: Arduino TFT libraries compatibility

Post by ChrisMicro » Sun Jul 02, 2017 3:20 pm

I think "compatibility" in an Arduino context means that a software can easily ported from on to another platform.

The best is probably to port a demo to another platform like this tetris then you can see which problems may arise.

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

Re: Arduino TFT libraries compatibility

Post by david.prentice » Mon Jul 03, 2017 8:01 am

Yes, I see your problem(s).

I inserted an ILI9341 SPI display on a 3.3V "Uno".
I installed ILI9341_t3 with the Library Manager. It does not support the fonts.

So I removed the ILI9341_t3 library and built for a Teensy3.2.
The Teensy installs several popular libraries that have been tweaked for Freescale. This makes them incompatible with regular Arduinos.

In other words, the whole Arduino principle is violated.

Having said that, most ILI9341_t3 methods are fairly portable. But as soon as you start hacking, everything falls down.
In my personal opinion, it is fine for PJRC to add extra features that are specific to Freescale but they should maintain compatibility with the standard Arduinos.

Your particular example combines some specific bits of hardware. And you get a similar situation. i.e. the MapleCore variety for STM32 contains special hacked libraries.
I would be a lot happier if the STM32 support was merged into the main popular libraries. Then a punter could install "ILI9341_t3" with the Library Manager. And it would work with Arduino, STM32, Freescale, ...

I am not particularly interested in a "Tetris" game. I do not possess any sound hardware.
But it should be fairly straightforward to port the TFT graphics code.

David.

User avatar
Pito
Posts: 1593
Joined: Sat Mar 26, 2016 3:26 pm
Location: Rapa Nui

Re: Arduino TFT libraries compatibility

Post by Pito » Mon Jul 03, 2017 9:08 am

Be realistic. No one is going to change from 8080-8 to 8080-16 at runtime. Likewise, you are not going to change from SPI to parallel at runtime.
I do not think of a "runtime change", of course.
But I think changing an interface (there will always be an effort needed with init the specific tft controller and mcu's perihperals, sure) ie. from 9341-8bit to 9341-16bit or to 1289-16bit, or from 1289-16bit to 7735-SPI or to 9341-SPI shall be at the "hw interface bus level" much easier to do. Look at the way people do it today. And you need only two methods/functions..
Again, I do not comment on tft controller's specific internal video features here.
Pukao Hats Cleaning Services Ltd.

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

Re: Arduino TFT libraries compatibility

Post by david.prentice » Mon Jul 03, 2017 10:57 am

Look at my MCUFRIEND_kbv library. There is only one spot that is conditional for 16-bit or 8-bit interface. And that is the optimisation for fillRect() i.e. write 16-bit data bus once, wobble the /WR line many times.

Yes, the low level macros for the interface get messy when you have SPECIAL wiring.
But if you have a regular Shield and regular Arduino, the wiring is fixed.

I have my own ILI9341_kbv, ILI9163_kbv, HX8347D_kbv , ... SPI classes. They use the same methods. You just change one include and one constructor to run the same sketch on different hardware.

And I can often port some "foreign TFT library" sketch with little more than a GLUE class.
For example, I compare my standard "graphictest_kbv" sketch by running it with other libraries e.g. ILI9341_t3

It is easier to "GLUE" to a class you are familiar with than to try and rewrite someone else's sketch (or library).

David.

danieleff
Posts: 336
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Arduino TFT libraries compatibility

Post by danieleff » Tue Jul 04, 2017 6:36 am

I once wanted to do a c++ template based one, where the protocol, the chip driver where just templates.
It was something like:

Code: Select all

Display<PROTOCOL_ILI9341<ARDUINO_STANDARD_SPI_CS_DC>> tft1;
Display<PROTOCOL_WHATEVER<DRIVER_PARALLEL16_OPTIMIZED_FOR_STM32>> tft2;
You could change the protocol / driver to other "optimized" versions, different hardware connections, or fallback to the standard arduino. Mix and match like Lego.
You don't have to copy/paste the display commands every time.
Because of templates, it would compile really well. Could easily use multiple displays (not that anybody would do that). No need for #ifdef, because you just don't include the not used drivers, so will not compile (.h files).
Then I remembered https://xkcd.com/927/, and dropped the idea.

Post Reply