Sida 2 av 2

Postat: 18 november 2007, 19:16:13
av Icecap
Hoppas att du vet att 32KHz-kristallerna är ganska känsliga för rätt belastning och störningar. Vissa kristall måste man sätta ett motstånd mellan oscillatorutgången och kristallen för att det ska fungerar bra då de inte tål så mycket spänning.

Postat: 18 november 2007, 22:11:01
av sodjan
> Är väl den elegantaste lösningen.

Eller en bit-operation mot högsta biten.
Se bara till att ha T1COn.RD16 = 0 så att TMR1
kan läsas och skrivas direkt som två 8-bitars register.

Det är ju även för övrigt den metod som föreslås
i databladet, så, tja, varför inte... :-)
Varför används den inte redan nu ?
Frisk, har du kollat "Exempel 12-1" ??

Postat: 18 november 2007, 22:42:57
av xxargs
'vissa' - förmodligen alla kristaller behöver seriemotstånd, men dom flesta struntar i detta då det inte fins någon omedelbar koppling mellan fel drivning och problem i funktionen, utan möjligen som 'konstigheter' kanske först flera år senare...

Det är heller ingen liten resistans som skall kopplas i serie för att inte överlasta 32768 Hz kristallen utan kan handla om 220 kOhm till 1 MOhm om det drivs av standard TTL/CMOS/HC-utgångar

Nu tittade jag i PIC18F4550-dokumentationen - och där verkar det som att man har en separat lågeffekts oscillator avsedd för just klockkristall och inget annat, och då får man anta att drivningarna är anpassade för detta.

Postat: 18 november 2007, 23:19:41
av sodjan
På senare PICs är TMR1-osc specifikt designad för 32 KHz drift.
Detta är t.ex en av skillnaderna mellan 16F628 och 16F628A, på den
äldre var TMR1-osc specad upp till 200 Khz, på 628A specas den enbart
för 32 KHz drift. Så man får anta att den är designad och optimerad för
just 32 KHz "klock-lristaller".

Postat: 20 november 2007, 15:47:02
av Frisk
sodjan, vad menar du med att den är designad för det, Att det redan är anpassat med serieresistans, eller ska de ändå vara där? Finns ju ett kopplingsexempel i PIC-manualen, där sitter det inte med några serieresistanser.
Märkte att jag behövde sätta T1CON.RD16 till noll, gick inget vidare att ändra tiderna annars, men tack för tipset, en typisk sak jag kunnat fastna på..
Kollade kod-exemplet i manualen, och tog insperation därifrån, men kopierade inte rakt av, vilket jag kanske istället borde gjort.

Har i alla fall programmerat om efter era förslag och verkar som klockan går mycket mer jämt nu än den gjort tidigare, dock inte fått in hastigheten helt rätt.

Postat: 20 november 2007, 16:26:49
av sodjan
Att det är en low-power oscillator byggd för dessa klockkristaller.
I tidigare PIC modeller var det en lite mer generell oscillator.
Jag kan inte svara bergsäkert om serieresistansen, men om den inte
finns med i databladet, så skulle jag i alla fall börja utan...

Hur "fel" går den just nu ?
Helt rätt kommer den naturligtvis aldrig att gå...

Postat: 20 november 2007, 18:25:21
av Frisk
Tack för infon, hoppas på att det funkar utan motstånd då.

Vet inte exakt hur mycket fel det är nu, men tror det är ca 15min/dygn, så är ju en del, men verkar vara konstant, så ska nog gå att justera in.

Nä, räknar inte med att ha byggt ett atomur, men vore trevligt om jag i alla fall kan få upp precitionen till kanske max 5min/månad, inte jättekul, men går i alla fall leva med.

Postat: 4 februari 2008, 21:11:05
av Frisk
Drar igång denna tråden igen, har inte haft så mycket tid att fixa med klockan senaste tiden, men i alla fall kommit fram till att klockan går fel å båta hållen, ibland för fort, och ibland för långsamt, verkar hålla sig antingen för långsamt, eller för snabbt ett tag, för att sen byta, rör sig om 15-20min/dygn åt båda hållen.
Vad kan vara fel? Några idéer? Förstår inte vad som skulle skapa sånna fel.

Råkade även ut för ett annat väldigt konstigt fel, klockan stod på 13, har jag för mig, och sekundrarna räknade upp till 64 (gick upp till 60, sen inget tänt i några sekunder) sen började den om, räknade inte upp varken minutrar eller timmar, vad kan detta bero på? Var inte omprogrammerad eller något sånt, hade inte gått längre sen reset än tidigare.
Körde en reset, sen gick klockan som den borde.

Postat: 4 februari 2008, 21:20:32
av Icecap
Mycket ofta beror sådant på att "vissa" skriver:

Kod: Markera allt

if(Seconds == 60)
  {
  Seconds = 0;
  Minutes++;
  }
och sedan kommer förbi med MER än 1 sek mellan, då kan sekunderna ha räknat till 60 ELLER MER... Rätt kod då?

Kod: Markera allt

if(Seconds >= 60)
  {
  Seconds -= 60;
  Minutes++;
  }
Skulle sekunderna ha råkat komma upp på 60 eller mer kan utläsningen kortvarigt se konstig ut men kommer snabbt i fas igen.

Postat: 5 februari 2008, 08:31:14
av spaderkung
En idé är att lägga möjlighet för synkronisering lätt tillgänglig. Det är ju inget konsitgt med regelbunden kalibrering av ex vågar och termometrar.

Postat: 5 februari 2008, 15:19:02
av Frisk
Tror Icecap har en poäng där, klart man borde göra så, det får såklart ändras i koden.
Måste varit det som hänt när sekundrarna bara snurrade och snurrade utan att klockan gick frammåt, även om jag har lite svårt att förstå att den skulle missa en if-sats en hel sekund, när det inte är mer kod än vad som är, men kan uppenbarligen hända, så får bli ändring där, tack för hjälpen!

Jo, visst är det naturligt med kalibrering, ska inte vara för svårt att komma åt, men tycker det verkar konstigt att den växlar så mellan att gå fort och långsamt, kan växla mellan en dag, så måste vara något annat som är fel.
Tror det får bli att hämta tiden från elnätet, behöver ändå 0-genomgångarna för framtida dimmer av belysning, kan jag lika gärna använda de som klockpuls med, går i alla fall exakt.
Men är ju klart en roligare utmaning att få kristallen att funka, nu när det var så jag tänkt mig från början.

Postat: 5 februari 2008, 18:40:18
av Icecap
Nu kan jag ju inte se ditt hela program (och jag vill inte heller!) men en del tror att de "ägar" main-loop-delen helt och fullt så att vad de än gör där knappast har betydelse för timingen för annat och det är ju fel!

Har jag en klocka som ska räknas upp använder jag alltid en timer-interrupt och gör uppdateringen Sek->Min->Timmar osv. direkt i interrupt-loopen, det tar minimalt med tid och det blir oerhört mer säkert.

Jag har dock enstaka gånger gjort så att interrupten bara räknar upp en sekundräknare, main-loop kollar då denna räknare och lägger värdet till sekunderna OCH subtraherar det värde som är adderat, på det vis kan man få det enkelt och idiotsäkert.

Och dessa räknare... "räkna upp till X" och folk använder "if(Counter == 60)"... vad om det skiter sig? NÅGOT går ALLTID fel och varför inte kolla såhär: "if(Counter >= 60)" om man ändå menar detta? På det vis kan man fånga mycket skit och säkra sig mot många fel.

Nåväl, nog svamlat. Att din klocka är instabil tyder på att något parameter är dålig, om du har det hela på ett experimentboard kan det förklara mycket då 32KHz kristaller är känsliga av bara fan, jag undviker dom då "vanliga" kristaller är MINST lika bra och oftast mer exakta och de kan trimmas också.

Har man en timer ledig eller som ger fasta interrupt kan man använda den till att räkna på klockan, Marta har ett flertal gånger beskrivit metoden på att få den exakt och jag har en gång beskrivit den i praktiken.