Originally Posted by Dr Strangelove
You're right, it is a short document which is why I was asking for a little more info. No, I have never tried to communicate with I2C before. I note that pull up resistors are required. What value should I use? No doubt I could search the I2C standard, or some friendly person could just give me the benefit of their experience. I assume the resistors are 10k and go between the lines and a 5v supply?
Again, if anyone feels like sharing some code that works, that would be great. If not, that's cool too.
There is no "right" value for the resistors. With a 5v system on a circuit board, you probably want to be around 4.9k. That would probably also work with the short wires off the ET sensors as well.
As wiring gets into the foot plus range...or you use a lower voltage system...or you start using a solderless breadboard...you need stronger (lower ohm) pull ups to overcome the capacitance.
The resistors are there to make the lines "snap" to the high-state when nothing is pulling them low. Too weak (high ohm) and the state doesn't change fast enough and you get communication errors. Too strong (low ohm) adds unnecessary stress to the controller, altimeter, etc.
I'm using a 3.3v system with a PIC 24F microcontroller, an (I2C) eeprom on board with the micro and header connectors into which I plug the ET altimeter and a CrystalFontz I2C display (CF-533-KC). I use 2.2k pull-ups.
5v and 4900 ohm would mean 1ma current. 3.3v and 2200 means 1.5. I could probably use 3k and work just fine...but I had 2.2k handy and figured with 2 sets of wires hanging off the board, a little stronger pull up would be smart.
As to code...code for what? My first test was a cut and paste of the pseudocode in the original post. I just had to make sure my PIC's I2C was properly initialized and the variables were properly declared and it worked as is. I mean...PIC C doesn't have a 'byte' type, I changed that from "byte data" to "unsigned char data"...and from "USHORT reading=0xFFFF;" to "unsigned int reading=0xFFFF;"
Any code more detailed than the pseudocode Bill put in the original doc will depend entirely on the specifics of the implementation you're attempting.
It will be much harder if you're going to bit-bang the I2C protocol (manually control the lines) such as with older micros that don't have I2C support built in.
Whatever you're working with, I'm sure I2C code relevant to that setup exists (whether it's a generic AVR implementation...or an Arduino...etc). Take any sample code that works from that, and tweak it to make the following sequence occur:
initialize (turn on / set up the I2C bus)
"START" (assert start condition on the bus)
Tx 0xE8 ( address of the altimeter in write mode)
Tx 0x07 (command to read altitude)
"RESTART" (bus condition)
Tx 0xE9 (address the altimeter in read mode)
Rx (byte 1)
Rx (byte 2)
"STOP" (do not ACK byte 2)
My current code differs from the pseudocode primarily in that I now run it as an interrupt driven state machine. I have a system that's running enough tasks that I don't want to essentially sideline everything else for the time it takes to read the altimeter.