Multiple I2C devices

4x5n

I'm thinking about a project that would use multiple I2C devices and would like to save pins on the propeller by using them on the same "bus". I'm wondering about the protocol for reading and writing to them. Can I "open" more then one device and read and write to them or do I have to address or "open" one read or write to it. Close it and then open the other?

Phil Pilgrim (PhiPi)

Every transaction with an I2C device on the bus must end with a "stop" condition before a "start" condition can be issued for another device.

-Phil

Mike Green

The Wikipedia has a good article on the I2C protocol. As Phil mentioned, you have to have a complete transaction with one device before you can have a transaction with another device. With memory devices, you start with the "start condition" signal transition, then a device type and selection code, an address, then one or more bytes of data are transferred, then a "stop condition" transition terminates the transaction. With other devices, the transaction is similar.

JonnyMac

Not sure if this the *best* way to handle I2C,but I have a project that has many I2C devices _and_ multiple Spin cogs accessing said devices. I wrote a very simple I2C object (just the basics) that keeps the IO pins in a DAT table so that they are shared among all devices using the driver (the first device instantiated defines the pins, in this, case the same pins used by the boot EEPROM). In the code I also have a lock for I2C access so that one Spin doesn't step on another during I2C access phases.

LoopyByteloose

The 'real world' of I2C as a single bus is that some chips support it well, some are mediocre in their support, and other chips do not clearly support it. And often in EEPROMs, the support comes in as additional pins for A0, A1, and A2.

The bottom line is that what you choose to put on a single bus will decide if that is the best option - especially with the Propeller's parallel processing availability. After all, the bus requires only two pins.

THE EXAMPLE BELOW IS COMPLETELY WRONG - PLEASE IGNORE
"But if you add another chip that requires 3 more pins to participate with that bus - the issues and alternatives begin to evolve in rather complex ways."

Phil Pilgrim (PhiPi)

Loopy Byteloose wrote:

And often in EEPROMs, the support comes in as additional pins for A0, A1, and A2. ... But if you add another chip that requires 3 more pins to participate with that bus - the issues and alternatives begin to evolve in rather complex ways.

Huh? There's nothing at all complex about strapping the A0 .. A2 pins on an I2C device so the various parts on the bus don't conflict. IOW, thse pins do not need to be part of the bus signaling but can be tied to Vdd or Vss as appropriate to avoid address conflicts.

-Phil

photomankc

JonnyMac wrote: »

Not sure if this the *best* way to handle I2C,but I have a project that has many I2C devices _and_ multiple Spin cogs accessing said devices. I wrote a very simple I2C object (just the basics) that keeps the IO pins in a DAT table so that they are shared among all devices using the driver (the first device instantiated defines the pins, in this, case the same pins used by the boot EEPROM). In the code I also have a lock for I2C access so that one Spin doesn't step on another during I2C access phases.

I'm working on adapting PASM_I2C_Driver to the same type of deal. I've got it running at 400KHz open-collector real well and with the higher speed should be able to get a lot of devices onto the same bus. I need to add the locking ability to mine as well because I envision several cogs using it to communicate to other controllers and sensors and the idea is to save pins wherever I can. Might have it posted out on the exchange in a month or two.

LoopyByteloose

@Phil
You are absolutely right, the example I gave is a bad one. But there are indeed other examples of problems. Mostly they seem to arise when mixing true I2C from Seimens licensed source and chips that are not true I2C but will somewhat work with the buss. At times, a really good chip refuses to pay Seimens to license their I2C, so they provide a non-standard bus solution, and it is up to the builder to find a way around the problem. Parallax sells a light sensing chip that is from such a manufacturer.

BTW, I do have some earlier versions of EEPROMs that do not connect the A0-A2. The feature is not provided. And then, later versions of the same do have the A0-A2 provided. That is another complication if you are reading an up-to-date PDF and building to it and then are shipped old chips.

Peter Jakacki

Loopy Byteloose wrote: »

@Phil
You are absolutely right, the example I gave is a bad one. But there are indeed other examples of problems. Mostly they seem to arise when mixing true I2C from Seimens licensed source and chips that are not true I2C but will somewhat work with the buss. At times, a really good chip refuses to pay Seimens to license their I2C, so they provide a non-standard bus solution, and it is up to the builder to find a way around the problem. Parallax sells a light sensing chip that is from such a manufacturer.

BTW, I do have some earlier versions of EEPROMs that do not connect the A0-A2. The feature is not provided. And then, later versions of the same do have the A0-A2 provided. That is another complication if you are reading an up-to-date PDF and building to it and then are shipped old chips.

IMO you are way off with your information and your statements. First off, it's Philips (NXP) that came up with I2C and license this although some manufacturers will simply rename it and call it a 2-wire bus or whatever to avoid any I2C licensing (not just fees).

I know of a lot of I2C chips and I don't know which ones you are talking about at all, perhaps you care to give the details. There has not been an I2C chip that I know of that has suddenly changed it's use of the I2C bus address modifier pins such as A0..A2. There are no complications, please don't make assertions, just stick to the facts or at least provide sufficient details.