Re: [xpcc-dev] Would similar techniques apply to the mbed framework ?
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
Re: [xpcc-dev] Meeting C++
Am 07.12.2015 um 22:02 schrieb Niklas Hauser: Mornin', I just asked FOSDEM how many speaking positions are still available in the room. I think we should all meet there, give awesome talks and then have an interactive ask us anything / feature wish panel where people with lots of embedded experience but little meta programming skill can tell us what problems they have trouble solving due to lack of library support. I wouldn’t consider myself knowledgeable enough for a panel in C++, especially when it comes to Metaprogramming and Standard library support. That language and library are so complex, they regularly baffle me. That doesn't really matter, we need some good talks to attract embedders who ask for things. I can only make STL suggestions for stuff that I know I need but there is still no doubt many things I have not thought of that others need. There are quite a lot of languages that work on embedded by now, with even more capable microcontrollers on the market. Also consider the push for even smaller Cortex-A class embedded systems running Linux directly like Googles Brillo, or Amazons IoT platform. As long as no batteries are involved, the product is not highly price sensitive and no hard real time guarantees are needed these are perfectly acceptable. But that is by no means the whole market. It gets more and more difficult to justify C++’s language complexity in this context. What do you guys think? Who would like to give a talk? - Odin - Wouter - who for xpcc? Kevin on xpcc and Niklas on how mbed will allow C++11 ;P I just gave a long talk about something really cool (I’m not spoiling it) as exemplified by xpcc, which was received very well, but I wasn’t planning on giving a talk at FOSDEM’16 though. The submission deadline is the 18th December for Developer Rooms, so I have about 10 days to make up my mind. Let me talk to Kevin and my colleagues first though. I would love to hear it. Cheers, Niklas ___ 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
Re: [xpcc-dev] Meeting C++
Am 07.12.2015 um 19:18 schrieb Wouter van Ooijen: Op 07-Dec-15 om 6:25 PM schreef Odin Holmes: I just asked FOSDEM how many speaking positions are still available in the room. I think we should all meet there, give awesome talks and then have an interactive ask us anything / feature wish panel where people with lots of embedded experience but little meta programming skill can tell us what problems they have trouble solving due to lack of library support. The C++ standard committee is asking for input from embedders as part of the SG14 working group STL enhancement (they put embedded in with games for some reason, maybe because we both don't use exceptions and RTTI). And no heap. Except for the use of an OS it seems to me that small-embedded/real-tiem and gaming have a lot in common. But gaming seems to be a lot more active in lobbying with the comittee, so it just as well that they gree with us in most aspects :) What do you guys think? Who would like to give a talk? - Odin - Wouter - who for xpcc? Kevin on xpcc and Niklas on how mbed will allow C++11 ;P Wouter ___ 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
Re: [xpcc-dev] Meeting C++
I just asked FOSDEM how many speaking positions are still available in the room. I think we should all meet there, give awesome talks and then have an interactive ask us anything / feature wish panel where people with lots of embedded experience but little meta programming skill can tell us what problems they have trouble solving due to lack of library support. The C++ standard committee is asking for input from embedders as part of the SG14 working group STL enhancement (they put embedded in with games for some reason, maybe because we both don't use exceptions and RTTI). What do you guys think? Who would like to give a talk? Best, Odin Am 18.11.2015 um 01:12 schrieb Odin Holmes: Looks like no talks yet though, maybe we should apply. Von: Niklas Hauser <mailto:niklas.hau...@rwth-aachen.de> Gesendet: 17.11.2015 22:54 An: xpcc Developer Discussion List <mailto:xpcc-dev@lists.rwth-aachen.de> Betreff: Re: [xpcc-dev] Meeting C++ Hi Wouter, >>> will any of you guys be at Meeting C++ in Berlin next month? I would love to keep in touch. >> Sorry, no, I won’t be going. >> I’m considering going to FOSDEM’16, but that is more OSS, less C++ focussed. > Maybe we could start an embedded room or whatever they call it at DOSDEM? FOSDEM’16 has an Embedded Developer Room. https://fosdem.org/2016/schedule/track/embedded,_mobile_and_automative/ That’s also where we presented xpcc almost two years ago: https://archive.fosdem.org/2014/schedule/event/the_xpcc_microcontroller_framework/ Cheers, Niklas ___ 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
Re: [xpcc-dev] Meeting C++
Looks like no talks yet though, maybe we should apply. - Ursprüngliche Nachricht - Von: "Niklas Hauser" Gesendet: 17.11.2015 22:54 An: "xpcc Developer Discussion List" Betreff: Re: [xpcc-dev] Meeting C++ Hi Wouter, >>> will any of you guys be at Meeting C++ in Berlin next month? I would love >>> to keep in touch. >> Sorry, no, I won’t be going. >> I’m considering going to FOSDEM’16, but that is more OSS, less C++ focussed. > Maybe we could start an embedded room or whatever they call it at DOSDEM? FOSDEM’16 has an Embedded Developer Room. https://fosdem.org/2016/schedule/track/embedded,_mobile_and_automative/ That’s also where we presented xpcc almost two years ago: https://archive.fosdem.org/2014/schedule/event/the_xpcc_microcontroller_framework/ Cheers, Niklas ___ 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
[xpcc-dev] Meeting C++
Hi fellow Nerds, will any of you guys be at Meeting C++ in Berlin next month? I would love to keep in touch. Best, Odin ___ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de http://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
Re: [xpcc-dev] Power efficiency and hard real-time
Hi guys,
sorry for my super late reply.
Am 08.11.2015 um 01:15 schrieb Niklas Hauser:
Hi Alex,
This project looks great.
Thanks!
We also have an extensive concept for cooperative, stackless multitasking,
based on Dunkels Protothreads [19], which we expanded on with Resumable
Functions [20] which are used in all device drivers to make communication
non-blocking and allow multiple device drivers on the same bus to safely access
it.
This form of multithreading is very resource friendly since it does not require
context switches and only the main call stack (literally 2 bytes of RAM per
Protothread).
However, this is quite an advanced topic and there are disadvantages to this
approach compared to a full real-time operating system (power efficiency, hard
real-time), such as mbed os or riot-os, however, they do not necessarily work
well on AVRs.
>>
Could you please expand on the disadvantages to power-efficiency or hard
real-time ? And how bad are those ?
Sure.
Some background first:
The protothreads are constantly being polled for state changes in their `run()`
method regardless of that being useful or not.
This makes it very simple to implement timer logics, since they do not require
to register callbacks, you simply wait until the timer expired:
xpcc::PeriodicTimer timer(200); // expire every 200ms
…
bool
MyAmazingThread::run() {
PT_BEGIN(); // protothread begins
while(1) {
PT_WAIT_UNTIL(timer.execute()); // yield until true
Led::toggle(); // toggle an led every 200ms
}
PT_END(); //
}
In your main loop you will have to call the `MyAmazingThread::run()`
continously for this to work.
Notice that this equals to an _implicit_ round robin scheduling, ie. you don’t
register with a dynamic scheduler class, but simply add your update function to
the main loop.
Other than that the Protothread behave very similarly to other thread
implementions, with the exception that you cannot have local variables, since
they are based on a stackless coroutine implementation).
This is a very simple multitasking concept and it works very well for most
applications.
I especially prefer the thread abstraction over using callbacks, as this can
lead to some very unreadable code.
Regarding power-efficiency:
Since you have to poll the threads even when no state change occurred, the CPU
is alway 100% utilized.
So this naive polling approach is obviously not very power efficient.
For our use this is not really a concern, since our robots consume around
10-15W just doing nothing, so the extra 10mA from the CPU doesn’t really matter
;-)
However, theoretically you could implement a sleep function here, by running
though the main loop only when a state change in hardware occurred.
For example, the timers only need to be polled every 1ms, since that is the
resolution of the clock.
So if all threads are waiting for a timer to expire, the CPU could to go sleep
and wake up on the next ms tick.
Since the only thing that you seem to be waiting for which is not an
interrupt is a time event you could implement a "time server" with a
queue which you can push wakeup events to. Essentially the time server
just sets the timer to go off at the nearest time point and then pops it
from the queue. Then you can just wait for interrupt at idle and have
all the power savings but can also potentially run at a finer
granularity. I have had success with this even using multiple soft uarts
(which require quite high timing precision).
Similar approaches could be taken for peripherals. You only have to poll the
thread waiting on I2C/UART/SPI if a state change actually happened, etc.
I would like to investigate the possibilities of this in the distant future, as
that sounds promising.
Another reason for not being power-efficient is that no DMA support is
implemented yet.
Even though we have a DMA HAL for the STM32, the Controller and Stream
selection for every peripheral still needs to be implemented.
This will likely happen before considering a sleep concept.
However, please note, that for true power efficiency, you need a full blown
resource manager, that not only manages CPU sleep but also powers down unused
peripherals (clock gating) and even external peripherals (ie. sensors, external
memories).
Such advanced schemes can become very complicated very quickly (there is a ton
of research done on doing this in clever way) and will probably never be part
of xpcc.
Regarding hard real-time:
In my experience, you don’t need a hard real-time scheduler, when you can do
your things directly in hardware (using a timer for a motor controller for
example) or by enabling a high-priority interrupt handler and executing from
there.
If you do need actual hard real-time in your program, having a implicit
cooperatively scheduled main loop is not the way to
