Slammer wrote:Can you say more about the status of your cubeMX core?
The core , If it could be called that, basically was a way of structuring the variants folders to float over the HAL layers. This way all the IFDEF nightmare is inside the HAL libraries. I retained the Maple headers which expose some of the core functions for flavoring processing and wiring. I got it far enough to do some of the wiring digital I/O and some of the serial stream. This was all about 6 to 10 months back.
Most of what has been done has been proof of concept.
I structured it so that each variant has it's own branch folder. The cube .ioc is inside the version control. In my case I have a number of example boards. Mostly Nucleo, some discovery. I have not pushed back much to the github as they are more abstract tests than actual examples.
I primarily work with Mac and OS X, so I was looking for a way to program these boards using the provided tools that were in the STM32 folder. the bulk of the work was in the board file and others to isolate the different hardware platforms.
This had the added benefit to parallel the build paths so that the "project" can be edited and debugged with eclipse. This is more for debugging libraries and glue code.
Another benefit, as Setup() and Loop() are called from the Main generated by the CubeMX program, is that the HAL APIs can be directly called in a sketch. MX seems to be fairly robust in retaining this code when regenerating. It does add a layer of complexity as the peripherals are instantiated by the MX tool prior to setup being called, So things like setting baud rates bit depths and pin states are redundant in the sketch proper. One still does have to call *.begin to create the processing structures (which are for the most part simply C++ classes)
At the same time I am also learning more about the arduino world. As an advanced AVR programmer I had dismissed the Arduinos. Now I am starting to understand some of the mindset behind it.