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_discovery/stm32f072_discovery.hpp#L32-L38 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_discovery/stm32f072_discovery.hpp#L65-L103 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_experimental/src/xpcc/architecture/platform/driver/clock/stm32/clock.cpp.in#L24-L42 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.hau...@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_experimental/examples/stm32f4_discovery/can/main.cpp#L55-L79 Cheers, Niklas _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
