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

New Device Files
by Niklas Hauser 18 Jan '14

18 Jan '14

are now available on this link: https://www.dropbox.com/s/mocxy5jbrth68ad/xml.zip Both AVR and STM32 devices have been updated to include the latest chips. Noteworthy additions are the STM32F030 and the STM32F429. Happy programming, Niklas

1 0

xpcc::endl
by Niklas Hauser 14 Jan '14

14 Jan '14

Hi, is there a particular reason why xpcc::endl appends only `\n`, and not `\n\r` ? When using a serial device from the command line (using screen, picocom, etc) this gets annoying _really_ quickly, as there are no options to treat a newline as a newline with a carriage return. Are there any concerns over just changing xpcc::endl to append `\n\r` ? Cheers, Niklas

2 2

Filling SmartPointer with array type data
by Thorsten Lajewski 07 Jan '14

07 Jan '14

Hello developers, I have currently the following problem: I want to use the SmartPointer with an array type datatype e.g. char[13]. The following contructors are implemented: 1.) SmartPointer () default constructor with empty payload 2.) SmartPointer (uint8_t size) Allocates memory from the given size. 3.) template<typename T > SmartPointer (const T *data) 4.) SmartPointer (const SmartPointer &other) The third variant is not useable with pointer type data, because the memory gets only calculated for the size of the pointer. So the next solution would be to use variant 2, but then there is no way to fill the data array. There are only getter functions and no setter functions. Thus i would suggest to add another constructor type template<typename T > SmartPointer(const T *data, int size) which allocates size*sizeof(T) memory. For this solutions also getter functions with a size parameter have to be added. The pointer is not type-safe anyway. If you can think up a better solution, please tell me. If you are ok with this solution, I will implement it as soon as possible. Best Regards, Thorsten Lajewski

2 2

Release Tests: add to drivers
by Kevin Laeufer 05 Jan '14

05 Jan '14

Hey folks, I am working a little bit on fixing `scons check` on develop. During that I found out how we test the different devices (the code is in `release/tests`). Unfortunately the files in `release/tests` only cover a small subset of what should be supported on the different devices. Also since almost no one knows of the existence of these files (or at least I did not until tonight) it is difficult to keep them up to date with a changing API. Thus I want to propose including small snippets of code with the peripheral drivers. We could add a new tag to the `driver.xml` files, something like <compile-test></compile-test> that point to a file that contains something like e.g.: GpioOutputA0::setOutput(); GpioOutputA0::setOutput(xpcc::Gpio::High); GpioOutputA0::set(); GpioOutputA0::reset(); GpioOutputA0::toggle(); GpioInputA1::setInput(); GpioInputA1::read(); GpioA2::setOutput(); GpioA2::set(); GpioA2::setInput(); GpioA2::read(); for the stm32/gpio driver. Then `scons check` can go ahead and build a compile test program by looking at the drivers that a available for a specific device. Also we could add a flag to tell `scons check` only to check a certain driver, i.d. only build files for devices that require said driver and only include the tests of said driver in the test files. Doing this will make the tests more complete and easier to keep up to date. However there might be some things that I overlooked since the idea just popped into my head. So I would be happy to hear your comments on this issue. Kevin

2 1

Hosted: linking boost_thread
by Kevin Laeufer 05 Jan '14

05 Jan '14

Hello everyone, as you may have noticed the unittests are broken on the development branch of xpcc. I have them running on my system again, but before I commit my stuff I would like to talk about linking the boost_thread library. First of all I stumbled over this line in xpcc.py[363]: libpath = ['/usr/lib/'] Two thing: 1.) Why is this not in hosted.py which for me was the first place to search for this. 2.) As far as I understand or at least with my system (Fedora 20) /usr/lib contains 32bit, while /usr/lib64 contains 64bit libraries. Since we want to build for the host architecture, the correct path for 64bit systems would be /usr/lib64 The second point should be easily fixed by just not setting the library path. Either /usr/lib64 or /usr/lib will be set as an environment variable depending on the system. I do not understand why we had to manually set this in the first place. The thing concerning boost_thread that kept the unittests from compiling on my system was this line in xpcc.py[362] - again this should imho be in hosted.py: libs = ['boost_thread-mt', 'boost_system'] On my system there is no libboost_thread-mt.so.x.x.x library, there is only a libboost_thread.so.x.x.x. I can not find any definit information on this, but apparently boost_thread and boost_thread-mt have been the same for quite some time: http://stackoverflow.com/questions/3031768/boost-thread-linking-boost-threa… So maybe newer distributions won't include it anymore. Would it be ok if I changed this to _boost_thread_ without the **-mt**? Kevin

2 1