Quickstart eeprom/i2c/sensor code issues- help please?

Rforbes

Hey all

I'm struggling to figure this out.

I've got two TC74 temperature sensors attached to my quickstart (rev and I'm using pins 28 (clock) and 29(data) for the i2c bus.

When I attach the quickstart to the usb port and load the program (attached) into RAM, the sensors work fine and everything seems great. PST happily shows what I intend in the terminal window, the temperatures are fairly accurate, etc.

But, I keep getting an error when I try to load the program to eeprom. It just won't let me do it.

If I disconnect the sensors from the quickstart I can successfully load the program to eeprom, but then when I power it back up nothing happens. PST doesn't seem to work, nothing at all seems to be happening.

Can I get some help here please? I've no clue why this is happening. The attached file is pretty short and sweet, not a lot to it other than the i2c driver. The only modification to the driver I've made is to add the address for the sensors as constants (S0 thru S7.)

Thanks in advance,
Robert

Duane Degn

I haven't looked at the program but are you aware the QuickStart had the data and clock lines switch from the order many would expect? P29 is just to the right of P26. P28 is to the right of P29.

Rforbes

Duane- Yep, got that. Wiring is fine, everything physical seems good to go. I'm just not understanding what the hangup is. The onboard eeprom uses these pins, so I am wondering why there seems to be a problem with trying to access the eeprom when the sensors are on the bus? I don't use an eeprom object to write or read anything, but I'm still trying to wrap my head around the i2c object I'm using. For all I know, I might just need to use Mike Greenes' driver or a different one.

Duane Degn

Rforbes wrote: »

Duane- Yep, got that. Wiring is fine, everything physical seems good to go. I'm just not understanding what the hangup is. The onboard eeprom uses these pins, so I am wondering why there seems to be a problem with trying to access the eeprom when the sensors are on the bus? I don't use an eeprom object to write or read anything, but I'm still trying to wrap my head around the i2c object I'm using. For all I know, I might just need to use Mike Greenes' driver or a different one.

Then I'm out of ideas. I looked at the code but nothing jumped out at me that would cause a problem. Hopefully someone else will have a useful suggestion.

Rforbes

Ok, I figured it out. My cabling isn't quite what I need. I have two TC74's connected via 8 ft branch cables to a 16 ft trunk line. At 18.6 pf / ft I'm way over the 400 pf bus capacitance limit (+/- 608 pf). Oddly, the sensors are working great with the cable setup. But since the eeprom is on the same bus, I reckon the bus capacitance is too much for the eeprom itself to work correctly. So, if I load my program into RAM it's not trying to use the eeprom and the program/sensors/etc run fine, but on starting up it tries to use the eeprom so everything goes to Smile.

Now I'm running with a total bus cap of about 190 pf and all is swell. So far...

Has anyone had much experience/success using something like the PCA9600, P82B715 or some other type of bus repeater or extender for the i2c bus cable lengths? I'd like to hear your thoughts/opinions if yer willing to share.

As always, thanks in advance!
Robert

JonnyMac

Elektor magazine often publishes circuits for I2C extending -- unless circuits were reliable I don't think they'd be published so frequently.

Tracy Allen

A lower value of pullup resistor on scl and sda might speed up the transitions enough for it to work, even with the higher i2c bus capacitance. 1kΩ or even lower.

Your sensor driver is running slow, 1000 bits per second, so there is no problem.

[SIZE=1][FONT=courier new]TS.Start(28,29,[COLOR=#020FC0]1000[/COLOR]) 'Normally 28 and 29   ---clock, data, bit_rate[/FONT][/SIZE]

The EEPROM on the other hand will be operating at over 100 times that rate, so the transition time is much more critical.

About bus accelerators. I'm familiar with the TXS0102 chip, which is meant to interface different levels on the i2c bus or to extend a bus. It has built-in 10kΩ pullup resistors, and it also has a bus acceleration feature, so that when it detects a low-to high transition on the bus, the pullup resistor essentially drops to around 50Ω for a period of 30 nanoseconds. That quickly charges the bus capacitance to the high level. The data sheet does say to take care with long runs on cable. If a round-trip reflection would take longer than the 30ns speedup time, can cause false triggering. The round-trip time on 24 feet of cable would be about 80 ns, so it could be a problem.

My own rule is to NEVER run the system i2c bus to external sensors or devices. There is just too much that can go wrong and I want to keep that away from the vital core of the system. Make a separate external i2c bus.

Rforbes

Thanks guys- I appreciate your feedback!

Tracy- your rule makes sense. I'll try to do a work around so that I don't have to use p28 and 29. Right now I have no pins free other than 30/31 but I'm using pst extensively. So, I'm thinkin' I'll need to do something else. Too tired to think of what something else might be right now. Again, thanks!

Robert