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


_______________________________________________
xpcc-dev mailing list
xpcc-dev@lists.rwth-aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev

Reply via email to