Arduino for STM32

Phono wrote: Thu Apr 23, 2020 6:31 pm ...
I reported an issue in the github of stevemarple, the author of this library, but it seems that he is not involved any more in this section. So I put it here, to open a discussion about the best way to fix it....

You have done what is appropriate, reported an "issue" to the library author. In the spirit of Open Source, the author can elect to act on your (STM32-centric) concern or simply ignore you as it may be that the code posted is working fine for his/her intended use.

You have the choice of branching the code into your github and fixing same for STM32. You could also just "fix" the code for your personal use, either in /Arduino/libaries or simply embed the .h/.cpp into 2 tabs of your ArduinoIDE sketch. You could request the original author to pull your github changes to broaden the usefulness but some authors may refuse as the maintenance effort would generally necessitate procurement of test hardware. If you maintain a "STM32-centric" github, are your intents to maintain the code across all hardware listed as STM32duino? Big effort, perhaps.

Fact is, open source code carry limited (very limited) on post-release maintenance. The author may or may not accept patches and enhancements.

My "Ray" take on all of this is to be totally self-sufficient. I take what is available and "bend" it to my needs. I have years worth of modified Adafruit code in numerous sketches across multiple microcontroller projects. My project folders are organized something like:

Arduino/RaySketches/STM32F1/MapleMini/GPSclock-Barometer/LCD/ILI9341/SketchName/SketchName.ino
Arduino/RaySketches/STM32F1/MapleMini/GPSclock-Barometer/LCD/1602/SketchName/SketchName.ino
Arduino/RaySketches/STM32F1/MapleMini/GPSclock-Barometer/LCD/I2C_Oled/SketchName/SketchName.ino
Arduino/RaySketches/STM32F1/MapleMini/GPSclock-Barometer/LCD/SPI_Oled/SketchName/SketchName.ino

Every one of those running programs are fully working and copies of the appropriate 3rd libraries exist in every local folder. Hard drive storage is cheap and ASCII code compresses to a nice, small backup. If I write an article to publish, I know the required libraries are in the published ZIP.

My next need for a MapleMini project with SPI OLED is half-written.

Ray

I certainly would not issue a pull request without having very carefully thought of the fix to be done, and without having checked it. In this case, I admit it could be helpful to everyone, since the bug is not related to a certain type of microcontroller. What I think is just that I did a test that the author did not think of. Since the consequences are not acceptable to me (a crash of the whole board, for a single function at fault), I cannot leave it as it is.
I will definitely provide a fix of my own, but unless the author is interested in it, I will not publish it.

The author should first see what changes do you suggest in the code, then he can decide whether to merge or not.
I think the first step would be for you to make a suggestion what to change. I assume you already implemented a workaround which did the job. Why not share it? This would be in spirit of open source.

In the description of the issue, I suggested two ways to overcome it. I thought that the author would have a preference of his own, and I wanted to wait for his advice before going any further. On my part, I (at least temporarily) have implemented the easiest way that fulfils my needs.