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

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

Preliminary Device Files
by Niklas Hauser 28 Dec '13

28 Dec '13

Hi, I have updated the Device File Generator and it yields much better results now. With the exception of the newest devices (like the new ATmega88 or the STM32F429) all AVR and STM32 devices are now available. Since I only want to include tested Device Files in xpcc, I will not check them all in, but make them available via Dropbox: https://www.dropbox.com/s/mocxy5jbrth68ad/xml.zip Please test them, and check them in, if you are satisfied with it. Cheers, Niklas PS: If you want to generate some device files as well, here are the source files: https://www.dropbox.com/s/6nnph5pm9h3c9cm/STM_devices.zip https://www.dropbox.com/s/3xg3qgfjs6ds4y1/AVR_devices.zip

2 4

UART HAL
by Fabian Greif 22 Dec '13

22 Dec '13

Hi, I was wondering why we have the UART HAL layer for the STM32? What does it add apart from making the UART classes more complex? Background: Two days ago I did a small evening project to build a DMX512 light controller. In order to do that I needed a UART with two stopbits. As it was intended to be done fast, I copied the Usart1 class and was annoyed to have to figure out what class does what and to have to implement my changes in both classes. Cheers, Fabian

2 1

[RFC] xppc release 2013
by Kevin Laeufer 27 Sep '13

27 Sep '13

Since the next robotics season is approaching I would like to do an xpcc release next week. The name will be `2013` since we are probably going to do annual releases. If we want to do more frequent releases we can add a number (maybe a MINOR and PATCH version) or q1-q4 if we ever want to do quarterly releases. For the release I want to do the following things: 1.) Tag the current master branch as `2012` and then release this version via [github](https://github.com/blog/1547-release-your-software). Does anyone have any thoughts on release notes? 2.) Merge master into develop. 3.) Merge develop into master. 4.) Tag master as `2013` and release via github. Any thoughts on release notes? 5.) Merge _feature/experimental_structure_ into develop. 6.) Delete _feature/experimental_structure_ branch. For the remaining branches I have the following plans: * _feature/tcpip_communication_: rebase on top of the new _develop_ branch. * _feature/stm32_spi_slave_: add SPI Slave code manually to our new develop (I'm working on new SPI code for STM32 at the moment so it might already be on the _experimental_structure_ branch when we do our release). Cherry-pick example projects created on this branch. Then delete. * _feature/display_menu_structure_: this was planed to be included in the `2013` release but will not be ready in time. Thus rebase on top of the new _develop_. * _feature/stellaris_lm4f_support_: keep around because it will be usefull should we ever decide to add LM4F support to xpcc. Since TI has been quick to discontinued this line of uCs it is not certain if we ever will. So does anyone have any comments on this? If not I'll try to do the release together with Niklas probably on Tuesday.

2 3

Re: [xpcc-dev] run() vs. update()
by Georgi Grinshpun 27 Sep '13

27 Sep '13

Am 09/25/13, schrieb Niklas Hauser <niklas.hauser(a)rwth-aachen.de>: > This is how xpcc::ui::ButtonGroup works, where you only call the update() method every ~10ms or so. > This is also how all the I2C drivers work, where the internal state machine is truly asynchronous, since it polls the hardware for its (buffered) status. > I would suggest changing behavior of ButtonGroup enabling calling at arbitary frequency or changing the method name to something else, but run or update. Thats our cooperative multi threading concept which introduces methods update as well as run which mean they should be called as often you can. Maybe we can eliminate one of the notations. (Keep run, kill update?) By the way in our robots there are differences in run and update as i introduced recently (see description somewhere in drive code or in one of a commit message of mine). Here we have multiple threads which are called from main loop and from interrupts. run is mostly used as the interrupt thread and update as main loop thread. I've tried to separate notations to indicate potential race conditions. But this should not be considered in xpcc. Georgi

2 1

run() vs. update()
by Niklas Hauser 25 Sep '13

25 Sep '13

Hi, so this is just a minor issue, but the inconsistency is driving me so fubar crazy. Why is there so much inconsistency in using run() and/or update() methods? I would assume, that run() must be called unconditionally constantly in the main loop, and calls to update() can be scheduled at less frequency. This would make sense, because update() indicates an 'update' of the internal state machine, where as run() would indicate an executing, resource requiring instance, right? This is how xpcc::ui::ButtonGroup works, where you only call the update() method every ~10ms or so. This is also how all the I2C drivers work, where the internal state machine is truly asynchronous, since it polls the hardware for its (buffered) status. It seems to reason that classes implementing any form of local continuation (like using a timer for non-blocking scheduling), like the xpcc::ui::Led classes, must provide a run() method, and classes polling asynchronous events like the xpcc::driver classes, must provide an update() method. So far so good. Now, along comes a class inheriting privately from xpcc::pt::Protothread which encapsulates the run() method in its update() method, so it can do some scheduling of subthreads on its own. But this is like Matlock is trying to give me a back rub, it's like Andy Runy telling me to shut up and dance, it's like the Bucket List but not uplifting, it's like Cocoon, but somehow more gross. [0] It's just wrong. Since the protothreads are only a nicer way to describe a switch case, the calls to the subthreads run() methods, should also occur in the superthread's public run() method, but before the call to PT_BEGIN(). Is that an agreeable solution? Is there any use-case when you need both the update() and the run() methods in the same class? Cheers, Niklas [0]: http://www.youtube.com/watch?v=K7ZrSNsiYjY

2 1

Maximal Length Messages
by Thorsten Lajewski 20 Sep '13

20 Sep '13

Hello, I need to know the maximal length of a message sent. The SmartPointer class says one payload can maximal be 252byte. Is this the maximal Message size? Best Regards, Thorsten

2 3