SMBus, SBS, I2CWrite, I2CRead

[dsicon]

for SMBus can i just use PBP2.x I2CWRITE and I2CREAD commands w/ impunity ?

from the little i have read it would seem so ...

also what is the difference between SMBus and SBS from the perspective of getting a 'fuel' gauge or 'gas' gauge reading into a PIC ?
seems to be about the same thing maybe ?

the chips on the table are
BQ34z100 (which clearly and literally describes 'i2c')
and
BQ20z70 (which calls out SBS)
plans were laid to use the 34z and now they want to change to the 20z in the pack and it has me worried a bit
thanks in advance for any advice or experience in this area

[Demon]

I can't comment on SMbus, but be aware of the voltage used by the vehicule (assuming it is one). In Canada, cars use 12 volts DC; PICs work on 5 V DC max. Just be aware you might need a voltage divider to lower the voltage at input, depending on the maximum voltage from the sensor.

Don't forget to compensate for any battery charging circuit as well. In Canada, alternators can go beyond 14V DC.

Robert

[dsicon]

I can't comment on SMbus, but be aware of the voltage used by the vehicule (assuming it is one). In Canada, cars use 12 volts DC; PICs work on 5 V DC max. Just be aware you might need a voltage divider to lower the voltage at input, depending on the maximum voltage from the sensor.
Don't forget to compensate for any battery charging circuit as well. In Canada, alternators can go beyond 14V DC.
Robert

Hi Robert,
thanks for the reply
i have the hardware issues under control, there is an Li-ion pack with a fuel gauge being specified and my question is strictly about the firmware compatibility of the I2CRead I2CWrite compatibility with the SMBus and the SBS on fuel gauge type chips

[Demon]

Ok, well I2C is I2C. If the chip say it will work on that protocol, then I2Cread/I2Cwrite will work.

Read the PBP manual about these 2 commands, some chips work at higher speeds and require a DEFINE to be set. This is where the datasheet for your IC will come in handy, they should say what speeds the IC work at.

If the question is chosing between these two ICs, I would use the I2C personally; simple, lots of examples in forum.

Robert

[Demon]

I hope they were planning on using the bq29330 along with the bq20z70. I see at least 5 interfaces between the 2 ICs:

- XALERT
. CLKOUT
- SDATA/SCLK
- MRST
- VCELL+/VCELL-

The schematic on page 12 shows how integrated both ICs are designed to be used along with the SMbus line (out the right).

"The bq20z70 uses SMBus v1.1 with Master Mode and package error checking (PEC) options per the SBS specification."

At this point I'd google using the keywords above and see what comes out. It appears to be a matter of sending the proper bytes/values, I assume in serial manner (PBP can do this easily).

Robert

[Demon]

Found this:

http://smbus.org/specs/smbus110.pdf

"The System Management Bus may share the same host device and physical bus with I²C components
provided that the electrical and timing specifications of this document are adhered to."


So it does look like you can talk to it using I2C BUT

"The SMBCLK and SMBDATA pins are similar to the clock and data pins found on an I²C bus. The
SMBus electrical characteristics differ from those of I²C."

If this is about figure 2.1 on page 8, that just means you can use devices of varying voltage levels.


"In addition to bus arbitration, SMBus implements the I2C method of clock low extending in order to
accommodate devices of different speeds on the same bus."

I haven't seen a place where it says it is 100% compatible with I2C, only that it follows similar principles. But the document makes it seem as if you can use I2C.

From page 10 figure 3.2:
"As with I2C, two unique bus situations define a message START and STOP condition."

From page 14:
"SMBus provides a clock synchronization mechanism, similar to I2C, in order to accommodate devices of
different speeds to co-exist on the bus."

From page 16:
The SMBus implements several communication formats that are a subset of the communication formats of I2C.

From page 17:
"For reference, the following Slave Addresses are reserved by the I²C specification and thus cannot be used by any of the devices on this particular interface:"


This from page 18 leads to believe it is 100% compatible with I2C:
"Several SMBus and I2C devices can be used simultaneously in an actual system."


Finally, found the list of differences on page 37. It looks as if you are ok as long as you stay within common ranges of electrical characteristics.

Timing differences are on page 38. All I see are a minimum clock of 10 KHz and maximum of 100 KHz, so stay away from the FAST I2C setting.

Page 38 goes on to describe ACK/NACK differences. I prefer to leave more advanced users to comment on this.

I see address restrictions on page 39, again, gonna leave this to the advanced dudes.

The last thing that pops in my mind is the issue of Master Mode. I would tend to think they mean the IC must be master. I don't know if this complicates things with regard to the PIC.

I didn't see anything about package error checking, that seems to be under SBS, not SMbus.

Robert

[Demon]

...the chips on the table are
BQ34z100 (which clearly and literally describes 'i2c')
and
BQ20z70 (which calls out SBS)
plans were laid to use the 34z and now they want to change to the 20z in the pack and it has me worried a bit
thanks in advance for any advice or experience in this area

http://www.ti.com/lit/ds/symlink/bq20z70-v160.pdf

Page 2 clearly shows I2C between bq20z70 and bq29330, in theory you should be able to talk to it using PBP.

BUT "It is designed to work with the bq29330"

How complicated stuffing a PIC in there might be more than just sending a few read/write commands (still going though datasheet).

Robert

[HKMathews]

This is kind of a new direction, but people on this thread may be curious - I am trying to program a smart battery (smbus master), to recognize whether or not a level 2 smart charger (smbus slave) is attached to it. I figure if the charger is not there, I could look for an acknowledge bit to be false when I send the charger address. The problem is, the ACKSTAT bit never sets and is always low (asserted) with no charger present. I thought it would be easy because the master is just talking to an open bus (with pullups attached), but it won't work for me. Here is my code:

SSP1CON1 = %00101000 'MSSP1 is the smbus master
SSP1CON2 = %00000000 'default
SSP1ADD = $27 'baud rate for 100KHz smbus (16 MHz osc, PIC18F67K90)

SSP1IF = 0 'reset interrupt flag
WCOL = 0 'clear the collision flag
SEN = 1 '(SSP1CON2.0) initiate smbus START
DO WHILE SEN = 1 'wait for start delay to complete
LOOP
SSP1BUF = $12 'send address 18 (level 2 smart charger)
SSP1IF = 0 'reset interrupt flag
DO WHILE BF = 1 'wait for buffer to empty
LOOP
IF ACKSTAT = 1 THEN.....(skip smart charger module)

The hardware is functioning correct - the /ACK bit is high at the falling edge of the ninth clock with no charger. I tried to use I2CWRITE but it hangs up for some reason and my 1 second watchdog resets the pic.

[HKMathews]

Solved my own problem! I have to wait at least 1 clock pulse (15 usec) after the BF flag resets (buffer is empty) before looking at ACKSTAT, to allow the ninth clock pulse to complete. My fix:

SEN = 1 '(SSP1CON2.0) initiate smbus START
DO WHILE SEN = 1 'wait for start delay to complete
LOOP
SSP1BUF = $12 'send address 18 (level 2 smart charger)
SSP1IF = 0 'reset interrupt flag
DO WHILE BF = 1 'wait for buffer to empty
LOOP
PAUSEUS 15
IF ACKSTAT = 1 THEN.....(NACK - skip smart charger module)

[tumbleweed]

After you write to the SSPBUF if you wait for SSPIF instead of BF then ACKSTAT will be valid.

[dsicon]

great stuff H & T thanks for the info
i need to learn more about handling the MSSP hardware directly as you are showing

[HKMathews]

T- I tried waiting for the SSP1IF interrupt, but it never happened! The pic spec indicates that you clear it after the start condition is complete (SEN = 1) and you have written to SSP1BUF (PIC18F87K90 Family figure 21-23), but maybe I have to clear it before writing to the buffer.

D - I prefer to talk directly to the MSSP module because I2CWRITE wouldn't let me send just an address and look for a NACK.