PCF8591DAC setting LSB in address to 1 for reading

I’ve used this DAC for sometime now but only in output mode. To set the address byte, the last bit is the decider for read or write (1 or 0 respectively).
The first 4 bits of the address are fixed at 1001 that means when I want to write to it I send out 0X90 (10010000) but because the Arduino Uno can only send out 7 bits for the address I have to bitshift it right one digit. So that gets me 01001000. And this of course works with the first bit showing up as a 1 to the DAC (and the scope).

But when I want to Read, I need to send 0x91 (10010001)
From DataSheet: see image

But bit shifting 0x91 so the MSB shows up and to make the first nibble correct at 1001 will send the LSB right off the end and loosing the last 1. Resulting in the same as bit shifted 0x90.
I’ve checked this on the scope and both 0x90>>1 and 0x91>>1 trace out the same. And the DAC is not hearing the “read” bit.

I’ve seen a few examples of just starting a wire-read request after sending in 0x90 >>1 and that must work as the example comes from a reliable source, but I was curious why a READ bit either isn’t needed (because 0x91>>1 will never generate one) or why sending in a WRITE bit still works on the Arduino when you want to READ.


Answered my own question. And for the benefit of others in the same trap...

I didn't realize that the initial byte sent in is just to wake up the slave device and prep it for what is to come. But if you are writing, then the 8th bit (the READ/WRITE bit) is already set to write (0) due to the way the Arduino spits out the byte and the program moves on to send in a control byte (this tells the slave, in this chip's case, what pin to read or write from or to). A data byte follows those two bytes. So that first byte is enough for the address and to tell the device that the arduino is going to write. I'm not actually sure if the Arduino sets this far right bit to zero because there is a WRITE command a few lines below, or its just that there isn't a high pulse being sent where a bit is missing so its interpreted as a zero (potato/potata)

The fact that this works and is the standard way of doing things made me think that if I wanted to READ, then the first byte - the address byte - had to include the READ/WRITE bit set to 1. The data sheet of this chip confirms that this is required. But, it turns out, if it is going to be a READ, then the actual READ/WRITE bit, set to 1, comes from the Arduino READ command and this sends the address byte all over again, but this time with a READ bit at the end (1) and then the contol byte follows. And all this happens AFTER the arduino has already sent the address byte without a READ bit set to 1 - as though you wanted to WRITE.

Compounding this confusion is the fact that the first byte is the Address byte, not a clearing of the Arduino's throat or a warning to expect data. If you are reading, this first byte is obviously not doing its full job and a second repeat "first" byte (with the extra 1 being appended) has to be sent again.

There are many program examples out there that use (in this chip's case) 0x90 bitshifted right to get the MSB into the second slot so it doesn't get dropped (Arduino takes that 8 bit value and chops off the MSB leaving the original 1 in the new MSB slot and only 7 bits to send. And since this chip needs a 1 in the MSB of the address bit, this works). But really, 0x90 (10010000) >>1 is the same as 0x48 (01001000) without a bitshift. So using 0x90 instead of 0x48 might lead one to surmise that the shifted bits might be collected by the device or sent out of the arduino justified-left, leaving an opening at the far right for another READ/WRITE bit that came from... where? Or that the slave device bitshifted the whole mess back left again, getting the far right bit from... again, who knows?

This confusion is doubly compounded by the device's data sheet itself (and excellent example code from a trusted source). It said to use 0x91>>1 for a READ. This wouldn't work even if a full 8 bits were being sent out. 0x91>>1 is the same as 0x90>>1 since the far right bit gets pushed off the cliff.

Since I2C is a 7bit protocol (and 10 in some cases) plus the always present READ/WRITE bit, how many devices out there probably only send 7 bits from the stated address alone? All of them I would guess. 'Cause, y'know... its a protocol! So where would you use an unshifted 0x90 and 0x91?

That bitshifted 0x91>>1 sent me down a rabbit hole I'm only now just recovering from. I hope this puts up some much needed police tape around the trip hazard.