??? 11/06/08 20:12 Read: times |
#159851 - I2C Addressing Oddity I'm not quite sure |
I have a device the pca9546A which is an I2C multiplexer. Up to this point, all of my devices have had low slave address like 58, 24, 21 etc etc, so addressing devices has not been any issue.
This particular device (after I set the user bits), address is now 0xEE. Code architect built the I2C code and it has been very successful since I've got it going months ago. However, I found that the slave address is being shifted << 1. So that means EE will never get out because 77 would be a valid address. So how do I properly send the 0xEE? I have visual studio c++ app that I wrote that I can send direct bytes, I know the hardware works because when I send: 0xEE, 0x03 this enables the two channels 0 and 1 which I'm using and if I send 0xEE, 0x00 This disables those two channels as seen by my beagle I2C protocol analyzer and also on the scope. Now, when I use my MPU to send those commmand strings, the data is becomes like 6E! since the bits are being "dropped" off during the shift operation. Does anyone have a suggestion on how I should handle this? I thought of adding a if else statement to prevent the shift operation for values over 78, but that didn't seem to work out to well. I'm kind of stumped. Thanks Chris |
Topic | Author | Date |
I2C Addressing Oddity I'm not quite sure | 01/01/70 00:00 | |
From the data sheet Slave is 0xExxx0 | 01/01/70 00:00 | |
Pins are physically tied to Vcc | 01/01/70 00:00 | |
Also forgot to mention | 01/01/70 00:00 | |
it depends how do you see it | 01/01/70 00:00 | |
7-bit addresses are confusing | 01/01/70 00:00 | |
Got it now, it makes sense![]() | 01/01/70 00:00 |