SMBus, SBS, I2CWrite, I2CRead

[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

[Dave]

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.

[dsicon]

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 ?

[dsicon]

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

[dsicon]

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

[Demon]

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

[dsicon]

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