The 4x I2C busses were mainly there to reduce parasitic capacitance and also allows me to know where each key is physically relative to each other in software. I’m still working on the firmware for it, but currently the plan is for each of the keys to remember its “parent”, the neighbor that is closest to the main board, and forward events repeatedly to the main board.
So every I2C command is a relay hop? The 10th key in a chain has all the latency of the 9 before it who got the message and relayed it on? Separately what happens when the key is connected on all four of its sides? Does it receive four messages and need to send out four? Or is there some discovery of best path to master? I assume the master polls out “hey have you been pressed” to everyone?
Off the top of my head, I think I would have considered a masterless node system like CAN here, there everyone would just post their press status on change and on cyclic… because if you have to relay I2C messages even at 400kbps, that seems like a latency build up at n keys down the line.
But, I haven’t really thought about it at all. I’ve only used I2C like twice ever!
Yes it is a relay hop and the latencies do stack. If a key is connected on all 4 sides then in the worst case scenario it will have to receive 4 and send out 1 to the best path to the master. Ideally the master doesn’t poll and an interrupt would be triggered on a keypress. there might be a way to batch them but it would probably run on a FIFO basis. I could turn it into a CAN bus but I still have to test out if that would be better than the current system.
It’s a keyboard you don’t need masterless. You would be fine with one master, as you have USB to work out anyhow, and none of your keys need to talk to each other.
You could look into single wire LIN. You might still need a transceiver. And you might want to use it with 12V but that isn’t necessary.
There is an interesting way you could do othangonal position detection. And while it’s much slower than I2C, there would be no relaying at every step. I bet it would be lower latency overall.
Can requires a transceiver, but they can get quite small now. I don’t know if it fits in your cost model, but again all your chips would be single can module which is easy to do. Gets hard when you need 3+ CANs. IDK, I’m sure there are other masterless systems out there, I just have twenty years automotive experience with CAN.
The 4x I2C busses were mainly there to reduce parasitic capacitance and also allows me to know where each key is physically relative to each other in software. I’m still working on the firmware for it, but currently the plan is for each of the keys to remember its “parent”, the neighbor that is closest to the main board, and forward events repeatedly to the main board.