Hi,

...

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.

[…]

Recompile and it should just automagically work.

Yeah, probably not.

CAN needs very accurate prescaler settings for BS1, BS2. Kevin has added some more frequency values lately, so I’ve merged the develop branch into the feature/stm32f103 branch.

Still, only 8, 30, 36, 42 and 48 MHz input frequencies are accepted, with 36MHz being the maximum for the APB1 domain. https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...

You’ll have to configure your PLL and APB1 Prescaler to generate one of those frequencies. I think you said you run at 48MHz? That would mean 24MHz for APB1 (because divided by 2 so you get less than 36MHz). So you need to calculate BS1 and BS2 values for 24MHz.

(Or drop CPU frequency to 36MHz with APB1 Prescaler of 1. Don’t do that, that’s stupid).

Niklas

Hi,

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.

Microcontroller stuff is really hard. It’s even harder to do something smart in that area and make it usable and documented and un-magical and reliable. I work full-time with an entire engineering team to solve issues like this, and it’s still really, really hard.

That’s not an excuse for the black magic though. We can do better.

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 :)

Yeah. Conceptual documentation of xpcc is really bad. I started the blog to get these concepts written down, but I’m not a strong writer, and it takes a lot of time and effort to research and write these articles.

There’s a long list of things I want to write about: http://blog.xpcc.io/2015/02/23/why-a-blog/

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).

Ok. 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: https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f072_di...

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: https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f072_di...

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 xpcc::stm32::ClockControl: https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...

Generated file for F103 (might still be wrong!, Better verify this code with the Reference Manual!) https://gist.github.com/salkinium/7113bb72c1f33ee6677d

You then are free of the SystemClock dependency and should be able to just use the normal develop branch.

2016-02-05 1:55 GMT+01:00 Niklas Hauser niklas.hauser@rwth-aachen.de:

...

Yeah, probably not.

It actually compiled, but doesn't seem to work, altough I'm not sure I'm doing everything right.

At 32MHz it shouldn’t compile, there are no CAN settings to choose from. Hm?

The F1 CAN hardwrae is identical to the F4. You need to initialize your filter as well.

See this loop-back example here: https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...

Cheers, Niklas

2016-02-05 2:40 GMT+01:00 Niklas Hauser niklas.hauser@rwth-aachen.de:

I have a Nucleo-F103RB lying around, so I might give this a try on the weekend. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847/PF259875

That would be a huge help! (btw I have the exact same nucleo for flashing)

Hi,

I will try this then. I still need to copy over the device description file, right?

Yes, and linkerscript.

...

At 32MHz it shouldn’t compile, there are no CAN settings to choose from. Hm?

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>, AhbPrescaler::Div1, Apb1Prescaler::Div1>;

and writing out xpcc::clock::fcpu at runtimes confirms this.

Sure, but what is the value of `systemClock::Can1`? And does

Can1::initialize<systemClock>()

compile? I mean it really shouldn’t, 32MHz is not in the look-up table.

...

The F1 CAN hardwrae is identical to the F4. You need to initialize your filter as well.

See this loop-back example here: https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...

What is 'CanFilter::setStartFilterBankForCan2(14);'? If I'm only using Can1, should I still call this with something?

No, the shared filter bank is only available on connectivity devices F105/F107: https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...

Also this is a bug, the function should not be generated for F103.

Niklas

On 05/02/16 02:59, Szabó Antal wrote:

This is how I initialize Can1:

     GpioInputB8::connect(Can1::Rx, Gpio::InputType::PullUp);
     GpioOutputB9::connect(Can1::Tx, Gpio::OutputType::PushPull);
     Can1::initialize<systemClock, Can1::Bitrate::kBps125>(9);
     CanFilter::setFilter(0, CanFilter::FIFO0,

CanFilter::ExtendedIdentifier(0), CanFilter::ExtendedFilterMask(0));

So yes, it does, and I have no idea why.

Did you make sure, that your version of xpcc includes the latest CAN code?

Try the latest version for STM32F103 from Niklas: https://github.com/salkinium/xpcc/commits/4ca26ba6d896cc0e55e182b5cd1f19e142...

The old code did not properly detect unsupported frequencies. This was changed in commit 8cdc210dafd1d9d7424857ed2efd5e8643ac4454

If you want to calculate timing constants for your Frequency, you can find the python script that I used to generate the constants here: https://gist.github.com/ekiwi/51573729365405fef89c

Best of luck!

Kevin

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.hauser@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-L...

The output frequencies are generated using this template: https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...

Which uses the Clock Graph encoded here: https://github.com/salkinium/xpcc/blob/feature/stm32f103_support_experimenta...

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_experimenta...

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