Hi,
so this is just a minor issue, but the inconsistency is driving me so fubar crazy.
Why is there so much inconsistency in using run() and/or update() methods?
I would assume, that run() must be called unconditionally constantly in the main loop, and calls to update() can be scheduled at less frequency.
This would make sense, because update() indicates an 'update' of the internal state machine, where as run() would indicate an executing, resource requiring instance, right?
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.
It seems to reason that classes implementing any form of local continuation (like using a timer for non-blocking scheduling), like the xpcc::ui::Led classes, must provide a run() method, and classes polling asynchronous events like the xpcc::driver classes, must provide an update() method.
So far so good.
Now, along comes a class inheriting privately from xpcc::pt::Protothread which encapsulates the run() method in its update() method, so it can do some scheduling of subthreads on its own.
But this is like Matlock is trying to give me a back rub, it's like Andy Runy telling me to shut up and dance, it's like the Bucket List but not uplifting, it's like Cocoon, but somehow more gross. [0] It's just wrong.
Since the protothreads are only a nicer way to describe a switch case, the calls to the subthreads run() methods, should also occur in the superthread's public run() method, but before the call to PT_BEGIN().
Is that an agreeable solution? Is there any use-case when you need both the update() and the run() methods in the same class?
Cheers, Niklas