-
12F629 I2C problems
Hi everyone. I am trying to simply interface a 12F629 with an external eeprom (24AA00) using PicBasic Pro's I2CWrite and I2CRead commands. However, it never seems to interface correctly. My circuit looks like this:
.................................................. ................
.................+5V.....1...8.....GND............ ....... 12F629
..................LED.....2...7.....--------------|......
..................LED.....3...6.....----------|....|......
.....+5V-->1k-->.....4...5...................|....|......
.................................................. ...|....|.....
.................GND.....1...8.....+5V.........|.. ..|..... 24AA00
.................GND.....2...7.....GND.........|.. ..|......
.................GND.....3...6.....----------|....|......
.................GND.....4...5.....--------------|......
.................................................. ................
Where SDA Pin7-->Pin5 and SCL Pin6-->Pin6
Also, I have a 4.7k resistor connected from +5V-->Pin6 on the 24AA00 to act as a pullup. Same thing for Pin5 on the 24AA00.
My code is very simple too. It is below:
value var byte
I2CWrite GPIO.0,GPIO.1,$A0,1,[3]
pause 20
I2CRead GPIO.0,GPIO.1,$A1,1,[value]
pause 20
if value=3 then
high 5
else
high 4
endif
End
This will simply write to the eeprom and read back from it. If it reads back the value it wrote, then the LED5 should turn on, if not, the LED4 should turn on. It only ever turns on LED4. I am not sure what the problem is. I have tried many many things, but nothing has worked. Please let me know what your thoughts are. Thankyou very much.
Chris
P.S. - Miscellaneous Information:
Programmer: IC-Prog 1.05C
Fuses: WDT, PWRT, MCLR, BODEN
Bandgap: Default
Oscillator: IntOSC GP4
Adding CMCON=7 doesn't seem to matter
Sending a word instead of a byte doesn't seem to matter
-
Try this one and post result
Code:
CMCON=7 ;disable internal comparator
TRISIO=0 ;set pins to outputs
LED1 VAR GPIO.5 ;define GP5 as LED1
LED2 VAR GPIO.4 ;define GP4 as LED2
cont var byte ;variable for control word of eeprom
value var byte
cont=$A0 ;control word of eeprom
value=3
I2CWrite GPIO.0,GPIO.1,cont,1,[value]
pause 20
I2CRead GPIO.0,GPIO.1,cont,1,[value]
pause 20
if value=3 then
LED1=1
LED2=0
else
LED2=1
LED1=0
endif
End
regards
-
Hi Steve, Good news. I tried your program and it works! I guess it just wanted me to use variables instead of hard coding the I2C statements. Or, maybe I just needed to add the TRISIO to set the pins as outputs. There is a weird anomaly going on though. Most of the time when I power it on, other leds flash on for a second then are off. To debug this, I put a pause right under the TRISIO statement. The leds stayed on much longer, then started dropping out one by one. Also, if I have GPIO.0 and GPIO.1 connected to a led, as well as the SDA and SCL lines, the program doesn't work. Any ideas on this? Other than that, the program works great!
Thanks for your help.
Chris
-
> I tried your program and it works! I guess it just wanted me to use variables instead of hard coding the I2C statements. Or, maybe I just needed to add the TRISIO to set the pins as outputs. There is a weird anomaly going on though. Most of the time when I power it on, other leds flash on for a second then are off.
For sure you must use variable in I2Cread/I2Cwrite statement. It's always safe to assign pin to TRIS statement. Looks in some case on 12Fxxx, if you don't set TRISIO, the output don't work properly .
> There is a weird anomaly going on though. Most of the time when I power it on, other leds flash on for a second then are off.
it can be safe to set LED output on a specific state at the begining.
GPIO.0=0
GPIO.1=0
GPIO......
Be sure to pull down/up unsused pin with resistor <10K. Also i see often an noisy PSU who screw the PIC when starting. Safe if you add 0.1uF + 10uF (tantal or 47uF electrolytic)
>Also, if I have GPIO.0 and GPIO.1 connected to a led, as well as the SDA and SCL lines, the program doesn't work. Any ideas on this? Other than that,
Do you place led to monitor pins of EEPROM? in this case it's absolutely normal, EEPROM may not provide enough current to drive/sink LED.
regards
