Dummy Needs help with 12f675

Hi,

I do some very simple stuff with the 8 pin pics - the 508a, specificaly. I got tired of having to UV erase chips and picked up some 675's.

After trying to program one, it performed erractically and I realized there were some things I missed. I've looked at back messages on the PicList and have managed to get myself hopelessly confused regarding osscal values, how to use the internal clock, etc.

So....

Could someone do a quick handholding walkthrough with me?

I've got a brand new, virgin 675 on my desk. I want to use the internal clock. All I want to do is blink LEDs on GPIO.0 and GPIO.1

I do not want to use the AC/DC comparators.

What Defines do I need at the beginning?

Do I need to read a value for OSSCAL, write it down, and re-enter that each time for each individual chip like I had to do on the UV eraseable ones? Or is there an easier way?

I know this is pretty basic, but I have managed to get myself throughly confused.

Thanks,

Mike Tennent


PS - I'm using PicBasic Pro

Good page about configuring the Pic12f675;
http://members.shaw.ca/picgroup/Reso...5%20Notes2.htm

Go to the 'General' Section of this forum, check the thread "Sound Command with 12-bit MCU's", and download YankeeDoodle.txt for a working 12F675 example. Believe it or not, that example has now been incorporated into a commercial product... Let nobody say that you don't get useful freebies from Melanie...

Hi Melanie,

Thanks for the quick response (and to Original, too.)


I had looked at yankeedoodle and thought it was answering my questions, but then I found another snippet from the PicList archives that had this:

@ DEVICE INTRC_OSC_NOCLKOUT
@ DEVICE MCLR_OFF ' - as per Melanie
OSCCAL=$A4 ' from chip read


(The chip read is what threw me.)


And the file Original pointed me includes this in its "typical front end statement" -

DEFINE OSCCAL_1K 1

(but it doesn't include @ DEVICE INTRC_OSC_NOCLKOUT)


Those variations seem to overlap or even contradict each other, hence my confusion.


Your example seems to indicate that if I include:

@ DEVICE INTRC_OSC_NOCLKOUT
@ DEVICE MCLR_OFF

then neither the chip read nor DEFINE OSCCAL_1K 1 is needed, correct?

Regards,

Mike T.

With 8-bit PIC's like the 12C509, there are no Flash equivallents. You are either good at programming and get it right first time, or you fill up a garbo skip parked outside your office/house/garden shed with dead parts that didn't work because you made a boo-boo programming these one-time parts. To help the terminally dsylexic, Microchip came out with the J-series UV eraseable parts. Cooking them under a UV lamp for quarter of an hour, or out in the sunlight in the Arizona desert for two years (the non-urgent projects) would neatly erase the chip. Unfortunately, it also erased the OSCCAL value (see further down). So you had to read the chip FIRST, and then replace the OSCCAL value by writing that value back into your program or presetting it manually into your programmer.

The 12F675 and it's dinky brothers has TWO sets of configuration bits which should be preserved at program time. These are the OSCCAL and BANDGAP bits. Most sensible programmers (the machines not the people) can be set to avoid overwriting these bits when programming or erasing the chip which means you can dispense with reinserting them back into your program. Hell... you got 1,000 12F675's to program it'll be a bit of a chore to read the value from each of them first and to embed it manually thereafter. So basically, you can dispense with PBP's OSCCAL defines and setting for the 12F675... it's really intended for UV parts.

You're just about to ask "Why are these bits important?", so I'll tell you...

The OSCCAL value trims the internal 4MHz oscillator to as close to 4Mhz as they can be bothered to get it in the factory. Still no replacement for using an Xtal or Resonator when doing high-speed comms, but the internal oscillaor is however reliable enough for 2400 baud providing you don't screw-up OSCCAL too much. If you do lose OSCCAL by inadvertantly erasing it, the chip is still fully useable, but the timing won't be 4.000MHz... (it never is anyway) but could vary by a percentage point or so. Let's face it, if you're blinking an LED at one Hz, you don't really care if it's 1.0000Hz, or 0.98Hz or 1.02Hz.

The BANDGAP bits are used to trim the on chip voltage reference. This voltage reference is NOT the VRef for the Comparators set by VRCON, but just a variable voltage divider used to trim the reference for POR/BOR. If they are changed the reference will probably not meet the accuracy specifications in the Data Sheet. No big deal for Hobbyists or non-critical applications either.

@ DEVICE INTRC_OSC_NOCLKOUT

The above line tells the PIC to use the internal oscillator (INTRC_OSC) no xtals, resonators or other external circuitry required, and we don't want the clock appearing on any pin (NOCLKOUT) leaving BOTH those pins available for I/O.

@ DEVICE MCLR_OFF

That line tells the PIC to use it's internal MCLR circuitry, and leaves that pin free for Input. Note that the MCLR pin (GP3) is INPUT ONLY.

Melanie

Melanie,

You're an angel, as always.

I had to do a bike workout and go to a meeting before I could finally get home to try your solution.

Everything seems to be working like it should now.

Thanks for the very complete explanation. It helps to understand the reason for commands.

I was on the PicList for awhile, but I think my ISP barfed too many times and I got de-listed for some reason. I'll have to try and sign up again.

Thanks again for your help and patience.

Mike Tennent

Actually, I've kinda given up on the piclist. You spend time and effort composing a reply and it just gets lost. I did it earlier today answering a thread on stepper motors, twelve hours later it's still not appeared. Over the last couple of weeks a dozen posts or so from me never made it.

Hello,

PicKit2 displays the BANDGAP value.

Does anyone know if PicKit2 is able to change the BANDGAP bits? Just can't find out...

I made it with WinPic but PicKit2 surely does it too.