SMBus, SBS, I2CWrite, I2CRead

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

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

Quote:

---

Originally Posted by 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

---

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

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

Quote:

---

Originally Posted by dsicon

...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

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

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

Philips Semiconductors (now NXP Semiconductors) developed a simple
bidirectional 2-wire bus for efficient inter-IC control. This bus is called the
Inter-IC or I2C-bus.

SMBus, first proposed by Intel in 1995, was designed to
allow a battery to communicate with the charger, the system host,
and/or other power-related components in the system.

The I2C-bus is a registered trademark of Phillips.

Hey Robert
thanks a lot for your efforts here, back on this again
did you see an i2c address to use for the bq20z70 in the i2cRead command ?

well here is the latest on this topic
i still have not tried I2CWRITE and I2CREAD from PBP 2.6 with the SMBus yet but i have learned quite a bit
the address is 0
they didn't make it easy but found that in the spec (rather than the chip data sheet)

as mentioned the electrical thresholds are different - they are specific voltages rather than ratios of VDD, might be generally compatible but why mess around ?
i found that the PIC16F1508 specifically says i2c/SMBus on the first page and that there is a register bit to set the electrical properties to i2c or SMBus

my next concern was whether there would be a need for voltage translation and / or whether other i2c devices could co-exist on the same bus

since the bq20z70 operates at 2.5V i was concerned about the PIC host running at 3.3V or 5V and possibly having the bus Hi voltage dragged down by clamps or other issues, a close study showed
that there should be no issues whatsoever running the PIC at 3.3V or 5V and having other conventional devices on the same bus although i have not yet built hardware to test this

there is however a need for voltage translation when the Host is much lower than the SMBus or other i2c peripherals such as a 1.8V host (master) and slaves at 3.3 or 5V, NXP has chips for these situations

so my plan now is to use a 16F1508 or other chip with that specific feature and get someone to program the thing in C and switch the electrical type bit on the fly as required

i got the TI dev kit and withing an hour or three was able to commune with a smart battery sample, it was breathtaking to see the wealth of information available including individual cell voltages in the series stack

here is the latest on this

i now have I2CREAD I2CWRITE working on a SMBus battery and it is treat to see all the stuff in the battery

but in my previous post about the address i wrote something which was not consistent with the truth, in other words it was wrong in part

in searching for the i2c address of the bq20z70 it always seemed elusive, now i sort of see why, there are several addresses (not subsequent control registers but first order addresses) and the choice puts the fuel device device into various modes such as slave, master, host and other things

the BQ chip is not new but the data sheet just did not say, i then got a newer one and it clearly showed decimal 22 for the address as Slave

given that i was almost rolling except the data was flaky, after playing a bit i found that slowing the PIC clock down to 4MHz that things seemed better, at 2MHz rock solid, at 1MHz stopped working altogether

now i sent
I2CREAD, pin, pin, 22, 9, [byte0, byte1]
note that 22 and 9 were variables, 9 is a command
and after putting the bytes together i i got 15600
then i put my voltmeter on the battery and measured 15.60V - way fun
and there are a ton of data in there more interesting than the voltage

next point of concern was the threshold since i was not setting that bit since i was not using the i2c hardware

after examining the battery schematics and i2c levels on the scope i decided that there was no issue at all since i had solid 0V and VDD -0V for logic low and high respectively,
my battery is 4S with a single cell it is possible that the threshold concern will resurface

I'd dying t see pictures, PCBs , anything you have doing this project.

Interfacing with a car computer to get access to the status of all systems is on my to-do-sometime list.

Robert

i am happy to share what i have learned and delighted as well about PBP3 doing what needed to be done
pictures and pcbs are probably off the table due to being the property of the customer but things learned along the way in PBP are fine
i don't know about cars, isn't that CAN ?
my project has a 4 cell (4S2P) Li-ion pack with an integrated 'pcb' which contains the protection stuff and the aforementioned fuel gauge, about 80W/hr so closer to a laptop than a car
the battery 'pcb' is by the vendor
i had many concerns about the thresholds and possible protocol issues which i feared may necessitate using the I2C hardware but at the end of the day the I2CWRITE worked fine, voltage thresholds and levels were well beyond points to cause worries
in fact the i2c buss is shared with several other chips, a DAC and phillips LED blinker and all are playing nicely together
the main hurdle that cost the most time was discovering the address ('control') (dec 22), discovering how to set batt as slave (as it could be master) which 22 also accomplished

next the battle over corrupt SMBus data was won by good old trial and error, i found that i needed to slow way down (by means of OSCCON (is intosc)) to 2MHz** and then all was rock steady
trouble was that 2MHz turned out to be impractical overall (and BTW PBP does not have DEFINE OSC 2 and i needed DEFINE for many things) so i wasted a bunch of time compensating for that until i simply made everything 8Mhz and then in the GOSUB to ReadSMBus switched the OSC to 2 at the start and back to 8 before RETURN,
worked a treat!
now i just send
i2CREAD pSDA, pSCL, bFGAddr, bSMBC, [bTemp0, bTemp1]
where bFGAddr is dec 22, bSMBC is hex 11 (sorry about mixed types) and the 2 bytes get put into a word which gives me ...
RunTimeToEmpty
this word contains minutes which are dynamic and based on all the historic goes inna goes outta so as i vary the load the minutes go up and down, how cool is that ?

i can read the batt temperature, current in, current out, voltage, remaining runtime at an arbitrary current by writing something to another register, theoretical total capacity as per original setup and on an on

way more stuff than i need and kudos to TI for all this tech and kudos to MEL for these great tools that make it simple

**PS
as i recall, contrary to my expectation slower than 2Mhz was not better it started to get flaky again at 1, so 2 was the sweet spot, the I2CREAD routine is not a speed demon so i suspect the data rate is in the 10's of kHz, i did not scope it and measure it

dsicon, sorry for replying to an old thread but I just wanted to get a bit of clarification. The bit of code you posted works as is when the clock runs at 2Mhz? I'm starting a project that involves interfacing to a smart battery pack via the SMBus and there wasn't much in the way of examples.

Hi astouffer, this project is still alive for me!
i run the main loop at 8Mhz RC clock
when i call a gosub to do the SMBus via I2CREAD I2CWRITE in the gosub at the top i switch to 2MHz RC OSC on the fly and just before the RETURN i switch it back to 8MHz
this was VERY hard won for me at least, it was all proven empirically, 1 & 4MHz did not work, at least not reliably, 2Mhz seems quite solid
if there is anything else let me know
what is your operating voltage for the PIC ?
what is the batt voltage and Watt hours? (shouldn't matter much unless maybe is only one cell, just curious)
what is the fuel gauge chip in the battery?

The PIC will be a power supervisor in this application and we're going with two of these battery packs http://www.cell-con.com/pdf/D90494_DataSheet_BP.pdf.

What voltage does the SMBus use? If its 5 volts then that will be the PIC voltage. The PIC is going to monitor the battery time remaining and have some status LEDs and probably watch the temperature as well. If the batteries get too low then its going to disconnect the equipment. Nothing real fancy. I'm not sure what fuel monitor chip the batteries have but they do have 24 possible values to read from.

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.

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)

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

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

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.

Quote:

---

I tried waiting for the SSP1IF interrupt, but it never happened!

---

Hmm. After you initiate the START (SEN=1) and then wait for SEN to go low (SEN=0) you should be able to clear SSPIF before you write to the SSPBUF.

If you look at that figure once you write to the SSPBUF you'll see BF being asserted on the 8th clock, but SSPIF isn't asserted until the 9th after the ACK.