Hi Wiktor,

I really like the idea and I'm impressed by really nice architecture, but have questions about performance and memory/flash usage? Has anybody made any benchmarks and comparisons of memory usage?

No, we haven’t don any large scale empirical studies comparing xpcc with other frameworks. However, it is designed to also work on ATtiny's and therefore a lot of work has been put into making it really resource friendly. (It’s definitely faster and smaller than Arduino, but their goal isn’t performance). If you want to convince yourself, you can compile all examples and xpcc will output the Flash (=Program) and static RAM (=Data) usage. Here for the AVR Gpio basic example [1]: Memory Usage ---------------- Device: atmega328p Program: 152 bytes (0.5% Full) (.text + .data + .bootloader) Data: 0 bytes (0.0% Full) (.data + .bss + .noinit) As you can see, our GPIO implementation has no static RAM usage whatsoever. It is also completely inlined and even atomic for the set/reset/read methods. It probably doesn’t get any faster than literally one instruction. Similar concepts exist to minimize resource use in many places, but I invite you to explore them yourself by compiling the examples that interest you and looking at the resource usage. Cheers, Niklas PS: The STM32F4 Gpio example [2] obviously also has 0.0% RAM usage. Memory Usage ---------------- Device: stm32f407vg Program: 1152 bytes (0.1% Full) (.data + .fastcode + .reset + .text) Data: 52 bytes (0.0% Full) (.data + .fastcode) Ok, so its 0.027%, but that’s from the start-up code and not from the GPIO, which is still inlined without RAM usage. However, the resources on the STM32 series are also luxuriously dimensioned compared to the AVR ;-) [1]: https://github.com/roboterclubaachen/xpcc/blob/develop/examples/avr/gpio/bli... [2]: https://github.com/roboterclubaachen/xpcc/blob/develop/examples/stm32f4_disc...

Hi Niklas, first of all thanks for your long and detailed answer.

Your yalla project is impressive too, especially with its thorough use of C++11. I found your lib while researching for safe register access strategies. It’s certainly the most beautiful of the solutions I found.

Thank you as well, I put some long evenings of thought into it ;) I also read your blog entry on Typesafe Register Access in C++ [1] and I got to say that I agree. Having a type safe register library is a nice thing, but maintaining and creating it is a lot of pain. If you have a good HAL then it is not so important how registers are accessed internally, as you only use an abstract interface anyway. Therefore I will probably stick with xpcc as you already created a very good and (as far as I could test it) solid HAL. However, I will not bury the yalla project as a pure C++11 library for AVR is still a nice thing to have :)

Perhaps. But let’s not beat around the bush here. I think to say that C++ is a very disputed topic when it comes to its use on microcontrollers is an understatement.

Every now and then there are discussions on how to properly use C++ on mikrocontroller.net (you can find them on your own ;-). They usually get stuck in an endless loop when the "experts” battle about the performance of basic C++ features with superficial knowledge. I mean, just ask about when virtual tables are actually generated and watch the wars escalate until the universe implodes.

Such toxic discussions are really terrible and probably make a lot of C developers not even consider C++ at all. We are divided whether presenting xpcc in such a forum is going to make things better or worse for xpcc.

I don’t want to end up justifying and arguing over the use of C++ in xpcc on the internet [2]. (There are also enough amazingly detailed talks about the efficiency of C++ on microcontrollers, like here [3]).

I understand you completely. I stumbled across these discussions my self and read too much of them. It's a pity that so many embedded developers are afraid of C++. I myself study 'Informationssystemtechnik' at TU Dresden. It is a course that teaches a mixture of Computer Science and Electronics. For me it just feels natural that good Hardware needs a good Software Design and vice versa. However, I know many good programmers who are afraid to get there hands dirty and don't want to program down to the hardware level. And on the other side many good Electrical engineers are afraid of Programming and therefore don't understand what a good software design is.

5. I think there are few developers that approach microcontroller programming from the high abstraction level that xpcc has. We make extensive use of code generation and C++ templates, which is a path that very few other embedded libraries (none?) use. This complexity probably scares off a lot of developers.

So I still think you deserve some more attention but probably it's best to just attract the developers who have similar views. People who understand that a high abstraction level does not necessarily mean a high overhead and that even with overhead a high abstraction level brings a lot more advantages. But I have no idea how to do that ;) Probably they fill find the project eventually as I did. Cheers Christian [1] http://blog.xpcc.io/2015/02/25/typesafe-register-access-in-c++/ On Thursday 02 April 2015 01:15:40 Niklas Hauser wrote:

Hi Christian,

...

I just want to say hello and tell you what an amazing work you do :). With xpcc you achieved exactly what I tried to to build for the last ~6 years, but I never had the time nor the resources to actually get something useful. Thanks for your kind words :-D

Your yalla project is impressive too, especially with its thorough use of C++11. I found your lib while researching for safe register access strategies. It’s certainly the most beautiful of the solutions I found.

...

Why is this project not more popular?

Ugh. Here are a few points ;-)

1. Naming. `xpcc` is not a name that connects well to the microcontrollers and C++ combination. Just type `avr c++` or `stm32 c++` into Google and look at the results. We have certainly improved over the last year, with a better homepage, better title (C++ Microcontroller Framework) and better documentation, but it’s still not very visible. We also gave a talk at FOSDEM’14, which didn’t really lead to a higher popularity.

2. We cannot compete with commercial frameworks like Arduino, mbed and various others, which have hired full-time engineers to build platform support and start a community. We are only a handful of students that do the best we can in our sparse free time.

3. That being said, xpcc has incomplete documentation. A lot of concepts are working very well and are somewhat documented in doxygen, but the higher concepts are not well documented. Conceptual documentation is *a lot* of work, but we have started a developer blog (blog.xpcc.io), where we pick certain xpcc features and explain them in detail.

4. We don’t really have a release strategy. This is because xpcc is a side project of us building autonomous robots for the Eurobot competition [1]. We have about 10 other internal repositories of similar complexity just with robot code, which all depends on xpcc. This added internal dependencies you don’t see, but influence xpcc quite a bit.

5. I think there are few developers that approach microcontroller programming from the high abstraction level that xpcc has. We make extensive use of code generation and C++ templates, which is a path that very few other embedded libraries (none?) use. This complexity probably scares off a lot of developers.

Just to name a few…

...

I only stumbled across by chance. I think it deserves allot more attention. Maybe some advertisement in the big µC forums would help?

Perhaps. But let’s not beat around the bush here. I think to say that C++ is a very disputed topic when it comes to its use on microcontrollers is an understatement.

Every now and then there are discussions on how to properly use C++ on mikrocontroller.net (you can find them on your own ;-). They usually get stuck in an endless loop when the "experts” battle about the performance of basic C++ features with superficial knowledge. I mean, just ask about when virtual tables are actually generated and watch the wars escalate until the universe implodes.

Such toxic discussions are really terrible and probably make a lot of C developers not even consider C++ at all. We are divided whether presenting xpcc in such a forum is going to make things better or worse for xpcc.

I don’t want to end up justifying and arguing over the use of C++ in xpcc on the internet [2]. (There are also enough amazingly detailed talks about the efficiency of C++ on microcontrollers, like here [3]).

I think such issues can only be solved with thorough documentation and examples, but that’s not a *fast* solution for xpcc. In the mean time, you would have to find the right place or forum to present xpcc, and I haven’t really found it yet.

...

You will probably hear more from me in next time as I will use xpcc for various projects. I will also gladly contribute my work. For starters I wrote a driver for the PCA9685 PWM controller and I'm just about to create a pull- request.

Done. That was fast…

@all: The concepts used in the device drivers (especially our use of Coroutines for cooperative scheduling) are quite new (developed last summer). So until this is properly documented please don’t hesitate to write me an email, if you’re stuck.

Cheers, Niklas

[1]: http://www.roboterclub.rwth-aachen.de/cms/ [2]: https://xkcd.com/386/ [3]: http://aristeia.com/TalkNotes/C++_Embedded_Deutsch.pdf [4]: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/driver/iner tial/itg3200.hpp [5]: https://github.com/roboterclubaachen/xpcc/blob/develop/src/xpcc/driver/iner tial/lis3_transport.hpp _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev