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 

> 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 


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].

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.

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


[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

Reply via email to