Hello NXP Community,
I noticed something strange in the PCA9698 datasheet on page 22. I think something went wrong with the conversion from binary to hex:
0 0 1 0 0 0 0 (0) -> 8Bit: 20h -> 7Bit: 10h => Correct
1 1 0 0 1 1 1 (0) -> 8Bit: CEh -> 7Bit: 67h => Correct
1 1 1 0 0 0 1 (0) -> 8Bit: E0h => no its E2
1 1 1 0 1 1 1 (0) -> 8Bit: ECh => no its EE
1 1 1 0 0 0 1 (0) -> 8Bit: EEh => no its E2
I think here is a clear mistake with the binary conversion from address E0 in the datasheet. I assume the hex addresses are correct or?
greetings
Falko Sauber
Solved! Go to Solution.
Hello Falko,
You are right, thank you for pointing this out!
The 8-bit hex write addresses are correct. Here is the corrected version:
Best regards,
Tomas
Its funny how long that misprint has persisted. I'm also curious why those configurations give E0-EE, you've stated they are correct but they are out of sequence with the other address options so it seems to be a deliberate decision by the designers to map it that way.
To describe the upper bits: if V means connected to a supply rail and B means connected to a bus pin (SDL or SDA) then:
210
VBV : 20
VBB : 30
VVV : 40
VVB : 50
BBV : A0
BBB : B0
BVV : C0
BVB : E0
Rather than a 2 page list of data would it be easier to give the logic behind the mapping of address pins to address bits?
For example if you just use VDD,VSS then pins AD0,AD1,AD2 appear to map to address bits A0,A1,A2
If you use the SCL,SDA connections then SCL gives a "0", SDA gives "1" and the above still holds true.
Whether you connect an AD pin to a supply or to a bus pin appears to encode the high 4 bits but in a more complicated way. 3 selectable bits appear to yield 4 address bits, but that could be shown in an 8 line look-up-table instead of 64 lines.
Hello Falko,
You are right, thank you for pointing this out!
The 8-bit hex write addresses are correct. Here is the corrected version:
Best regards,
Tomas
Hello Tomas,
Thanks for the confirmation. Will there be an update of the datasheet?
Best regards,
Falko
Hello Falko,
I have already reported it and proposed the correction, but cannot promise the update as rev.3 was released 11 years ago.
Best regards,
Tomas