Hi,
can somebody help me to remember why do we have a device _and_ an
architecture entry in our project configuration files? An device should
be enough or do we have devices with multiple architectures?
Georgi
What do you mean?
As i know execution time is not affected by Lock?
Initialize methods may be used during usual execution also, so interrupts of given modules may cause initialization fail.
By the way initialize methods should assume arbitrary values in configuration registers, and not default values, which is not always easy and not everywhere done.
Georgi
Am 08/28/13, schrieb Niklas Hauser <niklas.hauser(a)rwth-aachen.de>:
> Hi,
>
> quick question:
> Is it a good idea to use
>
> xpcc::atomic::Lock lock;
>
> at the beginning of each and every Peripheral::initialize() method?
>
> Since initialize is mostly called during setup, execution time is not so important,
> and it reduces unwanted behaviour.
>
> What do you think?
> Niklas
> _______________________________________________
> xpcc-dev mailing list
> xpcc-dev(a)lists.rwth-aachen.de
> http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi,
quick question:
Is it a good idea to use
xpcc::atomic::Lock lock;
at the beginning of each and every Peripheral::initialize() method?
Since initialize is mostly called during setup, execution time is not so important,
and it reduces unwanted behaviour.
What do you think?
Niklas
Hi,
## The setup:
In xpcc-develop a software port is instantiated like this:
typedef xpcc::gpio::Port<P7, P6, P5, P4, P3, P2, P1, P0> Data;
That works until you only need less than 4, or 8 or 16 Pins.
Then you need to fill up the leading ones with `Unused`.
typedef xpcc::gpio::Port<xpcc::gpio::Unused, xpcc::gpio::Unused, xpcc::gpio::Unused P4, P3, P2, P1, P0> Data;
This sucks.
## The solution No. 1:
So in xpcc-ng, the template parameters are flipped and initialized to Unused, resulting in:
typedef xpcc::SoftwareGpioWord<P0, P1, P2, P3, P4> Data;
Better, but this also sucks, since it is not the way one expects the data (LSB-MSB is just wrong).
## The solution No. 2:
Enter variadic templates, another tool in compile-time recursion resolution [1].
So I implemented this[2], and surprisingly it is just as efficient as the previous solution with the added benefit of having the pins in the right order[3].
typedef xpcc::SoftwareGpioPort<P4, P3, P2, P1, P0> Data;
## The problem:
Unfortunately it does not work properly.
The `read()` function only recursed to mask 32 (P4).
The `write()` function only resursed to mask 16 (P3).
The generated assembly (ATxmega128a1u) can be seen here [4].
Compare the read (line 534) and write (line 338) function calls of `SoftwareGpioWord` with
the read (line 618) and write (line 707) function calls of `SoftwareGpioPort`.
The latter stop recursing at 32 (line 701) and 16 (line 714) respectively.
I think this has something to do with the compiler, maybe recursion depth?
Any schmart ideas?
Cheers,
Niklas
[1]: http://www.cplusplus.com/articles/EhvU7k9E/
[2]: https://github.com/roboterclubaachen/xpcc/blob/feature/experimental_structu…
[3]: https://github.com/roboterclubaachen/xpcc/blob/feature/experimental_structu…
[4]: https://gist.github.com/salkinium/73d38ccd4eb370d399bd#file-gistfile1-asm
Hi.
I propose to use the following header for all source files instead of the
full license text. It should contain the same information but is much
shorter:
/*
* Copyright (c) 2013, Roboterclub Aachen e.V.
* All Rights Reserved.
*
* The file is part for the xpcc library and is released under the
* 3-clause BSD license. See the file `LICENSE` for the full license
* governing this code.
*/
Any comments or other suggestions?
Cheers,
Fabian
Hi,
welcome to the new and improved XPCC Developer Mailing List.
Instead of 'Hello World', I am going to summarize our last developer meeting.
A couple of talking points were discussed:
1. Coding Conventions,
2. Documentation Conventions,
3. Peripheral Interfaces,
4. Useful Examples, and
5. XPCC Website + API.
6. Next Gen XPCC
## Coding and Documentation Conventions
The most significant changes are:
- removing the license text from every file,
- not indenting namespaces,
- Doxygen: @ not \
The current coding and documentation conventions are documented here:
https://github.com/roboterclubaachen/xpcc-doc/blob/master/source/developer/…
Once updated they are also displayed here:
http://xpcc.kreatives-chaos.com/developer/coding_conventions.html
## Peripheral Interfaces
There should be a distinction between platform independent interfaces, like Uart, Spi, I2C,
and low-level refactoring help, which summarizes register access on one famliy.
This caused confusion when developing these interfaces.
We will revise SpiBlockMaster with a similar idea like I2cMaster and I2cDelegate.
## Useful Examples
Currently the xpcc/examples folder in XPCC is more of a compilation check.
Most of the code is undocumented, too complex to understand and does not advocate
the core concepts of XPCC.
Therefore the content of the examples will be (partly) moved into xpcc/release and new
examples with thorough comments and explanations will be put in there.
It should also include a description of what will happen on the hardware (ie. "LED1 is supposed to blink").
These examples will be structured by:
- hardware
- functionality.
## XPCC Website + API
The xpcc-doc repository has not changes much since v1.0.
The core concepts of XPCC are not explained in enough detail, the idea of the peripheral interfaces is lost.
The Doxygen API in it's current form is very unorganized, however, the peripheral interfaces will
work to make this better using inheritance.
A xpcc.io domain is reserved for the future XPCC website.
It would be nice to bring the visual look of xpcc.io in line with the rest of the .io domains
(ie. it should look more modern and to-the-point).
## XPCC NG
We plan to merge the currently open `stm32_fsmc` and `display_menu` branches into `develop` and then release XPCC v1.2.
These changes must not be applied to this version of XPCC,
A next-generation version is being developed on the `feature/experimental_structure` branch,
which incorporates a lot of these changes already.
Please also see the notes of the Developer Summit 2012:
https://github.com/roboterclubaachen/xpcc/wiki/Developer-Summit-August-2012
The RCA plans to use the next-gen version in the 2014 season of Eurobot.
Therefore, these devices have priority for completion over all other platforms:
1. STM32F4,
2. STM32F3,
3. LPC11C24,
4. (STM32F1)
Since the next-gen version is quite different and very unstable, please contact @salkinium (Niklas) or @ekiwi (Kevin) before frustrating yourself on there.
Cheers,
Niklas
