Correct 10bit Device address handling.

[stickbreaker]

The existing code did not follow protocol with 10bit addressed devices. Per Philps/NXP Semiconductors UM10204 I2C-bus specification and user manual Rev. 6 4April2014 pg.15 3.1.11 10-bit addressing:
The first seven bits of the first byte are the combination of 1111 0xx of which the last two bits (xx) are the two Most-Significant Bits (MSB) of the 10-bit address; the eighth bit of the first byte is the R/W bit the determines the direction of the message

[stickbreaker]

Just found another inconsistency. In the Expressif 2.4 Technical Reference Manual, It explicitly shows mis-ordered address bytes.
My question is: when the I2C StateMachine compares a 10bit slave address, does it actually expect it in this mis-ordered fashion?

In figure 42, it say:

(slave_addr_first_7bits<<1|r/w)
slave_addr_second_byte

Which is totally bogus, I'm in the process of writing a slammed together I2C Slave mode, when I get the 7bit version working I'll document how the 10bit actually matches addresses.

Since this pull matches industry spec I think it should be applied to enable accessing 10bit slave devices. Depending how the ESP32 actually responds in Slave Mode, there might have to be some tweeking of SlaveAddress bit pattern.

Chuck.

[stickbreaker]

After creating a Polling mode I2C Slave for the ESP32, I was able to both Read and Write 7bit addressed data with the ESP32 using a UNO. When using 7bit address mode the slave_addr.addr is just the 7bit value.

My testing with 10bit addressed data was limited to Write mode only. The existing UNO Wire library does not support writing two byte addresses during a Read cycle. But, this restriction did not interfere with 10bit Write mode testing.

HOWEVER, when 10bit mode is selected, the bit order of slave_addr.addr has to be adjusted; b8:b9 becomes b0:b1, b0:b7 becomes b7:b14. To avoid collisions with existing 7bit devices, a mask must be applied to the first 7bits of the adjusted slave_addr.addr. 0x78 must be or'd with the reordered slave_addr.addr.

// code to convert a 10bit i2c address to slave_addr.addr format
	slave_addr.addr=((slaveId&0xff)<<7)|(((slaveId>>8)&0x3)|0x78);

UNO code to Write 10bit addressed data to the EPS32

uint8_t b = (uint8_t)((tenBitAddr>>8)&0x3)|0x78;
uint8_t c = (uint8_t)((tenBitAddr)&0xFF);
Wire.beginTransmission(b); // first address byte 1111 0 'b9' 'b8'
Wire.write(c);// b7:b0 at this point the ESP32 is selected
Wire.write(tick); // first byte of data
err = Wire.endTransmission();

So, when 10bit addresses are implemented, does the HAL layer assume the 0x78 mask has already been applied? Or does is insert the mask? I think the Wire library would be the correct place to apply the mask, this would allow the HAL layer do just do what it is told!

The 0x78 mask is need to comply with industry standards.
This table is from UM10204 pg.17:

Chuck.