@Jan, hi! I thought I asked you directly this time.
I’m still trying to get my head around switching snapshots with an arduino-based Control Chain device.
My progress so far:
Working Arduino-based prototype on a breadboard with two button-type actuators
CC_MODE_TOGGLE works as a charm on both actuators, no issues there, I parse and output assignment parameters on an LCD in an event callback func
I created a group out of these two buttons, with CC_MODE_MOMENTARY | CC_MODE_OPTIONS | CC_MODE_GROUP (and | CC_MODE_REVERSE for one of the buttons)
Assigned the group to snapshot change (Snapshots → Load/Manage → Assign All → Control Chain → name of the group)
I can track the debugging information in the ssh
Now, when I scroll through the snapshots with the buttons, it seems that my Dwarf performs unassignment and assignment at every update from an activator (see the example from the terminal below).
The question is: is it the expected behaviour (unassignment/assignment)?
Also, sometimes switching of snapshots sort of stalls, and the terminal shows [cc-lib] device timeout (device id: 1), as if the devices go out of sync, or don’t keep up with the changes, or something.
Any thoughts what could be the cause of such behaviour?
I’m trying to debug momentary_process routine in actuator.c, but all seems to be smooth there; could it be something on the MOD’s side?
I’m thinking that the stalls can be caused by a teeny-tiny memory on the Arduino Pro Micro that I’m using, that could just overflow. I will need to look into disabling strings usage, the library code is a bit buggy in a sense that when using CC_MODE_OPTIONS with strings disabled it throws compilation errors. I’ll try using a Mega which has bigger memory, or I’ll have to go buy a Duo, if the memory is indeed the root cause, for I do want to enjoy fully informative display, which, in case of disabled strings, is not possible to achieve. Or I’ll hack deeper into the cc-slave code disabling the strings only for OPTIONS mode, which I’d rather not because of lesser compatibility with the future cc-slave updates.
But the fact that there are unassignments/assignments still puzzles me, and I’d like an expert opinion on that.
apologies for the late reply! You actually stumbled upon some preparations we already did for a next update.
In the next ControlChain update, enumeration lists will be split into frames. This will allow slave devices with less memory to still go through large lists, without having to save all the data to memory when its assigned.
This also brings a problem, when value’s are changed from any other place then the slave device itself, we cant assume it has the right frame in memory. So a reassignment is needed in some cases to force this.
right now however, we can consider it a bug on our side, as the reassignment is not always needed, and should not happen in this version.
Sorry for the confusion! We will iron things out in the next CC update!
Hi @Jan, a quick one (I hope): now that I run the cc library on Arduino Mega, and dynamic memory is not an issue (with the CC_MAX_OPTIONS_ITEMS set to 32 there’s still 5K of dynamic memory free), I keep experimenting with snapshots switching.
After I set a pair of actuators to scroll up and down through the snapshots, it works for several changes of snapshots, and then it stops, and here’s what I see in the debug screen:
The question is, these reported timeouts, [cc-lib] unassignment timeout (id: 1) and [cc-lib] assignment timeout (id: 0), are these more likely on the MOD Dwarf’s side, or on my Arduino’s side? I.e. are these the symptoms of what we were discussing above, and there’s hope this will be sorted out with one of the next firmware updates, or should I keep debugging my code?