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/c...
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
Hi,
there is one more thing I would like to discuss, there should be a place for saving code for testing purposes. At the moment testing examples are misused for this kind of code, because there simply is no other place to put this code. A top-Level sandbox folder would be nice.
Kind Regards, Thorsten
On 01.08.2013 22:55, Niklas Hauser wrote:
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:
- Coding Conventions,
- Documentation Conventions,
- Peripheral Interfaces,
- Useful Examples, and
- XPCC Website + API.
- 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/c...
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:
- STM32F4,
- STM32F3,
- LPC11C24,
- (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 _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi,
there should be a place for saving code for testing purposes.
We have `scons check` which compiles everything in xpcc/examples. The idea is to move this to xpcc/release to test periodically in a CI environment.
At the moment testing examples are misused for this kind of code, because there simply is no other place to put this code. A top-Level sandbox folder would be nice.
No sandbox folder. We already have enough top-level folders. Do not commit half finished code as *examples*. Use a branch and make the code work, then write a nice example about it.
Niklas
Okay,
let's say I use a new feature branch for my new feature (of course). There I will still have to put my testing code somewhere. Probably this will not be any code which can be tested using the unit test, because it's hardware dependent for example. In order to test my code I would write a file containing a main function. And because the development of this specific feature would take some time, I would be glad to save it in the git branch.
1. I can't place it, where the rest of the code belongs. (It's not a part of the lib) 2. I can't place it, in a test folder (these are reserved for the unit tests) 3. I can't place it in an example folder, because it does not belong there.
So you still have not answered, where the place to put this kind of code would be.
Thorsten
On 01.08.2013 23:30, Niklas Hauser wrote:
Hi,
there should be a place for saving code for testing purposes.
We have `scons check` which compiles everything in xpcc/examples. The idea is to move this to xpcc/release to test periodically in a CI environment.
At the moment testing examples are misused for this kind of code, because there simply is no other place to put this code. A top-Level sandbox folder would be nice.
No sandbox folder. We already have enough top-level folders. Do not commit half finished code as *examples*. Use a branch and make the code work, then write a nice example about it.
Niklas _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Hi,
- I can't place it, where the rest of the code belongs. (It's not a part of the lib)
- I can't place it, in a test folder (these are reserved for the unit tests)
- I can't place it in an example folder, because it does not belong there.
So you still have not answered, where the place to put this kind of code would be.
You can put your undocumented testing code into xpcc/release and continue implementing your feature. Since you are working on a feature branch, your code does not have compile all the time.
When the new feature compiles and works as intended, you can leave the (now working) code in the xpcc/release example for release testing.
Niklas
Hi,
Am 01.08.2013 23:50, schrieb Thorsten Lajewski:
let's say I use a new feature branch for my new feature (of course). There I will still have to put my testing code somewhere. Probably this will not be any code which can be tested using the unit test, because it's hardware dependent for example. In order to test my code I would write a file containing a main function. And because the development of this specific feature would take some time, I would be glad to save it in the git branch.
- I can't place it, where the rest of the code belongs. (It's not a
part of the lib) 2. I can't place it, in a test folder (these are reserved for the unit tests) 3. I can't place it in an example folder, because it does not belong there.
So you still have not answered, where the place to put this kind of code would be.
There is a top level folder called "tests". And it contains, you might already have guest it, tests. Why not put it there?
Cheers, Fabian
On 02.08.2013 00:39, Fabian Greif wrote:
There is a top level folder called "tests". And it contains, you might already have guest it, tests. Why not put it there?
Isn't this folder for the unit tests?
If not, please explain, which folders are for unit tests.
Best Regards, Thorsten
Am 02.08.2013 00:52, schrieb Thorsten Lajewski:> On 02.08.2013 00:39, Fabian Greif wrote:
There is a top level folder called "tests". And it contains, you might already have guest it, tests. Why not put it there?
Isn't this folder for the unit tests?
No. Just take a look there. There are only normal projects.
If not, please explain, which folders are for unit tests.
The folders in /src/*/test contain the unit tests. /tests is for integration tests etc. Actually, most of the stuff in /examples should be in /tests.
Cheers, Fabian
Update:
## 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).
I want to add some information:
The source code (in the xpcc repository) is documented with doxygen and MarkDown (.md). Doxygen has built-in support for .md and will generate the API for us.
However, the website (in the xpcc-doc repository) uses reStructuredText (.rst), _not_ MarkDown. In order to not go crazy with .rst I recommend using an editor with a live preview, such as ReText.
ReText is developed for Ubuntu, but can also be compiled to OSX using homebrew. http://sourceforge.net/p/retext/wiki/Home/#faq
For Markdown a better, native OSX editor called Mou exists: http://mouapp.com
Cheers, Niklas
-
Fabian Greif -
Niklas Hauser -
Thorsten Lajewski