I2C to RS485 converter

Thread Starter

Vindhyachal Takniki

Joined Nov 3, 2014
594
1. I need a I2C to RS485 converter. Preferred is hardware based solution so that no MCU programming is required & low power since system is battery powered.
2. I2c specs are attached to be matched. If 400khz is fast, then I can limit 100Khz.
3. I was loking for MAX1307 and SC16IS750IBS.
looks like they can fit the solution.
4. Any other suggestions or better solution? Provided low power & dont want to add code/MCU support in it, looking for hardware based solution.
5. Only single I2C device will be connected. No more than that. i2C pins are pulled by 10K to 3.3Vdc

Untitled.png
 

ErnieM

Joined Apr 24, 2011
8,377
Your requirements are a bit bizarre in the details.

The MAX1307 is a parallel interface A2D converter with no I2C capabilities. In fact it has no capabilities at all as it is obsolete and only found on the secondary market.

The SC16IS750IBS already IS a UART that would already be the basic block you seek.

So just what are you up to? Forget the parts you think you need, what is your system doing?
 

Thread Starter

Vindhyachal Takniki

Joined Nov 3, 2014
594
Ohhh.
It was Max3107.

One one side I have Texas Instrument's bq34z100-g1.
Need to increase the communication wire length & read it on MCU on host side using RS485. SO I was thinking of using some bridge converter.
 

ErnieM

Joined Apr 24, 2011
8,377
Are you aware that both the SDA data line AND the SCL clock line are both bidirectional lines? That is why they both use pull up resistors.

How far apart are they? I2c is intended for short range stuff.

You might want to look into I2C extenders such as the PCA9507 from NXP.
 

schmitt trigger

Joined Jul 12, 2010
872
This is a common occurrence.....the I2C is such a versatile and useful bus, that we (and I include myself) want to use it for distances that it was never intended for.

What I ended up doing on an application (remote temperature sensing) was to use I2C bus extenders from NXP. They worked fine for distances up to 5 meters. Of course, I also had to operate at low speed.
 

ErnieM

Joined Apr 24, 2011
8,377
RS485 is totally unsuitable to transmit the I2C data directly. It is not bidirectional in the same sense as I2C.

To use RS485 you will need a micro to convert to data to some sort of packet each side can understand.
 

Thread Starter

Vindhyachal Takniki

Joined Nov 3, 2014
594
Hi,

A)Circuit:
1. I am using TI's bq34z100-g1 in device. It has I2c communication. Usually we connect an external MCU(I2c master), to read the bq34z100-g1 registers. Standard it has three pins SCL, SDA & GND(GND & BAT- same thing).
2. But in battery applications, we have another negative terminal called pack-. Bat- & Pack- are separated by inline sense resistor, charge & discharge mosfets, to protect the battery in case of any battery related error.
3. In outer battery pack case, we have four terminals: Pack+ , Pack- , SCl & SDA. Pack+ is battery positive voltage.
4. In normal operation, both fets are on, so bat- & pack- forms a path via a sense resistor. But in case of error, one of two or both fets are off, in that case connection between bat- & pack- breaks. & so does communication.

B)Goal:
1. To convert communication from I2c to such an interface, where this ground issue does not come in between. Communication happens without gnd line requirement.
2. Since circuit is to be used in electronisc vehicle, so I want communication with higher level of noise immunity.
3. Additional optional is, conversion from i2c to required interface, should be such no programming in interface conversion is required. Should be hardware asic based.
4. If third is not possible, then I can do MCU programming is required. But it will involve code time & other times like testing. So not an preferred option.
5. Since entire is battery powered, so lowest power consumption possible is preferrable.

C)What interface I selected:
1. Based on these I have selected RS485 communication.
2. I am open to suggestion or any other better interface solution.


D)What RS485 solution I have come up with:
1. Since I2C is bidirectional interface, so I have to select full duplex RS485.
2. I am thinking of using NXP's SC18IM700 & TI's SN65HVD70.
3. SN65HVD70 is Full-Duplex RS-485.
4. SC18IM700 is Master I2C-bus controller with UART interface.
5. SO bq34z100-g1 will be connected through SC18IM700. Then SC18IM700 will be connected to SN65HVD70 for full-duplex RS485.
6. On host side, I will have another SN65HVD70 & a uart based MCU for reading through registers of bq34z100-g1.

E) How does it solves the purpose:
1. No gnd related issue now. Even if bat- & pack- gets disconnected, I don't have problem of communication.
2. Since communication is RS485, so noise immunity will be there.
3. Power consumption of SC18IM700 is high is in 5mA in idle mode. It has sleep option, But cannot use it, since to wake up it needs its pin to be pulled down, which is not possible, as in outer case I have only four connections.

F)Suggestions/Reviews:
1. What are suggestions or reviews on this?
2. Any other solution for this?
3. Any way I can reduce power consumption?
 

ErnieM

Joined Apr 24, 2011
8,377
F)
1. Fail. Bidirectional data via an open collector wired or connection cannot be replaced by RS485.

2. Asked and answered.

3. Reduce the power of what?
 

Thread Starter

Vindhyachal Takniki

Joined Nov 3, 2014
594
Hi,

1. Attached is the circuit diagram which I am talking about.
It has a complete battery unit, from where 4 outputs are coming.
Pack+ & pack- are for power. SCL/SDA are for data read.

2. Bq34z100-g1 is powered from battery inside & there is another circuit inside this entire pack, which controls charge & discharge fets.

3. Bq34z100-g1 Vss connection is with Bat-, while battery pack return is through pack-.

3. Now problem which I am thinking will come is, as long as there is no error, both fets are on, communication will be ok, as there will be only sense resistor between BAt- & Pack-.
But when one or both fets are off, there will be a communication break.

4. I cannot bring out bat- terminal from the pack. Thats why I am thinking of some way that I can read through it even if any/both mosfets off.
Also want communication to be immune to noise.

5. Two ways communication can happen, external host is powered from pack+ only or have seprate supply.

6. What could be solution in this.
I am also looking reading datasheet of NXP's PCA9615 at the moment if it fits the application.


7. External four wire connector, I can choose, how many connections there. Can increase from 4. No issues there. Task is to solve these:
a) communication dont break even if fets gets off
b) noise immune for vehicle application
c) low power
 

Attachments

Thread Starter

Vindhyachal Takniki

Joined Nov 3, 2014
594
@ErnieM , Given my circuit in post#10, & using SC18IM700 with SN65HVD70, I am pretty convinced that I can achieve what I wanted to do here.
SC18IM700: Master I2C-bus controller with UART interface
SN65HVD70 is Full-Duplex RS-485.

1. First the bat- & pack- disconection, as described in post#10, in that case communication will not break.
2. Differential signal for noise immunity is achieved.
3. Power is issue that we can discuss later.


But first can u explain why these two points cannot be resolved?
 

JohnInTX

Joined Jun 26, 2012
4,787
@ErnieM is right that you can't do physical I2C over RS-485 but..If I understand what you are saying ,you propose to:

Drive the I2C at the battery pack with the SC18IM700 I2C to UART converter. The SC18IM700 will be located at the battery pack to avoid long unbalanced lines that pick up noise etc.
You would drive each of the RX/TX lines with a balanced, one way RS-485 pair using the SN65HVD70. That would make the RX/TX lines to the UART-I2C converter more noise-immune.
At the other end, you would receive the two balanced RS-485 lines and recover the single-ended RX/TX with another SN65HVD70 and get single ended async back.
You would talk to the battery pack registers by creating (convoluted) UART messages for the SC18IM700.

That would probably work. The downsides I see include:
The messages get bigger and no longer I2C since you specify the nuts and bolts of the I2C in UART-speak.
You still don't get any error detection/correction.
It is strictly one master, one slave. No multiple slaves since the RS485 scheme has no arbitration facility.

Personally, I would break down and use the CAN bus. Use a little CAN uC on the receiving end and a CAN-equipped main processor or a SPI CAN interface on your main controller. Assign each register/set to a COB_ID on the little CAN uC and let er rip. Using CAN would provide the noise immunity of a balanced pair with automatic error detection/correction/notification. Send your messages. If the CAN error counts are 0000 you are golden. Multiple masters/slaves are a non-issue as well.

I have actually done CAN-I2C bridges and this wouldn't be super hard but yes, there is some uC programming involved. The good thing is that once the code is done, CAN does all the hard stuff..

Good luck.
 

Thread Starter

Vindhyachal Takniki

Joined Nov 3, 2014
594
@JohnInTX @ErnieM ,

do u think NXP's PCA9615 can also work here?
1. From reading its datasheet I am not quite sure whether it can solve Bat- & pack- break issue.
2. Can be as immune as RS485, which can be used in electronic vehicle.

@JohnInTX As per your suggestion, at the moment I am looking for some hardware based solution. For CAN I have to learn the protocol & make code also. That option I would consider in the end if no other option available
 

ErnieM

Joined Apr 24, 2011
8,377
do u think NXP's PCA9615 can also work here?
This looks like a very good choice
1. From reading its datasheet I am not quite sure whether it can solve Bat- & pack- break issue.
Your "sketch" (it's not a schematic) is a mess. Q1 is just going to waste power and not control anything.

The PCA9615 can handle ground imbalances up to 1/2 the supply voltage. This does not include breaking the ground conection. I suggest leave ground always intact and you change your switching to high side switches.
2. Can be as immune as RS485, which can be used in electronic vehicle.
I see no ratings to suggest anything definitive, but this is very possible.
 

Thread Starter

Vindhyachal Takniki

Joined Nov 3, 2014
594
@ErnieM , Q1 solves the purpose. It get turned by internal circuit in case of faults. THere is whole logic & ckt behind it. The circuit is for sample only.
for PCA9615, I have make two supplies. Thats an issue.
Cannot swicth to high side fets. Not possible in this ckt.

I am more interested in using SC18IM700 & SN65HVD70.
Can this be used & this bat- & pack- communication break problem, can be solved by these two?
 

cmartinez

Joined Jan 17, 2007
8,220
1. I need a I2C to RS485 converter. Preferred is hardware based solution so that no MCU programming is required & low power since system is battery powered.
2. I2c specs are attached to be matched. If 400khz is fast, then I can limit 100Khz.
3. I was loking for MAX1307 and SC16IS750IBS.
looks like they can fit the solution.
4. Any other suggestions or better solution? Provided low power & dont want to add code/MCU support in it, looking for hardware based solution.
5. Only single I2C device will be connected. No more than that. i2C pins are pulled by 10K to 3.3Vdc

View attachment 124435
Have a look at these two chips, the AM26LS31 and 32. They are quadruple differential line drivers and receivers that I've been successfully using for a different application. But that might come in handy in your case too.
 

Attachments

JohnInTX

Joined Jun 26, 2012
4,787
Could you provide an end-to-end schematic/block diagram of the latest concept with details at the ends where the TX/RX/power-down happens?

Last word and food for thought: Even when you cobb functional modules like this together, you still have to deal with the power issues, protocols, error detection/correction yada yada. That will take development time and probably some field revisions. That time could be spent in getting up to speed on CAN which, again, is designed exactly for this kind of thing. I find from experience that adapting a solid platform (PIC with CAN/I2c) to specific needs is better than cobbing something together then finding all of the flaws/oversights that I didn't think of originally (pioneering). Plus, if you are in the automotive arena, you'll encounter CAN sooner than later anyway - that's what CAN was designed for in the first place.

Just my .03, you will get support here whatever you decide.
 
Top