Thanks, that did the trick!

What I feel about xpcc, especially about its build system and
SystemClock, is that it's black magic, and that only the few of you
knows what's going on inside, and the rest of us can't do anything
about it. Now I'm getting used to the codebase, but it's still
difficult sometimes to find what I want.
What I think would really help is an overview documentation of:
  1) the build process (how to add new targets, etc.)
  2) the basic architecture of the system components/drivers

I know you don't have all the time in the world, these are just my
thoughts on making xpcc the best library for mcu programming :)

Also, since I'm writing software for a device that will eventually be
sold, I was wondering how hard would it be to port the current (i.e.
not system_clock branch) version of xpcc to the f103? I don't feel too
good relying on an experimental branch (also, running from external
crystal doesn't work currently).


Antal

2016-02-05 1:18 GMT+01:00 Niklas Hauser <niklas.hau...@rwth-aachen.de>:
> Hi Antal,
>
>> I'm trying to get CAN working, and I ran into this error:
>>
>> 'Can1' is not a member of 'xpcc::stm32::SystemClock<...>'
>>
>> As a reminder, I'm using the feature/stm32f103_support_experimental
>> branch, which is using the experimentel system_clock branch, so that
>> may be the problem.
>
> Yes, unfortunately the Clock Trees are quite complicated.
>
> The SystemClock is code-generated out of a template.
> The Can driver expects the `SystemClock::Can1` to exist and contain the input 
> frequency in Hz to the peripheral.
>
>> I went looking for a solution, but I just cant find the definition of
>> SystemClock anywhere, it's very frustrating. I found a million
>> SystemClock-named template parameters and other things, but not what
>> I'm looking for. Can someone help me with this?
>
> All generated peripherals can be found inside the build folder.
> The file you’re interested in is:
> build/stm32f103/blink/libxpcc/generated_platform/driver/clock/stm32/sinks.hpp
>
> The generated code you’re interested in is:
> https://gist.github.com/salkinium/3624a2c4ff73b2ec6892#file-sinks-hpp-L194-L239
>
> The output frequencies are generated using this template:
> https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/src/xpcc/architecture/platform/driver/clock/stm32/sinks.hpp.in#L157-L175
>
> Which uses the Clock Graph encoded here:
> https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/src/xpcc/architecture/platform/devices/stm32/stm32f103-r_v_z-c_d_e.xml#L105-L155
>
> As you can see neither the input data, nor the generated code mentions any 
> Can Output at all, which seems to be a mistake.
> The fact is the clock tree was written for the F100, and it didn’t have CAN, 
> so I just didn’t add it :-(.
>
> ST is notoriously bad for not describing what the actual device ClockTree 
> looks like.
> Looking at the Reference Manual of the F1 series, can you find which clock 
> domain CAN1 is connected to?
> I can’t. I have to look this up inside their source files every. single. 
> time. It drives me nuts.
>
> Anyways.
> CAN1 is connected to the APB1 clock domain. (Also I2S and DAC)
> So just add this:
>
>         <output name=“Can1”/>
>
> to the Apb1 subtree here: 
> https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimental/src/xpcc/architecture/platform/devices/stm32/stm32f103-r_v_z-c_d_e.xml#L123
>
> Recompile and it should just automagically work.
>
> Cheers,
> Niklas
>
> PS: You can add all your custom clock outputs this way. There might be more 
> missing :-(
>
>
> _______________________________________________
> xpcc-dev mailing list
> xpcc-dev@lists.rwth-aachen.de
> http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to