OSCCAL Register i PIC, en eller två byte?

[manw]

På en PIC12F675 saknades värdet OSCCAL, dvs kalibreringsordet för den interna RC-oscillatron. Värdet ligger lagrat i de två sista bytearna i programminnet exvis 3444h (ger ju 16 bitar)

På en av kretsarna fick jag meddelandet att värdet saknades, och så verkade fallet vara (ser värdet på ett annat ex)

Letade rätt på info om registret OSCCAL i PIC Midrange manualen, där ser det ut som registret bara är en (stympad) byte.

Står till och med hur man skall bära sig åt för att ändra, men när kartan inte stämmer överens med verkligheten så vet jag inte riktigt hur jag skall bära mig åt.

Någon med erfarenhet av detta som kan svara på varför det ser ut på detta sätt

[Chribbe76]

3444H är 14bitar och är instruktionen RETLW b'01000100'
Man gör en Call till sista adressen av minnet och får svaret i WREG.

Sen får man själv lagra värdet i register OSCCAL.

Om du inte vill använda sista adressen av minnet till kallibrering av oscillatorn så kan du använda MOVLW och lagra i OSCCAL.

Så här har jag gjort en gång när jag ville använda fabriks-värdet men kallibrera lite själv oxå.

call 0x3FF ; retrieve factory calibration value
addlw -.12 ;Förändra värdet (xxxxxx00)
bsf STATUS,RP0
movwf OSCCAL
bcf STATUS,RP0

[sodjan]

Chribbe76 har naturligtsvis rätt, men det är snabbare och
enklare att kolla kap 9.2.5.1 i databladet...

Om man vill slippa hantera OSCCAL så kan man köra
12F638 istället, vilken har kallibreringen "hårdkodad"
från fabrik...

Sen är det en annan fråga hur man gör när man saknar
värdet. Man får testa sig fram. T.ex genm att skriva ett
program som "mäter" en känd frrekvens eller tid och
justerar OSCCAL för minsta fel.

[manw]

Aha, tack för svar, nu är jag förvirrad på en högre nivå. Trodde att det var 3444H som var kalibreringsvärdet. Hittade värdet på/i ett annat exemplar på adressen 3FFF som är sista adressen i PIC12F675.

När jag kör IC-Prog och skall tanka ner koden så kommer just detta 3444H upp som ett kalibrerinsvärde på ett fungerande exemplar, men på den jag har hållit på att rodda med saknades värdet. Men då är det alltså 44h som är kalibreringsvärdet.

Men jag hade dessutom missat att flytta värdet som du säger, nu måste jag ta reda på hur man läser absoluta adresser med C. (Kompliatorn Cc5x) Lättast vore om man kunde skriva Assembler i C-koden, men skall ta reda på hur.

Då stämmer i alla fall kartan med verkligheten hur jag skall hantera OSCCAL och kaliberera den, sedan är det till att lagra 34xxH på minnesposition 3FFF om man vill "reparera" kretsen.

Förvirrad på en högre nivå som sagt, men nu är jag på spåret igen Tackar!

P.S. Egentligen om man ville göra en manuell kalibrering av varje exemplar skulle man ju istället kunna lagra värdet i EEPROM. Varför jag håller på att rodda med detta är att jag vill få seriell datakomunikation att fungera, trots att Microchip avråder från det tillsammans med den interna RC oscillatorn.

[manw]

Sen är det en annan fråga hur man gör när man saknar
värdet. Man får testa sig fram. T.ex genm att skriva ett
program som "mäter" en känd frekvens eller tid och
justerar OSCCAL för minsta fel.

Jo, nu kom jag på hur man kan skriva ett program som hittar ett lämpligt värde för OSCCAL. Man räknar upp ett antal värden det är ju 16 st & +/- bitarna vad jag kan se av manualen, och när man fått ett OK värde så skrivs det ut som seriedata läsligt i terminalprogrammet, och inte en massa junk som nu.

Det var naturligtvis inte detta jag skulle göra, men det var seriekomunikationen som strulade.

[Chribbe76]

"Man räknar upp ett antal värden det är ju 16 st & +/- bitarna"

Jag förstår inte hur du menar.
Som du skrev, det är en stympad byte, dom högsta 6 bitarna används, det blir då 64 olika värden att välja på.

[sodjan]

Slå upp RETLW och läs på lite, så kanske det klarnar.
Eller det kanske redan har gjort det, det var inte helt tydligt...

Det är lite konstigt att du har detta problem, vad har hänt ?
Detta ska hanteras automatiskt av varje programmerare värd namnet...

> Man räknar upp ett antal värden det är ju 16 st & +/- bitarna vad jag kan se av manualen,

Osäker på vad du syftar på här, men OSCCAL är *6* bitar.

> men det var seriekomunikationen som strulade.

Även med ett korrekt OSCCAL värde så är seriekommunikation med
denna äldre INTOSC lite "on the edge". INTOSC i den nyare 12F638 är mer
exakt (och det finns inget lagrat värde som behöver kopieras).

[manw]

Jo, jag uttryckte mig kanske ofullständigt. Tänkte att om man, med ett program, ändrar i OSCCAL registret, försöker skriva ut ordet på ett terminalprogram (ex Windows terminalen) via en seriekommunikationsrutin, ändrar igen, skriver ut igen, osv. En loop typ...

När man har nått rätt värde så är det läsligt, och man kan läsa sitt OSCCAL värde. Frekvensreferens i detta fall blir ju USARTENs klocka i PC'n.

Naturligtvis måste man omvandla hex-värdet till ascii, men har gjort det förut så det skall nog inte vara några problem.

Det var en metod som jag kom på att jag nog kan använda, men det rätta är nog att mäta med en riktig kalibrerad frekvensräknare, men saknar en sådan.

[sodjan]

Jo, *den* delen förstog jag, jag var osäker på om att du hade klykat
att det var en RETLW instruktion som ligger på sista adressen,
alltså inte bara ett 16-bitars kallibrerings värde...

Hur som helst...

Din metod är väll inte så tokig, speciellt om det är mot
*samma* PC som du ska köra senare, då spelar det ju
inte någon roll om baudraten i PC'n inte ligger exakt rätt...

Jag vet inte hur mycket varje "steg" i OSCCAL justerar klockan,
så det kan vara så att du får flera "läsbar" värden på PC'n, men då
får du välja det i "mitten".

Notera också att det kan ta en liten tid innan INTOSC justerar sig,
det är i alla fall så i den nyare INTOSC när man justerar OSCTUNE
registret. Men det rör sig antagligen om millisekunder i alla fall...

[manw]

Jodå, det är lungt, jag fattade det att i 3444h så är den första (stympade) byten RETLW intruktionen, och den andra (LSB) byten själva kalibreringsvärdet. Det som lurade mig först, var IC-Prog som visar en dialogruta att 3444h är kalibreringsvärdet.

Måste bara se hur jag skall läsa den i C, dvs absoluta adressen, OSCCAL har ju ett reserverat ord i Cc5x.

[manw]

Din metod är väll inte så tokig, speciellt om det är mot
*samma* PC som du ska köra senare, då spelar det ju
inte någon roll om baudraten i PC'n inte ligger exakt rätt...

Det är nästan så, mottagaren skall så småningom vara en annan PIC, där jag skall kosta på mig en kristall. Skall köra radiokommunikation så jag tror att jag är tvungen att manchesterkoda då, men måste få seriekomunikationen med PIC12F675 att fungera först över tråd. Det var just detta med oscillatorns frekvens som jag fick problem med då.

[Icecap]

Du kan ju också ta ett par easyRadio från LPRS, om du ska ha dubbelriktat är ER400TRS-02 grejen. De består i essens av en serieport (default 19K2,n,8,1) som man kommunicerar med. De saluförs av Acal, det finns sändare enbart, mottagare enbart och tranciever. Man kan lätt byta kanal, sändareffekt osv.