Hi, Due to the recent clock changes (https://github.com/roboterclubaachen/xpcc/commit/4b67b08ffddeb608df3d90c0595...) there are now conflicts between develop and feature/stm32f103_support_experimental, so now I'm not even able to easily merge the new changes. Now that it's easier to manually configure the clocks, I think it would make sense to add the device and linker files (and whatever else is needed) for stm32f103 to develop, so it can be used without experimental features (but for now only with manual clock config). What are your thoughts? Antal
Hi Antal,
Due to the recent clock changes (https://github.com/roboterclubaachen/xpcc/commit/4b67b08ffddeb608df3d90c0595...) there are now conflicts between develop and feature/stm32f103_support_experimental, so now I'm not even able to easily merge the new changes.
Yes, sorry, that was kind of unavoidable. I had to modify the clock control changes so they work with the other chips and the old system clocks as well.
Now that it's easier to manually configure the clocks, I think it would make sense to add the device and linker files (and whatever else is needed) for stm32f103 to develop, so it can be used without experimental features (but for now only with manual clock config).
What are your thoughts?
That’s exactly the plan! :-) I want to cherry-pick and amend the commits from the experimental branch to a separate feature branch and then add an example for the NUCLEO-F103 with the manual clock config in `Board::initialize()`. It might take until the weekend though, so if you already have a feature branch with F103 support by then, I will use that. Cheers, Niklas
participants (2)
-
Niklas Hauser
-
Szabó Antal