configuring the internal oscillator

I've been doing more study on the 12F629 PIC. Do I have to have some code in my program that will configure the oscillator so it is as accurate as possible?

I'm still trying to understand how the programmer even deals with the calibration values as I'm told the value is at h3FF, but I do not see anything at this address when I read the chip. The data sheet talks about saving the value and what not. How, where? It confuses me.

How do I ensure it is calibrated properly using picBASIC <em>not</em> PRO.

Ideally, if anyone is using IC-Prog that would be helpful so I can see the actual example as I look at the programmer.

Thanks.

Bart

hi bartman,

maybe you don't see anything because your programmer already erease it...

see this post
http://www.picbasic.co.uk/forum/show...ghlight=OSCCAL
or do a search with OSCCAL. everything is suppose to clear up your question.. If not let us know

regards

Well it looks like this is important:

<b>DEFINE OSCCAL_1K 1</b> and only good if I am using pbp which I am not so there is probably some equivilant for pbc, but that aside...

Before I did anything with the chip I read it and saw no values yet when I write to it it always says it will use the value in h3FF which, as far as I can tell, is nothing.

I still gather that I have to use some snippet of code to properly set up the clock (the code above for a 4mhz chip I assume). I'd just like to really figure out if things are erased or not erased or hidden away or what the heck.

Bandgap is another one that I can't see any value for although I do get a checkbox to change it or use the default (which I currently am doing).

Everything works for what I need to work, but I'd really want to get my head around it for the future. The chip is the 12F629 and it seems like it is just this 12F series that has these issues.

Bart

Hi Bart,

I tried to erase a 12F629 with IC-Prog and i couldn't, it seems to be smart enough to preserve it. You should be able to read something like 3474 on adress 3FF. If you dont have something that starts with 34 you have managed to erase it. That could have happened if you selected another device like 16F84 and pressed erase. To recover it you need to write a program and measure a frequency very accuratley. Not sure it's worth the trouble for a 2$ chip.

If you want to calibrate your pic, you should add the following code at the beginning of your program. It does the same as "DEFINE OSCCAL_1K 1" would in a PBP program.

/Ingvar

Code:

---

asm
    call 03ffh
    bsf STATUS, RP0
    movwf OSCCAL
    bcf STATUS, RP0
endasm

---

Thanks. I will look again for the value.

Because it kept asking me if I wanted to use the value at that address I figured there has to be something there even if I couldn't see it. I assume when using IC-Prog that you can see it? Perhaps I'm not looking in the correct spot.

If I did manage to erase it it is no big deal as this chip has just been my "test" chip. When I start building my project I'll program a fresh chip and won't be erasing and re-programming it over and over.

Thanks for the assembler code. I'll include it in the program.

Bart

Okay, I tried this bit of code and it didn't work. so I went through the data sheet again and found what I should look for and it said:

<b>
bsf STATUS, RP0
call 3FFh
movwf OSCCAL
bcf STATUS, RP0
</b>

Which is the same thing, but in a different order so I changed it and tried to compile again and still got the same error.

The compiler tells me "illegal bit number". If I do not include this code it compiles fine.

What what is wrong with this bit of code to cause those errors? Am I including it in the wrong place? I have it at the beginning right now.

Bart

Maybe the bitname RP0 isn't predefined for some reason. Try this instead.

Code:

---

asm
    bsf STATUS, 5
    call 03ffh
    movwf OSCCAL
    bcf STATUS, 5
endasm

---

Scroll down to the last line in the window "Address - Program Code". The Line should look similar to this .....

03F8: 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3474 ÿÿÿÿÿÿÿt

As you can see the last memorylocation contains 3474 instead of 3FFF. That's your calibrationvalue, if its 3FF you've managed to erase it. You can recover it if you have a frequencymeter and are prepared to do the work involved. Not difficult but timeconsuming.

/Ingvar

Hmmm,

One would think that a snipet of code direct from their datasheet would compile just fine. Also, I thought that when ASM and ENDASM were used the compiler is just to insert the code without looking at it?

Regardless, I will try it tonight when I get home and see what happens. Where would RP0 be pre-defined and how would the compiler know either way?

The location of the oscillator value is where I had been looking for it so I must of erased it if it was there to begiin with. I still think it wasn't since I didn't see anything on the initial read of the chip. I'll be double checking with the next chip to be certain.

Thanks.

Bart

Ahhh, just realized that PBC define things a little different. This will probably work. I don't know what the file would be called but it should be one of the files in your \PBC\INC directory.

Code:

---

asm
    bsf RP0
    call 03ffh
    movwf OSCCAL
    bcf RP0
endasm

---

/Ingvar

Odd that it would care if it just inserts the code in the .ASM file. What I posted is right out of the datasheet. If something is "different" then the datasheet loses a lot of value doesn't it? How would I know to make this change (assuming it works)?

Bart

Well, that did it. The last code example compiled fine.

Now, back to my question regarding how I would know about this change based on the info in the datasheet? It showed the original code as I posted it.

Bart

Hi Bart,

The code you're talking about came from Microchips datasheet, it would most likley compile if you used MPASM. MPASM is Microchips assembler compiler. However, you use the PBC and PM compilers from Melabs. Melabs prefer to define things slightly different from Microchip. No big deal, you only need to get used to using the bitname without the register. In the end it all compiles to the same thing.

If you don't like the way it's done now you could always define them yourself. I will be of no use for that since i haven't used this compiler in the last seven years.

How would you know ........ well, i guess it's all about getting familiar with your programming enviroment and REALLY understand it. Read the manuals(PBC and PM) over and over again, then finish off by learning your pic of choise by reading the datasheet over and over .......... you get the picture. No shortcuts, just hard work.

Cheers
/Ingvar

Great. A programming language where everyone wants to talk differently to say the same thing.

That will be tough considering I'm starting with, basically, zero knowledge.

Thanks for the explaination.

Bart