Hi guys,

I'm very new to programming PICs. I'm trying to do an A/D conversion of a voltage given obtained from a sensor. I'm using the PIC12CE674 for now and programming in C.

Here is my code:

#pragma chip PIC12CE674
#include "delay.h"

void main(void){

int adval;		 // adval is the ADC value
TRIS.0 = 1; 		 // Set GP0/AN0 as input
TRIS.4 = 0;		 // Set GP4/AN3 as output
ADCON1 = 0b.0000.0010;   // Set GP4 as Digital and GP0 as Analog, Vref = Vdd

while(1){
//Do the sensor conversion
delay_us(50);			// Set delay of 50 us for sampling (TAD)
ADCON0 = 0b.1100.0101;		// Set oscillator to FRC, Analog Channel 0 (GP0/AN0) selected, Go/Done=1, ADON=1
while(ADCON0.2 == 1){}		// A/D conversion started, continue to check Go/Done, when 0 it is completed
				// Bit 1 of ADCON0 is cleared when finished
adval = ADRES;			// Read ADRES into adval

if(adval >100){			// LED on at  GP4/AN3 (pin 3) when AN0 > 1.8V, off < 1.8V
	GPIO = 0b.0001.0000;
}
else {
GPIO = 0b.0000.0000;
}
}
}

Here's a link to the datasheet: http://pdfdata.datasheetsite.com/pdf1/Microchip/PIC12LCE674-04-P.pdf

It compiles fine in MPLAB but when I go to program it into the PIC with PICSTART PLUS, it gives an error of "device NOT blank: Program Memory". What does this mean? Why would the program memory not be blank considering the PIC is brand new?

I was reading on some things and I came across MCLR. What exactly does this do and do I need to use this somehow? I would appreciate the help.Thanks a lot.

 

It might be something to do with the OSCAL value which is preprogrammed. See page 56. Maybe you are supposed to read the value, UV erase the part, and then reprogram.
I'd strongly recommend getting a 12F675 instead which doesen't require the UV erase. The 674 seems to be a bit of a dinosaur.

 

Microchip recommend the 12F683 as a replacement. Its a better chip than the 12F675 or 12CE674 but a few pence more expensive.
http://www.microchip.com/wwwproducts/ProductCompare.aspx?product1=PIC12CE674&product2=PIC12F683

 

Thanks a lot. I didn't know the PIC was one-time programmable. I'm just using it now until I get my 16F684.

For the code I have, do I require that delay command if the oscillator was set to internal RC? I'm really confused about that part.

On another note, here's my code for the PIC16F684. I have the delay here as well and I'm not sure if its needed. If anyone can look at it and let me know if it's fine. Thanks!

#pragma chip PIC16F684
#include "delay.h"

void main(void){

int adval, a, b;	// adval is the ADC value
TRISA.0 = 1; 		// Set RA0/AN0 (pin 13) as I/P
TRISC.2 = 0; 		// Set RC2/AN6 (pin 8) as a dig O/P
ANSEL.0 = 1; 		// Set RA0/AN0 (pin 13) as analog I/P
ADCON1 = 0b.0011.0000;  // Clock set to internal Frc

while(1){
//Do the sensor conversion
delay_us(50);			// Set delay of 50 us for sampling (TAD)
ADCON0 = 0b.1000.0011;		// Right justified, Vref = Vdd, 
				// Read from AN0 (pin 13), Go/Done = 1, ADC Enabled
while(ADCON0.1 == 1){}		// A/D conversion started, continue to check Go/Done, when 0 it is completed
				// Bit 1 of ADCON0 is cleared when finished
a = ADRESH.1;			// Read bit 1 of ADRESH into variable a
a = a * 512;			// Multiply "a" by the position of that bit (2^9)
b = ADRESH.0;			// Read bit 0 of ADRESH into variable b
b = b * 256;			// Multiply "b" by the position of that bit (2^8)
adval = ADRESL + a + b;		// ADC value is the sum of ADRESL, a, and b

if(adval <369){			// LED on at  RC2 (pin 8) when AN0 < 1.8V, off > 1.8V
	PORTC = 0b.0000.0100;
}
else {
PORTC = 0b.0000.0000;
}
}
}

 

You don't need a delay before setting the go/done bit. TAD is the clock that the A/D converter runs from. You need to set bits 2:0 of ADCON1 depending on table 9.1.

When the device frequency is greater than 1 MHz, the FRC clock source is only recommended if the
conversion will be performed during Sleep.

The FRC clock is separate from the main system clock.
The while loop checking the go/done bit is correct.

 

Don’t forget this peace of code for the PIC 12F675if you do forget this and erase the device during a reprogram of code you will land up with an un calibrated oscall value and this will cause you no end of problems as i found out not so long ago when designing something else for someone !! You must include this in your main method

Here is the snippet of code

asm{
bsf _status,RP0
call 0x3FF
movwf _osccal
bcf _status,RP0
} // end asm

Check the datasheets for this before starting with that device they can be recalibrated but
I’ve not had much success with this as yet perhaps someone else can throw some light on this subject