I2C Question

Discovery

Can the 8-COG Propeller interface with more than one I2C network?
What is the best I2C cable for long distance reliable data transfers?
What are recommended connectors to PC Boards, bulkhead connectors and cable connectors?
Discovery

SRLM

Any pair of pins on the Propeller can do I2C. It's all software. Personally, I use a C++ object in libpropeller to do I2C without using an extra cog. Anyway, you could connect up to 16 different I2C pairs (32/2 = 16).
https://github.com/libpropeller/libpropeller/blob/master/libpropeller/i2c/i2c.h

I2C isn't really a long distance (meters+) type of thing. If you need something further then you should consider using either wireless or a differential signal (eg, RS232).
Most hobbyists just use a 4 pin header for I2C: https://www.parallax.com/product/451-04001 It's easy and inexpensive.

kwinn

For I2C I have used a 20mA current loop and RS422/485 drivers up to about 100 feet. Also tested RS485 on a 1000 foot roll of cat5/6 cable (still in the box) on my bench.

LoopyByteloose

RS485 and one twisted pair for half-duplex asynchronous serial.
RS422 and two twisted pairs for full-duplex asynchronous serial.

I guess kwinn is saying there is a way to combine the RS422/485 drivers with IC2, but I am a bit uncertain as to how many twisted pairs might be involved... maybe three.

1000 feet is not much distance for RS422/485 drivers, you can go miles and miles with repeaters.

IC2 is really for more local stuff. Nintendo did use it for game controllers at the end of a meter or two of wire, but that was a stretch.

Discovery

Very good.
My network design is a"Y" with two legs of the "Y" about 450 feet and the short leg at about 6 inches from the Propeller.
Do you have an RS485 implementation that I could test?
Discovery

jmg

My network design is a"Y" with two legs of the "Y" about 450 feet and the short leg at about 6 inches from the Propeller.
Do you have an RS485 implementation that I could test?


The local one can be pin-direct, the longer one will need buffers. What speed can you tolerate ?

You can also use CAN transceivers, or RS485 wired in  CAN-like mode (TX=1, Drive OE)
Note : That gives a 2-wire split of the SDA line - Is there a Prop at each end,  or a std i2c device ?

Addit: For devices that can handle that 2-wire split of the SDA line, see also
http://forums.parallax.com/discussion/118409/long-distance-i2c
and it looks like the PCA9600 has the required split of SDA/SCL to drive Opto couplers or CAN/RS485
( NXP mention  PCA9600 + PCA82C250)

This app-note gives wiring for CAN/ RS485 / Opto
http://www.nxp.com/documents/application_note/AN10364.pdf

Discovery

I originally designed the data communication system as a "Y" but since the Propeller can handle any number of I2C networks I could easily design two I2C networks rather than the single "Y". 
I expect about 220 I2C sensors on each leg of the "Y" or on each single network. A single Propeller will be used.
Discovery

Discovery

Thanks for the data links...I shoud be able to finish the design and run tests.
The data rate is low...just lots of sensors but not time critical.
Discovery

Peter Jakacki

How are you intending to address 220 sensors on each I2C leg? What type of sensors are they then?

jmg

I expect about 220 I2C sensors on each leg of the "Y" or on each single network. A single Propeller will be used.The data rate is low...just lots of sensors but not time critical.

 That's a lot of sensors, a Full Buffer + CAN Transceiver on each node may get expensive, but it would be the most reliable. There are also Buffers from OnSemi, intersil, TI as well as NXP, and you may need to test some.Sounds like good ESD rating would help too.

Discovery

The sensors will include temperature, humidity, analog to digital, open drain discrete outputs, discrete inputs, and an LCD display. Addressing 220 sensors on each I2C leg...I don't know yet. I ordered a few I2C devices with which I will perform some experiments. I had no problem addressing OneWire devices over 100 feet of Coax cable (RG-58) since each device has its own unique address. If I have a problem I can access OneWire devices through a Propeller-to-BS2p bi-directional bus. 
By the way, can the Propeller communicate using the OneWire protocol using C++? I did not see any description of a command in the list of C++ commands.

Discovery.

Peter Jakacki

You cannot address many of the same devices on an I2C bus, it is very limited as some may have sub-address pins to allow up to 8 of the same devices on the bus. Obviously you haven't looked into this as there is no way you can address hundreds of the same device on the bus. You can however connect 1-wire devices to the Prop very easily although I can't see why you think you would need a BS2 for this.

The other way I would handle this is to use very cheap (less than 50 cents) micros with temperature sensors and A/D on-board and connect them all up on a single half-duplex line directly if they are not too far away or else RS485 for much longer distances. I am designing in some EFM8BB10F8G-A in SOIC16 for less than 50 cents each and these have 12 channels of 12-bit ADC and temperature sensing as well as I2C/SPI/UART etc and 8kB of Flash CPU running at 25MHz.

BTW, Tachyon has extensive 1-wire support as well and MJB and Brian Riley have large sensor networks running in Tachyon.

DavidZemon

The sensors will include temperature, humidity, analog to digital, open drain discrete outputs, discrete inputs, and an LCD display. Addressing 220 sensors on each I2C leg...I don't know yet. I ordered a few I2C devices with which I will perform some experiments. I had no problem addressing OneWire devices over 100 feet of Coax cable (RG-58) since each device has its own unique address. If I have a problem I can access OneWire devices through a Propeller-to-BS2p bi-directional bus. 
By the way, can the Propeller communicate using the OneWire protocol using C++? I did not see any description of a command in the list of C++ commands.

Discovery.

You can use most any communication protocol you want with the Propeller - you just have to write it yourself (or find someone else who already has). After googling  "one wire driver bit bang" I was able to find this in C. You'll need to convert it from MSP430 to Propeller, but that shouldn't be too hard:https://github.com/dsiroky/OneWire
Look at onewire.c and onewire.h

JonnyMac

The sensors will include temperature, humidity, analog to digital, open drain discrete outputs, discrete inputs, and an LCD display. Addressing 220 sensors on each I2C leg...I don't know yet. I ordered a few I2C devices with which I will perform some experiments. I had no problem addressing OneWire devices over 100 feet of Coax cable (RG-58) since each device has its own unique address. If I have a problem I can access OneWire devices through a Propeller-to-BS2p bi-directional bus. 
By the way, can the Propeller communicate using the OneWire protocol using C++? I did not see any description of a command in the list of C++ commands.

Discovery.

Neither I2C nor 1-Wire is designed for long-distance coms; as others have suggested, you're better to go with smart nodes sitting on an RS-485 buss.
I (and others) have written 1-Wire code in PASM -- should be easy to adapt to C/C++.

Discovery

You are correct Peter...this is my first look at I2C for communications. Re-calculating...I could use the I2C bus for the LCD monitor and keyboard only then use a shorter distance One-Wire for my sensors and actuators.
I tied the BS2p to the Propeller so that I could communicate with One Wire devices without having to write a protocol driver...which I have never attempted.
If someone could point me to a working Propeller C++ code that fully implements One Wire protocol that would be very helpful. I looked at the MSP430 code and it hurt my head.
Discovery

JonnyMac

I've attached my 1-Wire driver. The high-level interface is Spin so you'll have to replace with C. The critical stuff is in PASM and uses the mailbox approach which means it can be used with languages other than Spin.
1-Wire is well defined and not very difficult to implement. I've seen others claim to write the critical elemetns in Spin, but I don't believe it fast enough. Compiled C/C++ will surely be fine.

Discovery

Thank you Jonny.
Discovery

Discovery

Jonny,
I have written only SimpleIDE C programs and no spin code.
I was wondering if I can write the code you supplied into my 8X32 Propeller.
How would I proceed?
Discovery

JonnyMac

It would serve you well to learn Spin. If you're motivated, you can master it in a day. It will give you the quickest path to learning the Propeller's architecture and taking advantage of mutli-core apps. Remember, Spin was specifically designed for multi-core, and designed to be easy.
If you can program in C, you can learn Spin. Once you get comfortable you can create a C interface to my PASM code (others have done it for things like my WS2812 LED driver). 
The code I posted is an object (library); it is designed to be used by another app.

Peter Jakacki

If you load the binary image of Tachyon Hardware Explorer (as in my sig) into your Prop it will boot up at 115.2k baud and locate all the 1-wire devices that you may have on your system automatically. You can then interact with each device etc through the "command line" or Forth prompt.

Peter Jakacki

If you load the binary image of Tachyon Hardware Explorer (as in my sig) into your Prop it will boot up at 115.2k baud and locate all the 1-wire devices that you may have on your system automatically. You can then interact with each device etc through the "command line" or Forth prompt.

EDIT: Found an old post where Tachyon scans all the port pins and reports back and in this case this is the part where it found all the 1-wire devices I had.

Scanning for 1-Wire devices from P0 to P27
P11-01:  DEVICE# 0000.03C3.6AB8  = 18B20 THERMOMETER
P11-02:  DEVICE# 0000.03B2.CB9D  = 18B20 THERMOMETER
P11-03:  DEVICE# 0000.06D6.3C3C  = 2401 SERIAL ID
P23-01:  DEVICE# 0000.000C.00DA  = 2450 QUAD ADC
P23-02:  DEVICE# 0000.06D6.535E  = 2401 SERIAL ID

jmg

The sensors will include temperature, humidity, analog to digital, open drain discrete outputs, discrete inputs, and an LCD display. Addressing 220 sensors on each I2C leg...I don't know yet. I ordered a few I2C devices with which I will perform some experiments. I had no problem addressing OneWire devices over 100 feet of Coax cable (RG-58) since each device has its own unique address. If I have a problem I can access OneWire devices through a Propeller-to-BS2p bi-directional bus. 
By the way, can the Propeller communicate using the OneWire protocol using C++? I did not see any description of a command in the list of C++ commands.

Discovery.

A bigger issue than 'one wire' is the 450' and 220 nodes, of varying types.
You need to decide what speed is ok, and I'd look for a Transceiver+Regulator (sometimes called System Basis chips) If network scan times in the order of 0.3~1s are ok, then LIN transceivers will be okIf you need more, then I'd look at CAN.Both can come with regulators in one package. (LIN example is NV7428?3)
The small MCUs Peter suggested would be ideal, as they can address 256 nodes easily.