Feature Suggestion
Opened this issue · 4 comments
This is not an issue, but it might be an idea for future development.
I needed to use TinyWireS with either a controllable delay or PulseIn etc which, as expected, ocassionally caused an issue when the master device transmitted a request to the slave. I solved this by introducing a pair of methods to TinyWireS - pause() and resume() - that 'removes the slave from the I2C bus'.
While paused the slave will not acknowledge its address to the master. (Main arduino wire library endTransmission() then returns '2' ie NACK on address and the master can behave appropriately)
This is implemented by setting/re-setting b7 of the slave's I2C address which is simple and fast. It is possible because I2C addresses use only 7 bits and the TinyWireS code checks the whole byte for equality.
All 8 bits of the address frame are used correctly in the usiTwiSlave library. 7-bits are the slave address shifted up by 1 bit and the 1-bit LSB is the I2C transaction direction (read/write). If you set the 0x80 bit on the slave address, it will be ignored.
If you want to pause the slave, just set the USICR to zero in your pause routine and nothing else. To resume, call the TinyWire init routine or the SET_USI_TO_TWI_START_CONDITION_MODE(); macro function.
--Scott (rshartog)
I take it back. The usiTwiSlave captures the 7 bit address correctly, but as you stated, it's compared to the full 8-bit argument passed in for the slave address, so the slave address will never match if the 0x80 bit is set in the slave address passed into the init routine.
Sorry for the digression.
--Scott (rshartog)
Scott - thanks for the reply.
I remain curious as to your opinion about 'pausing' the I2C bus by sending a NAK. Do you consider this an awful hack that should be avoided in I2C systems or a reasonable approach if the slave is busy?
I can push the address manipulation changes if you wish.
Again thanks
Graham
Hi Graham,
Eero (rambo) is the person to comment about the pushing the change.
I think your idea of setting the 0x80 bit of the slave address is elegant. Like you said, it's simple, fast, and unobtrusive.
Disabling the USI hardware by setting the USICR to zero would require additional checks to make sure that you don't stop the USI hardware in the middle of a transaction. Your idea does not have that problem because it only takes affect at the beginning of the next transaction. If a transaction is already in progress, it just continues.
--Scott