Support user replacement of default font table

[jgoossen851]

The methods that print characters and strings to the LED segments already support custom fonts to be used. However, unless all the optinal parameters are given at each call, the TM16xx display module will revert to the default font for subsequent display calls.

This commit allows the TM16xx display's default font to be replaced by a user-defined font table. The TM16xx class is able to setup it's default font at construction or the default font can be changed on the fly using the new setDefaultAlphaFont() and setDefaultNumberFont() methods. Internal member variables store pointers to the custom font tables in use, and the default font tables will be used if no custom font table is given.

[maxint-rd]

Hello @jgoossen851 , thank you for your contribution. As soon as I can find some spare time I will review this PR. (Unfortunately doing paid work and other responsibilities take precedence).

From what I saw it looks like a useful change. Can I ask for what kind of hardware you needed this change? (what chip, what display module, what processor, etc.?)

One consideration I still kind of struggle with when adding features is how to keep the base class small. Reason is that I also want to support smaller processors, such as the ATtiny44A and CH32V003, which I've used in many of my TM16xx projects. I mention the latter in particular since I experienced that its 32 bit-code seems to be less compact than code for the 8-bit processors.
So far my approach so far is to leave parts out when using smaller processors, but this is a bit cumbersome...

[jgoossen851]

Thanks for considering this feature! My current project uses the TM1638 LED & KEY module (8 7-seg digits, 8 red LEDs, 8 buttons). I'm compiling it for the Arduino Nano (ATmega328P).

I totally agree with your concern about keeping the base class small. I do not have an ATtiny44A set up to easily test with (or other microcontrollers at the moment), so my testing coverage is currently limited. I tested compilation against both the base and modified TM16xx library on a few sketches, and the global variables increased by 20 bytes with the new feature (program size varied by a few bytes too, sometimes increasing, sometimes decreasing).

I am already using the TM16xxDisplay class to be able to display integers over 32767 using all 8 digits, so if desired, I could look into implementing replacement of the custom font only for the TM16xxDisplay class, leaving the TM16xx class unmodified. I could also look into editing this PR to only add the capability for custom font replacement if TM16xx_ENABLE_CUSTOM_FONTS is defined true, leaving the TM16xx class essentially unchanged if TM16xx_ENABLE_CUSTOM_FONTS is undefined.

[maxint-rd]

Hello again, Are you familiar with the Wokwi simulator?
I've used it to demonstrate some examples, such as this TM1637 example on an Uno. If I remember well, the ATtiny85 is also available in the simulator. I find it a very useful tool to test things, but I'm not sure if you can use it to test a modified TM16xx library.

At the moment I haven't yet had much spare time to look into your PR. For now I think using an optional define is okay (I've used that myself for certain implementation alternatives). Using the TM16xxDisplay class is perhaps the best choice for any addition, in order to keep the base class small. The original library by Ricardo Batista had all functions in the base class, which I moved to TM16xxDisplay to make the base class smaller.