THANKS for the response! Just before receiving your response, I figured out just what you suggest. I added a stop before the start, and it works! Here are my notes on it: After a bunch more investigation, it appears the I2C under C18 (and perhaps under assembly) does not like having a start without having a stop before it. The X1226 says to read a random byte, send a start, send 0xae, send high address, send low address, send start, send 0xaf, read data, send stop. As noted in my previous posting, the 18c452 doesn't properly send the start after the low address. It turns out that the random address read on the X1226 is really a "set current address" followed by a "read next byte". Normally each of these commands would have a start before them and a stop behind them. In this single "random address read", however, the stop before the start of the "read next byte" is left out. This is where the 18c452 seems to have a problem. Putting a stop before the start solves the problem. Actually, I'm probably going to change my functions from a random read and write to a sequenctial read and write, and a separate function to set the current address. I'll consider making another set of functions that check idle. I'd have to duplicate pretty much all the functions, but that might be ok. Again, THANKS! Harold On Tue, 9 Jul 2002 20:42:30 +0300 "Peter L. Peres" writes: > I do not use that compiler but I have seen your problem before. Some > libraries do not implement Start entirely (they make assumptions > about the > line state which are not true here). So I add a proper Stop before > the > start and it works. If you look at the implementation of the > StartI2C you > should see the problem. > > Also, your code calls a lot of functions. Maybe there should be two > versions of > the I2C functions and you should use the blocking ones (the ones > that already > check for IdleI2C() inside them). > > Peter > > On Mon, 8 Jul 2002, Harold M Hallikainen wrote: > > >I'm having trouble figuring out how to use I2C from within the C18 > >compiler. Here's my code > > to read a byte from an X1226: > > > > unsigned char ReadU8eep(unsigned int addr){ > > // Read a byte from eeprom chip at addr > > unsigned char data; // Keep our data while we close the I2C > > OpenI2C(MASTER, SLEW_ON); // Initialize the I2C as a master > > // SSPADD=22; // 400 kbps with 40 MHz clock > > SSPADD=0xff; > > IdleI2C(); // Wait for i2c to be ready > > StartI2C(); // Send a start > > IdleI2C(); // Wait for i2c to be ready > > WriteI2C(0xae); // Send the slave address with the r/-w low > indicating > >we're writing an > > address > > IdleI2C(); // Wait for i2c to be ready > > WriteI2C(0xff & (addr>>8)); // Send the high half of the address > address > > IdleI2C(); // Wait for i2c to be ready > > WriteI2C(0xff & addr); // Send the low half of the address > > IdleI2C(); // Wait for i2c to be ready > > StopI2C(); // Add this > > > StartI2C(); // Send a start > > IdleI2C(); // Wait for i2c to be ready > > WriteI2C(0xaf); // Send slave address with r/-w high indicating > we're > >reading > > IdleI2C(); // Wait for i2c to be ready > > data=ReadI2C(); // Get the data > > IdleI2C(); // Wait for i2c to be ready > > StopI2C(); // Send an I2C stop > > IdleI2C(); // Wait for i2c to be ready > > CloseI2C(); // Done with I2C > > return(data); // Exit with the data we got > > } > > > > The documentation on the I2C library only gives sample code > for > >talking with Microchip > > EEPROMs, so I had to try to figure out how to talk with the Xicor > part. > >I'm assuming IdleI2C() > > is required between instructions to insure the SPP has finished > the > >previous instruction. > > Watching the transaction on a scope, the problem SEEMS to be > with > >the StartI2C() after > > sending the low half of the address. After the 8th clock, another > clock > >is sent and data is > > held low (I assume by the X1226) for an acknowledge. Then, the > clock > >goes low. The > > StartI2C() seems to do nothing. The clock and data both remain > low. > >After the acknowledge > > clock (about 12us) is a very short clock (less than 4us). It > appears the > >data line is released > > at the same time as the clock line. This MIGHT be an attempt at > sending > >a start, but it > > clearly fails. The clock goes low after the 4us or so while data > remains > >high through the next > > full clock (the start of sending 0xaf). When we get down to > reading data > >back using ReadI2C, > > the data line just stays high. I think the EEPROM ignored the > command to > >output its data > > because of the lack of a start. > > So, anyone done I2C using C18? > > > > Thanks! > > > > Harold > > > > > >FCC Rules Online at http://hallikainen.com/FccRules > >Lighting control for theatre and television at > http://www.dovesystems.com > > > >Reach broadcasters, engineers, manufacturers, compliance labs, and > >attorneys. > >Advertise at http://www.hallikainen.com/FccRules/ . > > > > > >________________________________________________________________ > >GET INTERNET ACCESS FROM JUNO! > >Juno offers FREE or PREMIUM Internet access for less! > >Join Juno today! For your FREE software, visit: > >http://dl.www.juno.com/get/web/. > > > >-- > >http://www.piclist.com hint: The PICList is archived three > different > >ways. See http://www.piclist.com/#archives for details. > > > > > > > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body > > FCC Rules Online at http://hallikainen.com/FccRules Lighting control for theatre and television at http://www.dovesystems.com Reach broadcasters, engineers, manufacturers, compliance labs, and attorneys. Advertise at http://www.hallikainen.com/FccRules/ . ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body