I tried with a single address and with a couple different orderings for the reads, like all the transmits followed by all the receives, or this kinda thing:
static uint8_t ansible_addrs[] = {
II_ANSIBLE_ADDR,
II_KR_ADDR,
II_MP_ADDR,
II_LV_ADDR,
II_CY_ADDR,
II_MID_ADDR,
II_ARP_ADDR,
ES,
};
static void op_ANS_APP_set(const void* NOTUSED(data), scene_state_t *NOTUSED(ss),
exec_state_t *NOTUSED(es),
command_state_t *cs) {
uint8_t cmd = II_ANSIBLE_APP;
int16_t n = cs_pop(cs);
uint8_t d[] = { cmd, n };
for (uint8_t i = 0; i < sizeof(ansible_addrs); i++) {
tele_ii_tx(ansible_addrs[i], d, 2);
d[0] = 255;
tele_ii_rx(ansible_addrs[i], d, 1);
if (d[0] < 27) {
cs_push(cs, d[0]);
return;
}
d[0] = cmd;
}
cs_push(cs, -1);
}
Sometimes it works, but still wind up getting a lot of 255s and -1s returned from the op, sometimes I’ve also seen 27. 255 seems like it would be something returning a -1 on the Ansible side and the sign getting lost, if it weren’t for the response value looking fine when printed from the Ansible side. The 27 it turns out comes from here when there’s nothing in the i2c receive queue.
The app consistently changes just fine, and the debug prints are right. I think the problem has gotta be something to do with how set_mode is gonna wind up reconfiguring the I2C peripheral and someone or other gets confused. I thought putting set_mode before sending back the response should work, because the configuration should be done after that, and thought maybe since Teletype was trying to check every address that it should wind up seeing the message even though it would be sent whichever one we switched to. However both set_mode followed by ii_tx_queue and the opposite order seem to show pretty consistent behavior.
Meant to respond this - I haven’t yet wrapped my head around how the key press vs key hold timer setup and control flow works, so I was less confident implementing these. Also I should do this more consistently for the hardware emulation ops but I ignore ANS.G/ANS.G.P ops if you’re in preset mode since this seemed dangerous. Maybe need another op to toggle the safety on presets.
