What to do with Adafruit_GFX_AS

Well, this is not the first time the issue has come up (see e.g. here: viewtopic.php?t=1040): Some graphics drivers in the stm32duino world are based on “Adafruit_GFX_AS”, some on the upstream “Adafruit_GFX”.

As far as I understand, the motivations for adding Adafruit_GFX_AS were:

• There used to be some incompatibilities between Adafruit_GFX and STM32. I have no idea what those were, but to my knowledge these are resolved in Adafruit_GFX, by now.

• Adafruit_GFX_AS added some functions, esp. for font-handling, before Adafruit_GFX had anything the like. However, by now Adafruit_GFX has seen a lot of development that has not been merged into Adafruit_GFX_AS, including (a different and more flexible implementation of) font-handling..

Now the latter means that simply ditching Adafruit_GFX_AS would mean breaking existing projects. However, keeping Adafruit_GFX_AS, as today, means that graphics drivers are arbitrarily divided into using two different bases, even though the actual difference between these is totally independent of the hardware level.

I am thinking a way out of this situation might be to rework Adafruit_GFX_AS to

• Provide a class with a distinct class name “Adafruit_GFX_AS”

• which is derived from Adafruit_GFX

I.e. essentially:
class Adafruit_GFX_AS : public Adafruit_GFX {
public:
Adafruit_GFX_AS(int16_t w, int16_t h);
int16_t drawUnicode(uint16_t uniCode, int16_t x, int16_t y, int16_t size);
int16_t drawNumber(long long_num,int16_t poX, int16_t poY, int16_t size);
int16_t drawChar(char c, int16_t x, int16_t y, int16_t size);
int16_t drawString(char *string, int16_t poX, int16_t poY, int16_t size);
int16_t drawCentreString(char *string, int16_t dX, int16_t poY, int16_t size);
int16_t drawRightString(char *string, int16_t dX, int16_t poY, int16_t size);
int16_t drawFloat(float floatNumber,int16_t decimal,int16_t poX, int16_t poY, int16_t size);
};

tfried:

Wow. You give us too much credit regarding the Adafruit graphics lib. It was chosen (I believe) back in the Arduino.cc thread days; before we broke away from the mother forum.

I suspect it was selected because Ladyada generally keeps her libraries usable across a wide selection of Arduino hardware, including Teensy. Getting Teensy to work is not much different that getting STM32 to work. Therefore, I suspect that we used that library because it was the path of least resistance.

STM32duino does package a few 3rd party libraries in our ZIP download: https://github.com/rogerclarkmelbourne/ … /libraries
and these “ported” libraries are just to give a new user something to play around with that works … maybe not work well, maybe not memory efficient, maybe even with some hiccups, but you get my drift … just compile without error and basically function.

I am not the voice of the forum, there are far smarter software architects than this old corporate dog. But generally speaking, I would propose that the end-user be responsible for any enhancements to libraries and porting responsibilities. When a user does such work, the effort can be incorporated into the core library directory with a github pull request. Just maintaining the “core” files is enough work and even now we have a backlog of pull requests which have been “tested” but which really must be fully tested… many pulls in the past have had to be un-pulled and the code rolled-back.

So, bottom line and this applies to any forum reader: if you want to port a library, create a library, or otherwise add value via code or architecture or both then go-for-it… at the end of the effort, test thoroughly and perhaps post and request others in the forum test your code. When things look good, issue a pull request to Roger.

Ray

I believe I was the one first using the Adafruit_GFX_AS library.
The reasons were the ones you and Ray mentioned. At that point the Adafruit lib didn’t have support for extra fonts, and neither that or the AS were compatible with the STM32, so give the amount of work would be the same, I decided to port the AS one, which I found in some forum or instructable.
The official one has come a long way since then, so there is probably not a lot of advantage on using the AS one.

I routinely use the Adafruit official one and works just fine.
As for going forward, if the AS one is maintained in github, I would suggest you get the latest version and try it out. If it needs any chance, submit it upstream so the master supports the STM, and then we can remove it from our repo and just use the official master.
If it’s not in github, then breaking the extra functionality as an extra class seems like a good idea.

Thanks for your feedback. Adafruit_GFX_AS is not on github. In fact it pretty much seems have ceased to exist outside of stm32duino.

However, the change itself was really almost as easy to do as I could have hoped: https://github.com/rogerclarkmelbourne/ … 2/pull/461 . I did not even have to touch the implementation of the “AS” functions at all!

Tried the TFT_Clock_Digital_ILI9341 (using “AS”-functions) and the stm32_graphicstest (not using “AS” functions) examples from the ILI934_STM driver, and both seem to work as expected, as far as I can tell. The additional font payload for AS is only added to flash, when one of the AS functions is used.

More testing on real life projects would certainly be nice, so if you are a user of Adafruit_GFX_AS, please test this (for drivers other than ILI9341, simply change the base class of the driver from Adafruit_GFX to Adafruit_GFX_AS).

That’s great. I need to check if I still have any project that uses it, if so will give you some feedback.

I really like your solution, tfried — it appears to offer the best of both worlds (revised upstream functionality that is currently missing and backward compatibility to the GFX_AS additions). I will test it out against my libraries to see if any issues pop up. thanks

Just a quick update: I tested tfried’s (pull request #461) with the following:

• Adafruit_GFX_AS + Adafruit_ILI9341_STM + examples/graphicstest (Uses GFX base functionality)
• Adafruit_GFX_AS + Adafruit_ILI9341_STM + examples/TFT_Rainbow_ILI9341 (Uses “new” GFX_AS functionality)
• Adafruit_GFX_AS + Adafruit_ILI9341_STM + my GUI library (GUIslice) (Uses GFX base functionality, both original GFX font and FreeFonts)

All appear to work fine.
For reference, the following versions were in play:

• Adafruit_GFX_Library (version 1.2.3)
• Adafruit_GFX_AS from Arduino_STM32\STM32F1\libraries\Adafruit_GFX_AS (legacy)
• Adafruit_ILI9341_STM from Arduino_STM32\STM32F1\libraries\Adafruit_ILI9341_STM (legacy)

Thanks

I will test as well, as I have a project where I am using this library at the moment

I’ve tested it and it seems to work OK

@victor_pv

Did you manage to test it ?

I havent yet, but someone else posted in the PR that he tested it too. I think this one should be good to go.

It didn’t cause any problems for me with my test project config, so I think I will merge it today

Guys

Sorry for the delay

I had lots of things to merge, plus some other non STM32 projects I do on GitHub needed to be updated.

There was also some confusion about which was the latest / best PR

Can you guys confirm which PR should be merged

I have merged https://github.com/rogerclarkmelbourne/ … 2/pull/461

which I think was the latest version

My project is working fine, and it uses SPI for display and also another module (nRF905) it also uses the uTouch library as well as some other things like the hardware timers, so I think its a realistic test

Thanks…