i2c slave operation

[ddscott]

I am attempting to use a 16f767 as an i2c slave. The address for the slave is set to 0x21. I am using an Aardvark i2c interface module to communicate with the PIC. When I send data to the PIC at address 0x21, there is no response. If I change the address that the interface module sends the data to 0x10, the PIC responds as expected. If I change the PIC's address to a different value, I don't get any response. When I check the values of the internal registers with MPLAB: register 0x14 (sspcon) = 0x36, register 0x91(sspcon2) = 0 and 0x93 (i2c addr) = 0x21. The same problem occurs when I use the ex_slave.c example or my code. When I use a scope to monitor the scl and sda lines, they seem to be correct.

Any ideas?

Main Program

#include "C:\Program Files\PICC\Projects\Bio_Briefcase\i2c_0816.h"
#int_SSP
SSP_isr()
{

int incoming;

if (i2c_poll() == TRUE) {
incoming = i2c_read();

if (incoming == 0x21) {

output_low(pin_a0);
delay_us(200);
output_high(pin_a0);
delay_us(200);
output_low(pin_a0);
delay_us(200);


}

}
}



void main()
{

setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF|ADC_TAD_MUL_0);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(VREF_LOW|-2);
enable_interrupts(INT_SSP);
enable_interrupts(GLOBAL);
setup_oscillator(False);

while (true){

output_high(pin_a0);

}

}


.h file

#include <16F767.h>
#device adc=8

#FUSES NOWDT //No Watch Dog Timer
#FUSES EC_IO //External clock
#FUSES NOPUT //No Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES MCLR //Master Clear pin enabled
#FUSES DEBUG //Debug mode for ICD
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES BORSEN //See Datasheet

#use delay(clock=20000000)
#use i2c(Slave,Slow,sda=PIN_C4,scl=PIN_C3,address=0x21)

[Ttelmah]

Remember an I2C address can only occupy the upper 7bits. The low bit of the address byte is reserved for the direction control, and will be changed by the code.
0x20 is a legitimate address, but not 0x21...

Best Wishes

[ddscott]

Thanks for the help. I came to the same conclusion about the time I opened my email. What was also confusing was that to get the PIC to respond to an address call of 0x20 from the emulator, you have to give the PIC an address of 0x40.

Thanks again.