Since the next robotics season is approaching I would like to do
an xpcc release next week. The name will be `2013` since we are
probably going to do annual releases. If we want to do more
frequent releases we can add a number (maybe a MINOR and PATCH version)
or q1-q4 if we ever want to do quarterly releases.
For the release I want to do the following things:
1.) Tag the current master branch as `2012` and then release this
version via
[github](https://github.com/blog/1547-release-your-software).
Does anyone have any thoughts on release notes?
2.) Merge master into develop.
3.) Merge develop into master.
4.) Tag master as `2013` and release via github.
Any thoughts on release notes?
5.) Merge _feature/experimental_structure_ into develop.
6.) Delete _feature/experimental_structure_ branch.
For the remaining branches I have the following plans:
* _feature/tcpip_communication_:
rebase on top of the new _develop_ branch.
* _feature/stm32_spi_slave_:
add SPI Slave code manually to our new develop
(I'm working on new SPI code for STM32 at the
moment so it might already be on the
_experimental_structure_ branch when
we do our release).
Cherry-pick example projects created on this branch.
Then delete.
* _feature/display_menu_structure_:
this was planed to be included in the `2013`
release but will not be ready in time.
Thus rebase on top of the new _develop_.
* _feature/stellaris_lm4f_support_:
keep around because it will be usefull
should we ever decide to add LM4F support
to xpcc. Since TI has been quick to discontinued
this line of uCs it is not certain
if we ever will.
So does anyone have any comments on this?
If not I'll try to do the release together
with Niklas probably on Tuesday.
Am 09/25/13, schrieb Niklas Hauser <niklas.hauser(a)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.
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?)
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). 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.
Georgi
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
[0]: http://www.youtube.com/watch?v=K7ZrSNsiYjY
Hello,
I need to know the maximal length of a message sent. The SmartPointer
class says one payload can maximal be 252byte. Is this the maximal
Message size?
Best Regards,
Thorsten
Hi,
can somebody help me to remember why do we have a device _and_ an
architecture entry in our project configuration files? An device should
be enough or do we have devices with multiple architectures?
Georgi
