Would similar techniques apply to the mbed framework ?
Hi. 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 ?
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]. 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 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
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
Hi,
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.
The issue isn’t sleeping, but with energy consumption. Lets say you have a main loop, which contains all protothreads and you go to sleep after every loop and wake up on any interrupt. You will then have to go through the entire main loop and poll protothreads that weren’t impacted by the interrupt. A smarter approach would be to attach a callback to the interrupt, and only execute that, but not the main loop. Of course this is a problem with the “dumb” xpcc implementation. I think this could be polished a lot more, if energy efficiency was a design goal (but it’s currently not). Cheers, Niklas
participants (3)
-
alex mor -
Niklas Hauser -
Odin Holmes