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
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
