Arduino TFT libraries compatibility

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

Re: Arduino TFT libraries compatibility

Post by ChrisMicro » Tue Jul 04, 2017 1:46 pm

Then I remembered https://xkcd.com/927/, and dropped the idea.
Yes, it is always a problem with standards. But despite of this yoke, standards do exist.

One type or standard is the standard designed from people sitting around a green table:
all fantasies are included and every one has problems implementing it over the next ten years.

Other standards evolve during time: Their sheer number will lead to declaring it at some point as standard.

From a point of Arduino-view I would say: close to a standard is Adafruit-GFX and its drawing functions and probably the best way to adapt written software is to write small classes which David calls "glue" and I call "wrapper".
Efficiency might be a problem.

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

Re: Arduino TFT libraries compatibility

Post by david.prentice » Tue Jul 04, 2017 2:46 pm

C++ Compilers are pretty clever. I would not worry too much about efficiency. It is seldom noticeable.

Templates and inheritance works slightly differently.

I have got to a stage where MCUFRIEND_kbv has so many initialisation sequences that it is significant on a Uno.
Which means that the "less common" controllers are conditionally supported. So you no longer have the situation where "anything" will plug and go.

Olikraus has a better system with u8glib. But you have to know exactly what hardware you have before you write the constructor.

Hey-ho. At least STM32 has more Flash to play around with.

I do think that it would be wise for Libraries to run on different platforms. i.e. make it painless for a Mega or Due program to work out of the box on STM32. Ok, you will always have a lowest common denominator but no one minds if an extra "bell or whistle" needs the bigger Flash or faster CPU. Just as long as the basics work.

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:01 pm

I got to make your library work on my F411, but I had to #define STM32L476xx and ARDUINO_NUCLEO_L476RG in top of mcufriend_shield.h.

It will be a pain if every nucleo board needs to be spelled out one by one. (plus had to add one more WR_ACTIVE; to WRITE_DELAY to not have corrupt screen. what joy)

hyperion
Posts: 2
Joined: Wed Nov 29, 2017 8:37 am

Re: Arduino TFT libraries compatibility

Post by hyperion » Fri Dec 15, 2017 4:43 pm

hello!
why not use native Adafruit_GFX instead Adafruit_GFX_AS?
i try change in Adafruit_ILI9341_STM.h
#include <Adafruit_GFX_AS.h> to #include <Adafruit_GFX.h>
and everithing work fine with custom fonts.. maybe I do not know what? :)

User avatar
mrburnette
Posts: 1894
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Arduino TFT libraries compatibility

Post by mrburnette » Sun Dec 17, 2017 11:18 pm

I do think that it would be wise for Libraries to run on different platforms. i.e. make it painless for a Mega or Due program to work out of the box on STM32. Ok, you will always have a lowest common denominator but no one minds if an extra "bell or whistle" needs the bigger Flash or faster CPU. Just as long as the basics work.
Ever had to port or make a change to one of those multi-platform libs? I will summarize my feelings: P.I.T.A. Your worst nightmare.

This is an advanced forum, so unlike Arduino.cc where "libraries are the backbone of Arduino"; libraries here are more of a luxury ... a few often needed libs were originally ported to assist the community, but simple libraries are best just written as a separate TAB in the ArduinoIDE.

If you want to excel at programming and extend your understanding of physical sensor interfacing, just write functions needed such as Init as a separate Tab ... extend each Tab to include related functions. New sensor? New Tab. Easy to follow. Easy to reuse. Easy to evolve without breaking past usages. Easy to ZIP for backup or publishing.


Ray

Post Reply