- xpcc-dev - lists.rwth-aachen.de

Generating documentation for specific device
by Szabó Antal 07 Apr '16

07 Apr '16

HI, I noticed that if I do `scons doc` the generated documentation doesn't include any specific device, How can I generate the docs for a device? Greetings, Antal

2 2

Data storage in flash
by Szabó Antal 17 Feb '16

17 Feb '16

Hi! I need to persistently store data in the device I'm developing, so I thought I would save it to flash. How can I do this? I didn't find anything in xpcc, so I would have to use some lower level functions I think, but what I don't know is how to allocate space for the data in the flash so it's on a separate page? Antal

3 3

Moving forward with STM32F103
by Szabó Antal 09 Feb '16

09 Feb '16

Hi, Due to the recent clock changes (https://github.com/roboterclubaachen/xpcc/commit/4b67b08ffddeb608df3d90c059…) 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

2 1

Trying to get CAN working
by Szabó Antal 05 Feb '16

05 Feb '16

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. 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? Regards, Antal

3 13

Towards modm
by Fabian Greif 05 Feb '16

05 Feb '16

Hi, during the last developer meeting we had some discussions about the next steps for xpcc. In my opinion one of the main problems in using xpcc for bigger projects is its build system. Although I like SCons and and implemented its beginning in xpcc, it has grown to much into a system builder. That is fine as long as xpcc is your primary platform, but makes it really awkward in cases where it is not. It also makes it difficult to full integrate it into IDEs like Eclipse, because the indexer has some problems deciding which file is used and which isn't. Another problem off xpcc is its size in combination with the release management. A fresh checkout is 77 MB at the moment, without the Git history its still 43 MB. In general that is not that much, but becomes annoying when you have a lot of small projects which you need to support in with different versions. Without a useful version schema, each project needs its own separate copy of the library. It is not possible/to much work to keep all projects always up-to-date to the most recent version of xpcc. Yet still new features are only added to newer versions, therefore it is also not useful to freeze an older version for all projects. To solve these issues a possible solution is extract the system builder part of the SCons system (basically everything in /architecture) into a separate tool and make the remaining parts more modular. One approach for this would be the library builder [1]. With this, a project would no longer be build against the complete library, but a subset of the library would be bundled together, containing only the needed and applicable parts for the project/architecture. E.g. a LPC11 application does not need all the STM32F.. library code. This greatly reduces the complexity of the generated source tree, which allows for an easy integration with IDEs and build systems other than SCons. The disadvantage mainly comes for the library developer, because the generation of the library becomes a separate step. For most projects you do this once at the beginning, after you selected your target architecture, but for library development you generate the library all the time. It may require a different workflow, by developing a new feature within a project, and only after it is finished moving it into the library. So how to start the work on this: Niklas already reserved modm-io on GitHub (modm stands for "Modular Object-Oriented Development for Microcontrollers") to resolve the naming issues between xpcc (the protocol) and xpcc (the library). I would start to migrating code from the xpcc repository over, separating it into independent modules. This requires a lot of structural changes which makes it difficult to automatically merge changes from xpcc to modm. The device driver generation part of SCons would be extracted into a separate tool which generates the content of the architecture folder. This will be the biggest amount of work. This tool will then be used by the library builder to combine the architecture stuff with the other parts of the library. So far the idea, any comments/other suggestions on that? Cheers, Fabian [1] https://github.com/dergraaf/library-builder

3 3

Would similar techniques apply to the mbed framework ?
by alex mor 25 Jan '16

25 Jan '16

Hi. I'm curious: using the same techniques you're using in xpcc , do you think it would be possible to build something mbed compatible , but with similar optimal results(memory, speed, etc) as xpcc gets ?

3 3

Hard fault debugging
by Szabó Antal 13 Jan '16

13 Jan '16

Hi! Thanks for the advice in the previous thread. I fired up gdb, and ran the program several times. This is the stack trace I get most of the time: (gdb) where #0 _hardFaultHandler (ctx=0x2000bea0) at build\libxpcc\generated_platform\driver\core\cortex\hard_fault_handler.cpp:39 #1 <signal handler called> #2 0x08101374 in ?? () #3 <signal handler called> #4 xpcc::BufferedGraphicDisplay<(unsigned short)160, (unsigned short)128>::drawImageRaw ( this=0x20000854 <hardware::lcd>, upperLeft=..., width=5, height=8, data=...) at D:\Prog\xpcc_test\xpcc\src/xpcc/ui/display/buffered_graphic_display_impl.hpp:92 #5 0x080011b0 in xpcc::GraphicDisplay::write (this=0x20000854 <hardware::lcd>, c=<optimized out>) at D:\Prog\xpcc_test\xpcc\src\xpcc\ui\display\graphic_display_text.cpp:115 #6 0x080011d8 in xpcc::GraphicDisplay::Writer::write (this=<optimized out>, c=<optimized out>) at D:\Prog\xpcc_test\xpcc\src\xpcc\ui\display\graphic_display_text.cpp:139 #7 0x08000d86 in xpcc::IOStream::writeInteger (this=0x20000858 <hardware::lcd+4>, value=48) at D:\Prog\xpcc_test\xpcc\src\xpcc\io\iostream.cpp:55 #8 0x08000dc0 in xpcc::IOStream::writeInteger (this=0x20000858 <hardware::lcd+4>, value=<optimized out>) at D:\Prog\xpcc_test\xpcc\src\xpcc\io\iostream.cpp:35 #9 0x08000c40 in operator<< (v=<synthetic pointer>, this=0x20000858 <hardware::lcd+4>) at D:\Prog\xpcc_test\xpcc\src/xpcc/io/iostream.hpp:206 #10 main () at main.cpp:41 What I get from this is that something causes an interrupt while drawImageRaw is running, and then tries to jump to 0x08101374, an invalid address, which causes the hard fault. The code in frame 4 is: 87 uint16_t row = upperLeft.getY() / 8; 88 uint16_t rowCount = (height + 7) / 8; // always round up 89 90 if ((height & 0x07) == 0) 91 { 92 for (uint_fast16_t i = 0; i < width; i++) 93 { 94 for (uint_fast16_t k = 0; k < rowCount; k++) 95 { 96 uint16_t x = upperLeft.getX() + i; Line 92 is the for loop header, and I don't see anything that can go wrong here. Also, it's not the exact same invocation where it crashes, the upperLeft parameter of drawImageRaw is different every time. Can you suggest anything I should try next?

3 6

Device description generation
by Szabó Antal 08 Jan '16

08 Jan '16

Hi! I just found xpcc, and it seems very promising. In my project I use an STM32F103RC, and if I try to build a really simple project for it, I get this error: "Error: XPCC Error: Could not find xml device file.". I looked in the tools/device_file_generator directory, but I don't really know how to use it. So my question is, what do I have to do to be able to use this mcu? Antal Szabó

3 18

Meeting C++
by Odin Holmes 12 Dec '15

12 Dec '15

Hi fellow Nerds, will any of you guys be at Meeting C++ in Berlin next month? I would love to keep in touch. Best, Odin

3 10

Implementation of Protocols
by Christian Menard 24 Nov '15

24 Nov '15

Hi everyone, First of all, a praise to your work! I just decided that a AVR-based platform is no sufficient for my project and upgraded to an stm32-discovery board. All I needed to modify in my application was a few Pin and device settings (about 5 lines). Thats it, the same application runs on a completely diffferent platform. Awesome! To my question: I'm working on an Ambilight clone (I already submitted a driver for my PWM devices). The device is connected via UART to a PC. Boblight runs on the PC and sends colors via a certian protocol over UART. I'm using a very basic protocol in the moment but would like to implement sanother one (LTBL). I would like to contribute the protocol Implementation, maybe it's of use for someone. So my question is: What would be the xpcc way of implementing a protocol on top of UART? Currently I'm using a protothread that reads a data stream from uart and parses it token by token. However, I'm think more of something similar to a driver. Cheers Christian

2 1