 |
 |
| View previous topic :: View next topic |
| Author |
Message |
MikeValencia
Joined: 04 Aug 2004
Posts: 238
Location: Chicago
|
| I2C, Master Reception, not making sense for pic18Fxx20 |
 Posted: Sun Dec 04, 2005 10:02 am |
 |
|
In the 18F45X -> 18F45X0 "migration" document, it states one of the programming differences to pay attention to:
| Quote: | | The MSSP module must be in an idle state before the RCEN bit is set, or the RCEN bit will be disregarded. |
I don't understand how I would know that I am in the so-called "idle" state that the datasheet is referring to before I set RCEN. In fact, it seems contradictory because you have to SET the RCEN bit in order to receive.
The following function works just fine in the PIC18F458, but in the PIC18F4580, it gets stuck in the while-loop forever. I have a feeling I have encountered an issue in the migration document, but I still don't understand what's going on:
What do I have to do differently in the following i2c_read() function (besides implementing an i2c timeout watchdog):
| Code: |
unsigned int i2c_read(void)
{
unsigned int return_value;
>>> You have to set RCEN to enable receive mode, right?? What do they mean that you have to be 'idle' before the RCEN bit is set??
PIC_SSPCON2 |= PIC_SSPCON2_RCEN; // Enable receive mode.
// Wait for the RCEN bit to clear
while (PIC_SSPCON2 & PIC_SSPCON2_RCEN)
{
>>> PIC18F4580 i2c master gets stuck here, but PIC18F458 master works flawlessly.
}
// Send NACK bit for ACKnowledge sequence.
PIC_SSPCON2 |= PIC_SSPCON2_ACKDT;
PIC_SSPCON2 &= ~PIC_SSPCON2_ACKEN; // Send ACK data now
return_value = PIC_SSPBUF;
return return_value;
} |
|
|
 |
Ttelmah
Guest
|
|
| Posted: Sun Dec 04, 2005 11:25 am |
|
|
The sequence I have used is:
start
send byte with the read flag set
_wait for the /ack to rise from slave_
Only once this is received, set the RCEN bit
Now clock your byte in, and /ACK this
stop.
Basically it seems to be critical that the slave has signalled it has acceptd the first byte, before RCEN is set.
Best Wishes |
|
|
valemike
Guest
|
|
| Posted: Sun Dec 04, 2005 12:52 pm |
|
|
Thanks Ttelmah. I just realized that CCS's i2c_write() function checks to make sure that PIR1.SSPIF flag gets set before it continues on.
It makes sense now. I have always been loading SSPBUF and not waiting for the write to complete. And as you said, i can either wait for the ACK to rise from the slave, or i can wait for the SSPIF interrupt flag to get set.
This migration from '458 to '4580 isn't so trivial after all. |
|
|
Ttelmah
Guest
|
|
| Posted: Sun Dec 04, 2005 3:10 pm |
|
|
It is this sort of little difference, that is often the worst....
Best Wishes |
|
|
|
|
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
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
