Am 16.01.2016 um 21:19 schrieb Niklas Hauser:
Hi Alex,
First, a disclosure: A couple of months back I started working at ARM on mbed
OS, especially on hardware abstraction layers.
So I know both side very well.
These are my personal opinions and obviously I can't discuss active development
(duh).
I'm curious: using the same techniques you're using in xpcc , do you think it
would be possible to build something mbed compatible , but with similar optimal
results(memory, speed, etc) as xpcc gets ?
TL;DR: It’s unlikely.
1. You have to use C++ for the lowest layers, to enable compile time
computations and inlining. C simply won’t cut it.
2. Code generation for HAL will not make things faster or more efficient, but
more consistent by de-duplicating code.
3. mbed’s dynamic scheduling is ultimately more useful, but it won’t work on
AVRs.
Details:
1. Language:
Deeply embedded engineers don’t write C++, and they certainly won’t start now
:-(
All the vendor HALs are written in C and therefore so is mbed-hal [1].
Lol so sad but so true ;)
xpcc HAL is designed using C++ templates, so that we can do a huge amount of
inlining and push a lot of checks into compile time.
Furthermore, the xpcc approach doesn’t require any "language hacks”, this is a
property of the HAL architecture, so you just get this for free, without having to
think about it. That was very important to us.
If your lowest layer is written in C, you loose all that.
It just severely limits the possibilities.
2. Code generation:
One doesn’t simply generate hardware abstraction layers.
(Ok, we _do_ generate HALs, but vendors don’t AFAIK.)
Once you have the entire infrastructure and data in place for generating HALs,
dealing with implementation “details” like which language you are using,
because much easier.
There is nothing stopping you from using our templates and rewriting them in C.
Or Swift. Or Rust (oh, someone please do that!).
You literally only have to exchange the template, we have done most of the
heavy lifting for you.
3. Scheduling:
xpcc can only do cooperative scheduling using stackless Protothreads and
Resumable Functions.
The upside is that this is completely static and you don’t need a scheduler
(and this works on tiny AVRs!).
The downside is power efficiency. You simply cannot really make this approach
energy efficient.
why exactly can't you sleep with protothreads? I only very briefly
worked on a design which went into deep sleep but their sceduler was
quite simmilar to protothreads.
mbed OS is aimed at battery powered devices and architected for it, where the
minar event loop [2] does the scheduling for you.
This obviously scales much better, and is easier to work with, while supporting
sleep modes.
I personally like the thread semantics from xpcc much more than the even-driven
approach from minar, but ultimately both do manual stack management, which
kinda sucks [3].
Obviously a lot of xpcc is written for thread semantics: especially all of our
device drivers.
That’s probably very incompatible with mbed OS, which is a shame, since these
drivers are quite cool.
Nevertheless, I strongly believe that out of all the embedded frameworks, mbed
OS has the most promise in terms of wide vendor support, modularity and
openness through yotta and the registry and the many forms of connectivity.
Also: There are some _really cool_ things in the pipeline ;-P
Cheers,
Niklas
[1]: https://github.com/ARMmbed/mbed-hal
[2]: https://github.com/armmbed/minar
[3]: http://web.stanford.edu/class/cs240/readings/usenix2002-fibers.pdf
___
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
