Find content
Not Telling
I tried the bitshifting thing--and it worked! But now I have a new problem.
If I bitshift the four addresses (for read/write and command/data) given, I get this:
0x78 = 0111 1000 >> 0011 1100 = 0x3C
0x79 = 0111 1001 >> 0011 1100 = 0x3C
0x7A = 0111 1010 >> 0011 1101 = 0x3D
0x7B = 0111 1011 >> 0011 1101 = 0x3D
The display does acknowledge when I send to 0x3C and 0x3D...but I need four addresses, not two.
I wrote a loop to cycle through every possible I2C address. Those are the only two addresses that acknowledge.
I emailed the company, and this was the response I got:
"your compiler seems to do things automatically. The last bis is for write and read operation (pelase compare with I²C bus sepcification, done by Philips)"
Not sure what to make of that. But it seems apparent that the display is ignoring the first address bit. Is there some simple way to tell the Netduino to throw in an extra bit at the beginning?
It also seems apparent that this is an issue with the display. The expander is supposed to be addressed at 0x20, and it acknowledges at that address while on the same bus running the same program. Why would the display's address require a bit-shift but the expander's wouldn't? Seems like it's a problem with the display.
I've attached two screen shots from my scope, both named by the address used in the program. You can see that 
0x78.bmp 219.43KB
0 downloads doesn't acknowledge and thus transmission is canceled.
0x3c.bmp 219.43KB
0 downloads does acknowledge and so another byte is transmitted.
But when I look at the scope readings, 0x3C looks like 0x78 to me. My understanding of I2C is that the master pulls the data line low to signify START, then the clock starts. The data line is read when the clock line is high. When I'm using the address 0x3C in code, the first high clock pulse has the data line at low, and the next 4 clock cycles, it's high. That sounds like 0111... to me, not 0011...
But I'm obviously missing something. If you look at attached file
0x20.bmp 219.43KB
2 downloads, that's the same setup trying to talk to the MCP23008 expander, whose address is 0x20, or 0010 0000. Same deal--that one looks an awful lot like 0100... rather than 0010... But it is acknowledging anyway.
I'm totally stumped here. Anyone have any ideas?
