2016-02-05 2:24 GMT+01:00 Niklas Hauser <niklas.hau...@rwth-aachen.de>:
> Radical idea: Forget SystemClock and configure the clock yourself.
> We did this for the STM32F072, which has the same problem of not having
> SystemClock support.
> We created a MockUp for SystemClock:
> This is used to allow the peripherals to initialize correctly, since they
> require the input frequency.
> Essentially it’s a manual representation of all the <output> tags and
> prescalers in the clock tree.
> Then configure and initialize the clock tree yourself:
> The F103 doesn’t have the HSI48, so obviously you need to adapt this.
> You don’t have to start from scratch, you may have a look at the
> Generated file for F103 (might still be wrong!, Better verify this code with
> the Reference Manual!)
> You then are free of the SystemClock dependency and should be able to just
> use the normal develop branch.
I will try this then. I still need to copy over the device description
> At 32MHz it shouldn’t compile, there are no CAN settings to choose from.
Actually, I was thinking the same. But I'm quite positive I'm running
at 32Mhz, the clock is configured like this:
using systemClock = SystemClock<Pll<InternalClock, MHz32>,
and writing out xpcc::clock::fcpu at runtimes confirms this.
> The F1 CAN hardwrae is identical to the F4.
> You need to initialize your filter as well.
> See this loop-back example here:
What is 'CanFilter::setStartFilterBankForCan2(14);'? If I'm only using
Can1, should I still call this with something?
xpcc-dev mailing list