Some updates:
- I had plugged in a SPI EEPROM in place of the I2C EEPROM during a period of experimentation. Replacing this with the correct I2C EEPROM got me some functionality back. Drugs are bad, kids.
- Despite this, the CB, CY, OH, CH, TR1, TR2, and TR3 are always hitting every step for every pattern. I can edit these hits out, but they always come back after switching patterns.
- The remaining instruments work as normal - patterns can be saved just fine.
- Pattern length and scale changes work as normal.
- Tempo adjustments work as normal.
This looks like an I2C communications problem as far as I can tell. I probed the I2C lines and found that the first 8 instruments worth of steps for a given pattern are loaded from the EEPROM in a single 32 byte sequential read. The ATMEGA NAKs on the last byte and the comms stop. The ATMEGA then sets up another read (probably for another 32 bytes and the rest of the pattern data), but doesn't ACK any of the transmissions after clocking the first one in. Not seeing an ACK, the EEPROM just stops and waits as expected.
Sending data to the EEPROM works in the similar way, with two 32 byte transmissions for the entirety of the pattern data (the first transmission is for the first 8 instruments worth of step data, and the second is for the remainder). There are a couple other transmissions for scale and step length data, too. As far as I can tell, writing to the EEPROM is working.
I wanted to dig a bit deeper, so I "installed" the latest Arduino Wire library to get access to the Wire.available() function...
Code: Select all
oid Load_Pattern()
{
unsigned int adress = OFFSET_PATTERN + pattern_nbr * PTRN_SIZE_BYTE;
Wire_Begin_TX(adress);//commence la transmission a l'adress du pattern selectionner
Wire.endTransmission();
Wire.requestFrom(0x50,PTRN_SIZE_BYTE); //request des 64octets du pattern a l'adresse de l'eeprom
for (char i =0;i<NBR_INST;i++){//loop autant de fois que d'instruments
for (char j=0;j<2;j++){//loop deux fois pour les deux parti du pattern 1a16 et 17 a 32
Serial.println(Wire.available());
pattern[!pattern_buffer][i][j]=((Wire.read() << 0) & 0xFF) + ((Wire.read() << 8) & 0xFF00);//on load le pattern dans l'autre parti du buffer
}
}
Lo and behold, the first time Wire.available() gets called, my Yocto prints "32" out on the serial line. So even though Wire.requestFROM(0x50, PTRN_SIZE_BYTE); asks for 64 bytes (PTRN_SIZE_BYTE = 64), only 32 bytes are waiting in the buffer. How could this be? More digging will tell. If anyone has any suggestions, I'm all ears.
At least I fixed the pattern edit multi-button push bug...
