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

xpcc-dev mailing list

Reply via email to