Hi,

Am 09/25/13, schrieb Niklas Hauser <niklas.hauser@rwth-aachen.de>:

...

This is how xpcc::ui::ButtonGroup works, where you only call the update() method every ~10ms or so. This is also how all the I2C drivers work, where the internal state machine is truly asynchronous, since it polls the hardware for its (buffered) status.

I would suggest changing behavior of ButtonGroup enabling calling at arbitary frequency or changing the method name to something else, but run or update.

I am not satisfied with the ButtonGroup design anyway, it is not involved enough with the Gpio classes. The Button class is not even implemented :( Also xpcc/math/filter/debounce.hpp implements a Schmidt Trigger o_O

Thats our cooperative multi threading concept which introduces methods update as well as run which mean they should be called as often you can. Maybe we can eliminate one of the notations. (Keep run, kill update?)

So: Use run() for tasks that should be called as often as possible and update() for single time state changes with an external timer (like an interrupt).

By the way in our robots there are differences in run and update as i introduced recently (see description somewhere in drive code or in one of a commit message of mine).

Please don't make me search all of our svn/git histories :(

Here we have multiple threads which are called from main loop and from interrupts. run is mostly used as the interrupt thread and update as main loop thread. I've tried to separate notations to indicate potential race conditions. But this should not be considered in xpcc.

So this would be the exact opposite of what I think it should be. Can you provide the specific details of that magical commit messages and/or comments? On 25. Sep 2013, at 20:21 , Fabian Greif <fabian.greif@rwth-aachen.de> wrote:

...

I would assume, that run() must be called unconditionally constantly in the main loop, and calls to update() can be scheduled at less frequency.

No, there is no such differentiation, at least not to my knowledge.

The run() method of Protothread is named run() because of the similarity to Thread::run().

Which other classes use run()?

Most prominently my xpcc/ui/led classes ;-) Pretty much every other class uses update().

I assumed everything else uses update().

Well, I assumed everything uses the Protothread scheme, because everything with an update() or run() method is essentially a much simpler Protothread… There should not be a difference in the API, since the internal state machine is completely transparent to the user. In xpcc.io a lot of work has gone into removing or at least reducing inconsistencies. This is most visible in the common peripheral interfaces, but there is a lot of work to be done to create unified and harmonious design patterns for the whole library. That should be the grand goal. Cheers, Niklas