SMBus, SBS, I2CWrite, I2CRead

[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

[astouffer]

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.

[dsicon]

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?