Using RPI to listen SMBus(I2C)

[box24]

I forgot to add that for an external bus you will also need to connect the I2C ground to the Pi ground.

why ? can you explain please.

if i dont use I2C bus but juste GPIO 23&24 ?

[joan]

No current will flow into or out of a gpio unless there is a complete circuit. The ground gives the needed return path for the current.

It's nothing to do with being an I2C bus or not.

Whenever you connect two devices you need to connect the grounds as well as any signal pins.

[box24]

No current will flow into or out of a gpio unless there is a complete circuit. The ground gives the needed return path for the current.

It's nothing to do with being an I2C bus or not.

Whenever you connect two devices you need to connect the grounds as well as any signal pins.

Yep, true!

[aiw]

If you don't end up getting the Pi to work for an I2C monitor this product is very inexpensive and does a great job decoding all bus architectures.

http://www.usbee.com/dx.html

[joan]

If you don't end up getting the Pi to work for an I2C monitor this product is very inexpensive and does a great job decoding all bus architectures.

http://www.usbee.com/dx.html

Have I misread the price? USD795 isn't what I'd call very inexpensive.

[box24]

inexpensive

I think i'm on good way.

I try with temperature sensor (I2C), it's work fine but a question to understand very well.

The format is "[" : start
"XX" : two byte
"+" or "-" : ack or nack.
"]" : end

for exemple i had [92+17+A0-]

92 -> 10010010 ?
but it's juste 1 byte no ?

In fact, I thought :

http://www.maximintegrated.com/images/a ... 2Fig01.gif

thanks you in advance

[joan]

I think that means that bytes 0x17 and 0xA0 were written to the I2C device at address 0b1001001 (0x49). The bottom bit is 0 for write and 1 for read.

What I2C device are you using? I'd like to check the specs.

[joan]

Crossing posts.

The 92 00 seem to be saying I want to read register 0.

Two bytes are then read from the device. Whether they are both from register 0 (word register) or from register 0 and 1 (byte registers) depends on the device.

[box24]

Specifically, i have :

the LSB
0 : write;
1 : read

[92+00+] -> 10010010 + 00000000
[93+17+A0-]

Actual data, sorry for the mistake

For the adresse 0x49 it's true, it's the temperature sensor adress.

[adresse_byte+data_byte]
[adresse_byte+data_byte]

adresse_byte : 1 byte + R/W ?
data_byte : 1 byte + R/W ?

Datasheet of my sensor:
http://www.ti.com.cn/cn/lit/ds/symlink/tmp102.pdf

it's just to understand your python code and reverse data.

[joan]

Could you confirm your data?

[92+00+]
[98+1B+80-]

98 would appear to be a different device, or is that a typo for 93?

The bulk of the Python code is interpreting the meaning of SDA/SCL level changes. To understand that you'll need to understand I2C signalling.

[box24]

Could you confirm your data?

[92+00+]
[98+1B+80-]

98 would appear to be a different device, or is that a typo for 93?

The bulk of the Python code is interpreting the meaning of SDA/SCL level changes. To understand that you'll need to understand I2C signalling.

Specifically, i have, sorry for the mistake :

the LSB
0 : write;
1 : read

[92+00+] -> 10010010 + 00000000
[93+17+A0-] -> 10010011 + 10111 + 10100000

[joan]

Okay.

[92+00+] -> 10010010 + 00000000

Writes 0 to the device. The bottom two data bits select the register, in this case the temperature register.

[93+17+A0-] -> 10010011 + 00010111 + 10100000

Reads two bytes from the device. The previous command selected the temperature register. The temperature is returned as 12 bits. The first byte read contains the 8 most significant bits. The second byte contains the least significant bits in the top nibble.

The temperature is therefore 0b000101111010, 0x17A, 378 decimal.

The least significant bit represents 0.0625 degrees, temperature is 23.625.

[box24]

Okay.

[92+00+] -> 10010010 + 00000000

Writes 0 to the device. The bottom two data bits select the register, in this case the temperature register.

[93+17+A0-] -> 10010011 + 00010111 + 10100000

Reads two bytes from the device. The previous command selected the temperature register. The temperature is returned as 12 bits. The first byte read contains the 8 most significant bits. The second byte contains the least significant bits in the top nibble.

The temperature is therefore 0b000101111010, 0x17A, 378 decimal.

The least significant bit represents 0.0625 degrees, temperature is 23.625.

Ok, thanks you!
Very nice explication!

I think, i will try to listen the SMBus on friday ! thanks !

[joan]

Bonne chance.

[box24]

Somes news

2 questions, i connected my "component" on I2C because pull-up in raspberry and pull down in the other card and the same ground


I check with i2cdetect - y 1 and i saw two adresse avaible. i think it's not very good for me

i try with sudo gpiod -s 1 and started python code.



the sample is too big ?

[joan]

I don't understand what the circuit diagram is saying (I don't understand electronics).

Which Pi gpios are you using?

Some devices have more than one I2C address.

There are repeated start bits. Nothing wrong with that, just slightly unusual. Could you point to the specs of the device you are monitoring?

[box24]

i'm using I2C pin in first time.

the device is bq20z655 (http://www.ti.com/product/bq20z655).

This screen show a voltage monitoring, in fact i am using an evaluation card (http://www.ti.com/lit/ug/sluu697/sluu697.pdf), page 9, and i put my RPI into the SMBus with the same ground to listen.

it's strange because in technical book for this device (bq20z60-R1/bq20z65-R1) link http://www.ti.com/lit/er/sluu386/sluu386.pdf, page 70, read Voltage (0x09).

2 bytes, read.

the resultat is strange.

Why repeat start bit ?

i convert in decimal :

adresse : 10110 ?
adresse : 0x09 ?
1 byte MSB 14310
1 byte LSB 6119

the soft show 14619 mV i think it's good but i'm not sure because sometimes :
[16+09+[17+EE+37+7B-]

i can read the register 0x09 with the evaluation board and the data is 37EE for 14318mV

[joan]

The chip is communicating using the smbus protocol. It seems to make more use of repeated start bits for its command set.

I can't make any sense of the display.

For instance [16+09+[17+EF+[6E+DD+] would seem to be an SMBus Read Word command (i2c_smbus_read_word_data), but I don't understand the third START.

The address of the device appears to be decimal 11, so hex 16 for write, hex 17 for read.

Code: Select all

S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
[   0B  0  +    09  +  [   0B  1  +        17  +        EF   +

But after the EF + there is another START where a STOP should be. That can't be right.

I'd try starting the pigpio daemon with a sampling rate of 2 microseconds and see if you get similar results. Some Pis don't play nicely with 1 microsecond sampling.

Could you explain a bit more about how you are monitoring the bus? Is the Pi purely passive. Which Pi gpios are you using. If the I2c ones are you sure there is no conflict in the pull-ups.

[box24]

I am using I2C GPIO, i think no mistake with that. I had change the sample, but no effect, same as previously.

Why i do that ? Because i need to understand very well SMBus because i need to read/write the data flash memory of the bq20z655 who using SMBus.

And the RPI seemed like a good idea, very "easy" to implement.

[joan]

If you have another Linux laptop it might be useful to run piscope on that and have a look at the I2C traffic to see if it looks complete.

The sample output you have given doesn't seem to make a lot of sense.

Could you dump a big load of output to a file and post that (or a link)?

[box24]

Yes i can save a file with data.

But i think it's sample rate or data store because i try with 2 register

Voltage 0x09, sometimes good, sometimes wrong


Cell Voltage 0x3C, good

[joan]

I wonder if the clock pulse is too short to be reliably detected by sampling. I think it's meant to be a minimum of 4 micros for the 100kbps bus.

[box24]

You code work until 100khz no ? the min is 4.6 micro for the pulse. How can i fixe it ?

Some of screen with piscope :

[joan]

That looks OK. You can count the nine clocks per byte (8 data bits + ACK/NACK) and the data looks clean enough.

You probably need someone who's familiar with smbus to comment. Longer examples of captured data would also be useful, especially if you can say what should be happening.

[box24]

The data is cleans on piscope, but sometimes a double "[[" appears or the syntaxe is not complete

But i used python code, the c code is more faster maybe ?

the time for SCL is 10 micro (see in piscope).