Doing my own I2C, would like some hint/help

Erlend

Yes, I know there are plenty of I2C drivers out there, but I want to do it my way so that I really learn the protocol.
I am launching into debugging now, and would appreciate help and hints to where I have failed. The first 'demo' I am trying out is a bus scan routine to check who is connected. The guy who is connected, an MCP32017, does not reply, so there I am.
Before I launch into real head scratching, hook up a scope or an analyzer, start getting entagled in probe wires, debug code, etc. maybe ask the forum for help? The project files are attached.

Erlend

JonnyMac

I ran your buss explorer program and it did see the boot EEPROM. When I attempted to read from it the program kept asking me for the device and register addresses. On examination, I found that you're missing quit commands after you read a value, which locks that code in a loop unless you want to abort. Once I added quit where required I was able to read a value from the EEPROM (verified with F8 in Propeller Tool).

PUB Read | ChipAddr, RegAddr, AddrForm, value 

    REPEAT
      pst.Str(String("Enter Chip address (HEX):"))
      ChipAddr:= pst.HexIn
      pst.Chars(pst#NL, 2)
      pst.Str(String("Enter Register address (HEX):"))
      RegAddr:= pst.HexIn
      pst.Str(String("-1-Quit, 1-8bit format, 2-16bit format, 3-32bit format:"))
      AddrForm:= pst.DecIn      
      pst.Chars(pst#NL, 2)
   
      CASE AddrForm
          1  : value:= bus.ReadChipA8(ChipAddr, RegAddr, bus#NAK)
               quit                                                             ' need to add this
          2  : value:= bus.ReadChipA16(ChipAddr, RegAddr, bus#NAK)
               quit                                                             ' need to add this
          3  : value:= bus.ReadChipA32(ChipAddr, RegAddr, bus#NAK)
               quit                                                             ' need to add this
          -1 : RETURN
        OTHER: pst.Str(String("Chose -1, 1, 2, or 3!"))
               pst.Chars(pst#NL, 2)
               
   pst.Str(String("Reply from chip: $"))    
   pst.Hex(value, 4)
   pst.Str(String("   %"))
   pst.Bin(value, 32)
   pst.Str(String("   Dec: "))
   pst.Dec(value)
   pst.Chars(pst#NL, 2)
   pst.Str(String("Completed."))   
   pst.Chars(pst#NL, 2)

LoopyByteloose

If all else fails, learn the SPI interface first and then see how all the I2C features are added in.

I2C has more features, so it is harder place to start out with.

Erlend

Thanks. I managed to replicate that. Just had to wire a PU resistor to the SCL of the boot EEPROM in order that the code would see SCL going high when released.
Have inserted the QUITs as you point out. I will continue to test my code against the boot EEPROM now that that I know it works, and then I will investigate later why MCP32017 is not responding. (It is working with your code).
Thanks again for the help,

Erlend

Erlend

Loopy Byteloose wrote: »

If all else fails, learn the SPI interface first and then see how all the I2C features are added in.

I2C has more features, so it is harder place to start out with.

Sounds good. SPI is next, so should be easy now

Erlend

LoopyByteloose

SPI is not only simpler, it is faster.

I have always felt the Propeller 1 boot from I2C EEPROM to be a bit slow. From SPI it would be much faster.

I2C has more to offer a shared bus of two wires, but that has never seem to have worked out on the Propeller.

There are other pros and cons. SPI usually requires at least one more i/o pin.

JonnyMac

I2C has more to offer a shared bus of two wires, but that has never seem to have worked out on the Propeller.

Really? I use the I2C pins in many of my projects -- it has worked out very well. You're right, SPI can be faster, but it takes more pins; as ever, we have to make a choice.

I once coded a project (for an HVAC system in China) that used MCP23017s (I2C) and a bunch of SPI parts. We had so many SPI parts that one of the banks of an MCP23017 was used to control the CS lines of the SPI devices.

DavidZemon

Erlend wrote: »

Loopy Byteloose wrote: »

If all else fails, learn the SPI interface first and then see how all the I2C features are added in.

I2C has more features, so it is harder place to start out with.

Sounds good. SPI is next, so should be easy now

Erlend

One can only assume you're going to write an SPI slave object. There are lots of master objects, what we really need is an SPI slave object!!!

Tracy Allen

One gripe about i2c is when manufacturers provide only one address option. If you want two of the same chip on one bus, you're out of luck. I'm thinking about the Sensirion SHT21, 8-bit devID=$80. Why--It is a 6-pin package with 2 of the pins NC?! Some chips manage to get 16 addresses out of two address pins.

One I'm onto now is the LMP91000 interface to gas sensors (potentiostat). We need to measure 4 gasses, CO, NO, NO2, O3. But it offers only one address, 8-bit $90, despite having NC pins. Instead, the '91000 has an active low chip-select, so multiple devices on a bus requires the same number of pins as SPI.

Erlend

@Tracy
What triggered my I2C effort was actually the one-address problem you are describing, but in this case the V6180X laser ranger chip. This chip can be reprogrammed to a new address, but looses this after power down. My idea is to stage the power-on of several chips tied to the sam bus - by means of RC delaying the power such that they come 'online' one after another. As soon as the first chip gets alive it gets a new address, then the next, and so on. The Sensirion chip is too stupid though, it even pulls SDA and SCL low when it looses power, and the LMP91000 is not much better - with a fixed address.

Erlend

Tracy Allen

I'd be cautious with that scheme, bringing up power one at a time. Will it work? I'd guess problematic, because the devices that are not powered will pull down the i2c buss through their substrate diodes, or else put them in a neverland half-on state. The rule more than the exception.

I've had situations where I've wanted to power down one device on an i2c bus while keeping other devices on the same buss up and running. That entailed use of a bus isolator (TXS0102), to go high impedance on sda and scl.

Today we're working with a CO2 sensor that not only has one available address $D0, but it also uses both clock stretching and a multistep process with checksums to read out a simple word of data. The difficult thing about i2c is usually not the basic steps. It's the variety of higher level protocol and registers they require.

LoopyByteloose

From what little I know and can observe, it appears that a lot of sensor companies avoided the I2C interface as they had to license from Siemens.

Some use the the 'standard' SPI, and other try to avoid legal difficulties by using an exotic non-standard SPI.

The net result is that a project might end up with both I2C and SPI being involved. And the SPI might be slowed down or modified for just one 'must have' sensor.

Peter Jakacki

Loopy Byteloose wrote: »

From what little I know and can observe, it appears that a lot of sensor companies avoided the I2C interface as they had to license from Siemens.

Some use the the 'standard' SPI, and other try to avoid legal difficulties by using an exotic non-standard SPI.

The net result is that a project might end up with both I2C and SPI being involved. And the SPI might be slowed down or modified for just one 'must have' sensor.

Philips (now NXP) developed I2C in the 80's and the licence I believe is not about money but more to do with compliance to the standard if you are wanting to obtain an I2C address. Anyone is free to develop a "2-wire bus" as Atmel have done and SMBus also which is I2C'ish but not necessarily compliant. Some sensors seem to implement their I2C'ish slave interface in software as it seems to be "flakey" and non-compliant.

But the biggest hassle with I2C devices is the setting of its address and it seems to me they should be more like 1-wire devices with a unique serial number as well as an easy fixed address. That way a similar search function could be applied to manage larger sensor networks.

Erlend

Tracy Allen wrote: »

I'd be cautious with that scheme, bringing up power one at a time. Will it work? I'd guess problematic, because the devices that are not powered will pull down the i2c buss through their substrate diodes, or else put them in a neverland half-on state. The rule more than the exception.

I've had situations where I've wanted to power down one device on an i2c bus while keeping other devices on the same buss up and running. That entailed use of a bus isolator (TXS0102), to go high impedance on sda and scl.

Today we're working with a CO2 sensor that not only has one available address $D0, but it also uses both clock stretching and a multistep process with checksums to read out a simple word of data. The difficult thing about i2c is usually not the basic steps. It's the variety of higher level protocol and registers they require.

Fortunately this chip has a dedicated boot/reset pin that I can use. Holding it LOW will prevent the chip from booting. A single Prop pin can do all the chip boot pins. I am soon at the stage of testing this scheme.

Erlend

ratronic

Erlend when you started this thread I was playing around with I2C

to get ready for a new toy I ordered from SparkFun. Mine has a

40Meter range and with some tricks distance can be sampled

at up to 500Hz. With a $10 off coupon and free shipping I couldn't resist.

Erlend

ratronic wrote: »

Erlend when you started this thread I was playing around with I2C

to get ready for a new toy I ordered from SparkFun. Mine has a

40Meter range and with some tricks distance can be sampled

at up to 500Hz. With a $10 off coupon and free shipping I couldn't resist.

A must have! Details please, I need to make sure I have more chips coming in than I have managed to interface, but now I was about to catch up...

Erlend

ratronic

It is a LIDAR-Lite v2 by PulsedLight. It is supposed to be here friday.

The thing that sold me on it was it can be setup like a Ping w/ PWM

output representing the distance.