@scanner_darkly - I was able to put a timeout in the infinite wait loop in the ASF library to bail out of unanswered commands. I was not able to figure out the series of voodoo commands required to restore the bus to a happy state. I tried a number of things there but was unable to get success. I’m just not familiar enough with i2c and with the ASF library to see the answer.
I do think we need to implement something like that to keep users from mis-typing a command and losing their work. With no Ansible connected, hitting CV 5 will lock your TT and you will loose all of your unsaved work. This is a pain in the butt for a studio session and a nightmare if you are live coding in a performance.
An easy way around this would be to “register” bus devices in the TT. The TT stores that registration to flash memory and then bounds checks any addresses at the time of the command - skipping devices that are unknown. Registration and deregistration would be a one-time affair.
Even if we do that type of thing, the aforementioned timeout and recovery would also be a good idea for the ecosystem so that it is more resilient.
Around timing, I’ve been able to pummel the bus with write commands without problem. 24 Triggers and 24 CV outputs writing values at 10ms intervals with only slight timing discrepancies. I put that in the “wow” category for what the TT and its 400mHz bus can do.
The reads are another story. They are slow and eat up bus time. I’ve avoided supporting read operations for the TXo for this reason; you don’t get a value from TO.CV 1 as it doesn’t bother calling to the device to get its state. I always figured that if this was desired, it would be far easier to cache the value on the TT and simply return it from there.
For the TXi, reads are unavoidable. One level of caching would be to remember values for the duration of a script so that subsequent calls for the same parameter would return from memory as opposed to another bus read. A second level of caching would have us move reads to a lower priority background thread and have it poll at a safe and reasonable rate (and for a single device at a time as opposed to input by input). Scripts can then read at any rate they want without causing havoc on the i2c bus and the values can update in the TT without affecting timing.
Lots of options here - thoughts?
