Add 'set_multiple' function, to permit setting multiple attributes

[seb26]

Suggestion to resolve #2.

Using decimctl set_multiple, set() is called, a single device instance is created and registers gathered, name & value pairs from the arguments are parsed and then set.

Example command:

decimctl set_multiple UMDs_W1_Enable 1 UMDs_W2_Enable 1 UMDs_W3_Enable 1 UMDs_W4_Enable 1

I am not sure how the UCP Control app is able to set All UMDs on or off in a single press, where all UMDs visually disappear or reappear together with no delay in between each one.

Testing:

It's much faster to switch UMDs on/off using set_multiple.

In #2 my shell script with 4 separate decimctl set calls, I can see ~891ms delay between each UMD appearing, measured using a slowmo iphone recording.

Using set_multiple the visual appearance of each UMD appearing/off is much quicker and the delay is ~491ms.

decimctl set attrib and decimctl set attrib value are functioning as normal.

[quentinmit]

Right now, setting attributes on an instance of Registers causes an immediate write to the device. That's presumably where the bulk of the delay comes from.

I would guess that the UCP Control app is able to change multiple values at once by writing the entire configuration block to the device, instead of writing an individual setting. When I first implemented decimctl, I felt that was too dangerous without understanding what the other bytes in the register block do.

That said, the UMD enabled/disabled status is stored in two consecutive bytes, so it should be possible to support setting those two bytes at once without much risk.

Given that this only takes it from ~900ms to ~500ms, I don't really like adding this as-is. If you want to work out an API that could allow changing multiple registers with a single write (e.g. by diffing before/after states to identify changed bytes?) or an API that specifically allows toggling all the UMDs at once (should be easier to implement, but obviously more constrained) then I'd be happy to entertain that.

[seb26]

Thanks Quentin for considering this, I will look at one of the alternative strategies you mention.