 |
 |
| View previous topic :: View next topic |
| Author |
Message |
valery_che
Joined: 04 Jan 2016
Posts: 5
|
| PIC18F4431 I2C issue |
 Posted: Tue Jan 05, 2016 12:12 pm |
 |
|
Hello!
I need to make a communication between PIC18F4550 (Master) and PIC18F4431 (Slave) via I2C. 18F4550 working good with another slaves (another PIC18F4550 for tests). I2C bus scanner don`t see 18F4431. Also, 18F4550 with the same code as slave working okey. It seems like I2C module fully doesn`t work in my 18F4431. What`s wrong?
Here is code for 18f4431:
| Code: |
#include <c:\Program files (x86)\PICC\Devices\18F4431.h>
#DEVICE HIGH_INTS=TRUE
#fuses HS, NOWDT, NOPROTECT, NOLVP
#use delay(clock=16 000 000)
#use i2c(Slave, sda=PIN_D2, scl=PIN_D3, address=0xA0, FORCE_HW)
int data = 0, state = 0;
#INT_SSP
void ssp_interrupt()
{
state = i2c_isr_state();
if(state < 0x80) // Master is sending data
{
data = i2c_read();
}
if(state >= 0x80) // Master is requesting data from slave
{
i2c_write(0);
}
output_bit(PIN_B4, TRUE); // Never turns on LED
}
void main()
{
enable_interrupts(INT_SSP);
enable_interrupts(GLOBAL);
output_bit(PIN_B4, FALSE); //Led
delay_ms(100);
output_bit(PIN_B4, TRUE);
delay_ms(50);
output_bit(PIN_B4, FALSE);
while (TRUE) { /*
output_bit(PIN_B4, TRUE);
delay_ms(100);
output_bit(PIN_B4, FALSE);
delay_ms(100); */
}
} |
|
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9271
Location: Greensville,Ontario
|
|
| Posted: Tue Jan 05, 2016 1:42 pm |
|
|
hmmm go back to step one...
create a 1Hz LED program for the 4431. Does it function properly,ie: flash LED at 1 Hz rate ?
step two...
confirm your 4431 is correctly wired for I2C and has appropriate pullups on the I2C busses.
step 3...
report back your observations.
my guess is the 4431 isn't running....
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jan 05, 2016 3:40 pm |
|
|
I got bad generated code (00 for register addresses), until I used i2c1
in the library declaration. Also you do need to tell the PIC to use
the PortD pins for i2c. That is done with a fuse setting. Try it with
the changes shown in bold below.
| Quote: | #include <18F4431.h>
#fuses HS, NOWDT, NOPROTECT, NOLVP, SSP_RD
#use delay(clock=16M)
#use i2c(Slave, i2c1, address=0xA0) |
|
|
|
valery_che
Joined: 04 Jan 2016
Posts: 5
|
|
| Posted: Tue Jan 05, 2016 4:50 pm |
|
|
| temtronic wrote: | hmmm go back to step one...
create a 1Hz LED program for the 4431. Does it function properly,ie: flash LED at 1 Hz rate ?
step two...
confirm your 4431 is correctly wired for I2C and has appropriate pullups on the I2C busses.
step 3...
report back your observations.
my guess is the 4431 isn't running....
Jay |
Yes, LED blinking directly 1 time per second. So, 18F4431 is on. And wireds for I2C connected right. |
|
|
valery_che
Joined: 04 Jan 2016
Posts: 5
|
|
| Posted: Tue Jan 05, 2016 4:57 pm |
|
|
| PCM programmer wrote: | I got bad generated code (00 for register addresses), until I used i2c1
in the library declaration. Also you do need to tell the PIC to use
the PortD pins for i2c. That is done with a fuse setting. Try it with
the changes shown in bold below.
| Quote: | #include <18F4431.h>
#fuses HS, NOWDT, NOPROTECT, NOLVP, SSP_RD
#use delay(clock=16M)
#use i2c(Slave, i2c1, address=0xA0) |
|
After enabled fuse SSP_RD all I2C functions on 18F4431 working! Thanks a lot! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19590
|
|
| Posted: Wed Jan 06, 2016 2:14 am |
|
|
Hurrah!... 
As a separate 'long term warning', I had problems with the I2C slave on the 4431. This is (partially) related to the errata sheet DS80132F.
I had to implement the timeout mentioned here, or just occasionally found that the normal repeated start was incorrectly handled, and the unit would not recover. Now it should not happen (the conditions they say trigger it, are both ones that my master was not generating - never sent two 'read starts' back to back, or a second start during a transaction). My code was using normal I2C protocols with the only repeated start being when I reversed bus direction for a read. However just once in perhaps 100000 transactions, the I2C would then get hung (intermittent after several days...). I ended up just starting a timer, when the address match occurred, disabled this when the transaction completed, and if this reached it's end count, reset the I2C (SSPEN off, then on). I set the timer to give me about 0.1 seconds, and had the master setup to retry after just a little longer, if it didn't get the get the correct ACK/NACK on the data bytes from the read. This has been 100% since. The 4431, is the only chip that has ever shown this for me.
So 'beware'. I had to use the 4431, since I wanted it's PWM functionality, and at the time it was the only chip with this, but I have a 'red flag' now in my design notes, to 'beware' when using the I2C on this.... |
|
|
valery_che
Joined: 04 Jan 2016
Posts: 5
|
|
| Posted: Wed Jan 06, 2016 8:57 am |
|
|
| Ttelmah wrote: | Hurrah!...
As a separate 'long term warning', I had problems with the I2C slave on the 4431. This is (partially) related to the errata sheet DS80132F.
I had to implement the timeout mentioned here, or just occasionally found that the normal repeated start was incorrectly handled, and the unit would not recover. Now it should not happen (the conditions they say trigger it, are both ones that my master was not generating - never sent two 'read starts' back to back, or a second start during a transaction). My code was using normal I2C protocols with the only repeated start being when I reversed bus direction for a read. However just once in perhaps 100000 transactions, the I2C would then get hung (intermittent after several days...). I ended up just starting a timer, when the address match occurred, disabled this when the transaction completed, and if this reached it's end count, reset the I2C (SSPEN off, then on). I set the timer to give me about 0.1 seconds, and had the master setup to retry after just a little longer, if it didn't get the get the correct ACK/NACK on the data bytes from the read. This has been 100% since. The 4431, is the only chip that has ever shown this for me.
So 'beware'. I had to use the 4431, since I wanted it's PWM functionality, and at the time it was the only chip with this, but I have a 'red flag' now in my design notes, to 'beware' when using the I2C on this.... |
Thank you for a great comment! I chose 18F4431 exactly for advanced PWM module. But after your story it seems like that isn't "friendly" chip for I2C communication. I need to control up to 6 servos and have enable to exchange data via I2C. Can you give me advice about 18F chip for that task? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19590
|
|
| Posted: Wed Jan 06, 2016 12:13 pm |
|
|
Unfortunately, the 2431/4431, is the only PIC18 with the power control PWM module that I know of. It's annoying, also, that the Microchip search doesn't allow this to be searched for (no column for this in their search). It's the slave I2C, that has problems (it also has an initialisation problem that hit me, I posted here about this at the time). If I was doing this now, I'd use a PIC33, the performance for the maths is just so much better, Something like the DSPIC33FJ16MC102 for a small chip (like the 2431). The relocatable peripherals make these so much more friendly....
Consider if you could do the communications to the slaves using something like RS485, instead of I2C?. Avoids the problems. |
|
|
valery_che
Joined: 04 Jan 2016
Posts: 5
|
|
| Posted: Wed Jan 06, 2016 12:44 pm |
|
|
| Ttelmah wrote: | Unfortunately, the 2431/4431, is the only PIC18 with the power control PWM module that I know of. It's annoying, also, that the Microchip search doesn't allow this to be searched for (no column for this in their search). It's the slave I2C, that has problems (it also has an initialisation problem that hit me, I posted here about this at the time). If I was doing this now, I'd use a PIC33, the performance for the maths is just so much better, Something like the DSPIC33FJ16MC102 for a small chip (like the 2431). The relocatable peripherals make these so much more friendly....
Consider if you could do the communications to the slaves using something like RS485, instead of I2C?. Avoids the problems. |
Hm. dsPIC really good option. But now I may be start using RS232 or RS485. Thank you so much! |
|
|
|
|
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
