I have raised the issue about what core we should be using, on several occasions, but no one seemed interested in trying to write a new core until @sheepdoll got involved,
I did look at Koduino and MakerLabMe ( see my other postings), but neither of them were particularly usable as a whole, for different reasons.
I think Koduino has some libs, which could probably be pulled over and converted to @sheepdoll's core.
And moving to a new core probably something that the community, needs to actively work on.
Unfortunately I'm really busy with work at the moment, on 3 or 4 simultaneous projects, and I dont have time to do much but maintenance on the current cores ;-(
Many of us members probably have some apprehension as we realize that building a core using vendor tools for low-level functionality is a 2-edged sword:
1) We benefit from the expertise of the company that designed the chip and wrote the reference manual,
2) We find ourselves beholding to the chip company for backward compatibility across a product line: understanding/accepting that retired products can seriously disrubt supportability under the Arduino umbrella.
Just to remind myself and other readers, this forum is titled: STM32duino.com
and I personally have some concerns that HAL/MX is both yin & yang. The Arduino layers of core, libraries, and user-code could easily break with the next+best version of the HAL/MX strategy. But, the STM32Fxxx product line is complex and manual core development is slow and error prone - we are not in the simple 8-bit world here. Knowing this, we still have to provide guarantees to library developers that this essential and often unappreciated work will not be disrupted by STM (in this specific case.) This could be an interesting balancing act.
If we are not careful, we may find ourselves beholding to STM just as some of us are beholding to Microsoft in the workstation OS space with XP unsupported, Win Vista no longer mainstream, Windows 7 no longer mainstream, ... you can see a pattern, surely.
Opinion by Ray