The System has been decided!

The search for the best tools and libraries for my application is over. This is a complete rewrite of the open-source Visual Pin Configuration application. And in doing it, I wanted it to withstand the test of time reducing the vulnerabilities as much as possible:

The Language

The first version was written in FreePascal language (using Lazarus RAD) for a couple of reasons: easy manipulation of strings (and this kind of app is all about strings), convenient GUI layout. But the Pascal compiler is not always available for all operating systems and it is also a forever evolving language, always trying to reach the same level of Delphi, the original Object Pascal compiler.

I decided to rewrite the application in C language (after researching about Go and D languages which maybe are a solution for the future) and I had to code a lot of Pascal functionality that was missing in C. At the time of writing this article, I am in full process. It is not a translation of the old code, it is a rewriting from scratch. The application compiles OK with the TinyCC (an ANSI C compiler which tries to be 100% C99 compliant) and with GCC compiler. I definitely write more code than in Pascal when it comes to strings. But C is a first citizen on all operating systems and some Linux distros provide it on their Live DVDs for offline work (in Windows you would say "portable") so, one win!

The GUI

In Lazarus I used Lazarus Component Library which clone the Visual Component Library of former Borland, it was easy and the app started to take shape very fast. But it had some disadvantages. Lack of graphical capabilities and lack of real time response. Another problem was that underneath, the LCL is based on gtk2 or qt5... work is done to advance it to gtk3 and qt6 but the process is slow and not yet usable. Some of the visual components used are depending exclusively on gtk2 and this toolkit is programmed for replacement in many of the Linux distros. Qt is also a no go because it is a fast moving target with the API changing often (many good qt4 apps are now non-usable because no one has the time, or no longer alive to translate them to at least qt5 - an AppImage executable would have helped). And its license is less helpful.

I really had to find an alternative, one that had to be portable and durable. With fewer system dependencies. And I found raylib+raygui libraries, fully graphical, OpenGL and it had also a Pascal translation - which in itself is still a backup plan. It could have been nanovg little library with Nuklear GUI, or anything OpenGL, but this one is small enough, fast and full of features, with a nice, simple and good looking GUI in immediate mode. Well, I ended up making my own controls, but that would have been the case whatever the solution. Yep, this time, fully graphical babe, with blinking LEDs all over the place! A second win.

The Driver

I started working at the first app with the intention to offer support for the ST  LowLevel API, then I changed my mind and went for the Standard Peripheral Library that was abandoned by the ST Microelectronics in favor of HAL+LL duo. It became the first app to provide a visual "configurator" for SPL...  Fast and small, with a quite small code size at compilation time (and having the advantage of keeping STM away from me). But, being abandoned, it had no support for new microcontroller families and I really longed for L4 family (today, I stare also at G0 family). In the past, I blinked some LEDs using libopencm3 open-source library and seeing that is in active development, with support for the newest families, I decided to make it the main target for my code. Even if is a new territory for me, I still have the courage to name it the third win.

Three huge challenges! And, as if it wasn't enough, I added the fourth challenge: adding support (apart from the current board) for three more boards: F072, L073 and L476. Which boards I don't have yet...

In the board selection, I made the existence of TIM6 and TIM7 an eliminatory criteria. Then, all boards had to have a similar pinout at LQFP64 level and identical pinout for the following peripherals: I2C1, I2C2, SPI1, SPI2, USART1. For this reason, F4 family (which it was proudly selected intially) didn't make it in the final, failing at the pinout of LQFP64 and I2C2 peripheral. And for this sole reason, G0 family will have its own separate application if time permit - this world is going nuts!. Really, I think that in the new world, many of the actual companies will completely disappear. With less population in the world, less financial gainings, less technology needed, less educated people... less new microcontrollers needed... So, many companies that are now willingly participating in the RESET operation are practically digging their own grave. But I digress... really?

Well. you would say that Arduino and Morpho connectors offers enough hardware abstraction between families but you have to remember that you are not allowed to use Nucleo boards in final products so, it all goes down to LQFP64 "raw" connections and for that, I favored grouped pins (identical throughout families) as much as possible. Maybe ST.M. will lift this restriction and then, let me know that...

And at the end, a rambling (or just a question?): why an STM32L4 instead of a dsPIC33EV which is fully 5V and has a DIP package being fully "hobby-able" and much MORE? Frankly? I don't know yet!!! Is this application of mine a huge loss of precious time?