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
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
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
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
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.ziphttps://www.dropbox.com/s/3xg3qgfjs6ds4y1/AVR_devices.zip
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
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.
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
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
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
