Jan-18-2021, 05:11 PM
Quote:But to get this, trellis.sync in the While loop reads all 32 boards each time. I was wondering if that could be avoided
I2C is a serial ( asynchronous ) bus, thus only one packet can be seen (or set) at any one time. A separate packet is put on the bus, with it's board Id each time an event occurs, and then is identified and read on the receiving end of the connection. I can't explain all here, but the specification here will explain all (the last release of specs was released, April 4, 2014 so don't let the date make you think that it's outdated. And is further explained here.
Putting stuff on the bus is the work of the sending hardware and/or software.
I'm guessing the following: (I have only previous real-life job experience and know how I handled this in the past)
The logical choice for setup is:
1. Poll each board individually, ( in software ) looking for a signal. This obviously has to be done fast enough to be able to detect each key press, no matter where it originates.
The polling speed is limited by the hardware on each neotrellis board, Not by the controlling processor, no matter how fast it is, so the pi zero (or any other processor, like the M4, is more than adequate A button can only physically be pressed as fast as a human finger can move).
2. Each individual board on the neotrellis fires an interrupt as soon as [b]Any[/] key is pressed on that board. This interrupt along with the board Id and x, y id is immediatly sent over the I2c bus to the controlling processor. This is the ideal setup as you don't have to discover which board is sending the button press signal. Again the time needed to process on the controlling processor is trivial when human intervention (the button press) is involved.
External processing is necessary to handle this (with a single I2c from all boards) to MCU. see: https://learn.adafruit.com/adafruit-neot...-3002700-9.
Any code, no matter what is used, can only send one packet at a time across the I2C bus. If more than one finger is used at the same time, It would be possible to have collisions (bounce) that must be taken into consideration with either de-bounce software or hardware. I'm not ready to say what is being done on this board yet. I will get to it, but as stated before, slowly (I have to fit this into my schedule, which, although being retired, is quite full).
That's why I warn that above is still speculation.