Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
Posted: Fri Mar 10, 2006 9:10 am
Well, I've solved it! Sort of.
I tracked the problem down to the line in the slave ISR "incoming = i2c_read();". It was getting stuck in there. Checking the assembly listing revealed just three instructions; it was checking the SSPSTAT "buffer full" flag and waiting until it got set before processing the data in the buffer. The flags must have been clear, but surely it should have been set (otherwise the interrupt wouldn't have been generated)? I couldn't find any code that clears that flag.
The fix was to replace that line with "incoming = *0xFC9;", i.e. ignore the buffer full flag and just read the buffer anyway.
I've checked the code for my previous I2C project (16F88 master and 18F4580 slave) and the code looks the same! Makes me very nervous that what looks like identical code should work in one place and not another! _________________ Andrew
mpfj
Joined: 09 Sep 2003 Posts: 95 Location: UK
Posted: Fri Mar 10, 2006 9:42 am
andrewg wrote:
I tracked the problem down to the line in the slave ISR "incoming = i2c_read();". It was getting stuck in there. Checking the assembly listing revealed just three instructions; it was checking the SSPSTAT "buffer full" flag and waiting until it got set before processing the data in the buffer.
You could use the i2c_poll() function which returns TRUE is there's a received byte waiting in the buffer.
e.g.
Code:
// if we've received some data ...
if (i2c_poll()) {
// read rxed byte
rx_char = i2c_read();
}
andrewg
Joined: 17 Aug 2005 Posts: 316 Location: Perth, Western Australia
Posted: Fri Mar 10, 2006 10:47 am
You're right! Thanks, that looks much better.
I think ex_slave.c could do with an overhaul... _________________ Andrew
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum