Rob Hamerling wrote:
> 
> 
> funlw65 wrote:
>> Hmm, guys you forgot about this:
>>
>> assembler
>>   -- ========================
>>   bsf _status, _rp0 -- bank 1
>>   -- ========================
>>   call  0x3ff   -- get the factory calibrated OSC value
>>   movwf osccal  -- for accurate timing
>>   -- ==================
>>   bcf _status, _rp0 -- bank 0
>>   -- ==================
>> end assembler
> 
> You are right that OSCCAL should be loaded with the calibrated value in 
> that high-memory location. And not only for the 2 PICs you mention, but 
> also for a number of others. I have a note in my todo list: 10Fs, 
> 12F508,509,510,519,629,675 and 16F505,506,630,676, maybe more.
> 
> I think a simple 'asm movwf OSCCAL' as very first instruction will be 
> enough, because with a reset the program counter is set to the last 
> memory location (e.g. DS41239D 4.7.1 and 9.2.2).
> 
> Changing OSCCAL is fine tuning, omitting OSC calibration will not be the 
> cause that a led doesn't blink at all, only the blink frequency may be a 
> bit different.
> 
> When an accurate frequency is a required an external oscillator is the 
> way to go.
> 
> We have discussed the OSCCAL issue in the begin-period of the Jallib 
> group and decided then to spend out time on more urgent things.
> 

Rob

I have been having a problem with, what I thought was with baud rate, in
a test file using the internal clock of the 16f628a.  I noticed that 
there was no OSCCAL in the device file.  Not knowing for sure if that 
(or me) was a problem, I grep'ed the svn device files for OCSCAL.  I 
come up with 289 devices with no OSCCAL in the files and 306 that have 
OSCCAL in them.

Thought I must be mistaken as I did not realize you had done 'that' many
(595) devices, I just put it into my notes and continued to see if I 
could get this k107 working.

Up till then I had been using 2 & 3 Terminal resonators but order some 
20Mhz xtals Monday to see if maybe that is my problem.  Live & learn.

Regards

Wayne

>> Should be included in device file for 12F629 and 12F675. 
> 
> And in some others, if in the device files at all. It requires 
> co-operation with the compiler, because the compiler decides where code 
> is store in memory. Maybe it should be a pragma.
> 
>> Also, you
>> must pay attention at burning time, to not override that location of
>> flash memory....
> 
> True, use a proper programmer!
> 
> Regards, Rob.
> 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to