nauwkeurigheid interne klok AVR controller

Met een timer alleen ga je er waarschijnlijk niet komen. Je zal een tellertje moeten bijhouden.

Als de µC niets anders moet doen dan om de x tijd een relais aan en af schakelen, dan kan je al beginnen met DIV8 aan te zetten. Je interne klok wordt dan al 1MHz.

Laat nu een timer lopen die elke seconde een overflow genereerd. Je hoogt dan een teller op. Dat zijn 3600sec/uur. 14400 overflows voor 4 uur. 600 voor 10 minuten.

Ik zou kiezen voor een bistabiel relais of een solidstate.

edit: onnauwkeurigheid kan je wegwerken door het aantal overflows aan te passen. Vraag is of iets dat 4uur en 10 minuten duurt enkele seconden een wereld van verschil maken.

Wil je het echt heel nauwkeurig? Gebruik een DCF module of een GPS. Veel GPS-modules hebben een 1PPS signaal waardoor je al een nauwkeurige seconde krijgt. Uit de GPS string kan je ook de UTC tijd halen. Je hoeft dan geen tellertje bij te houden maar de aan uit tijden.

[Bericht gewijzigd door buckfast_beekeeper op dinsdag 5 november 2013 09:40:55 (31%)]

Interne klok van een AVR kan dacht ik zo'n 10% afwijken/slingeren. In de datasheet staan de exacte getallen.

Doe er een extern kristal aan en het zal al een stuk beter zijn.

Idd, die interne clock is een belabberd ding. Beter een kristal gebruiken, en de juiste belasting condensatortjes, anders verloopt een kristal net zo hard na verloop van tijd.

Ook het waitms statement is niet erg nauwkeurig.
Je kunt beter met een timer werken of nog beter met de rtc functie in Bascom, zie Config Clock = Soft in de help file.

een afwijking van enkele seconden is niet erg maar nu is het meer dan 15 minuten. wetende dat de cyclus een 100-tal keer zal herhaald worden is deze afwijking van ±15 minuten dus teveel.

Die clock is prima te calibreren. Maar voor jouw doel gebruik je een Xtal. In enige vorm.

ik ga morgen eentje halen en dit opnieuw proberen.
zullen de wait commando's ook nauwkeuriger zijn of blijft het aangeraden deze te vervangen?

Geen idee hoe 'wait' geïmplementeerd is. Ik ben hoe dan ook geen fan van 'delay' of 'wait' of wat dan ook. Al zal het soms best nuttig zijn.

Hangt ook af van hoe je ze gebruikt. 1000 waits van 1mS is veel onnauwkeuriger als 1 wait van 1S...

Met een wait kan je niet eens meer checken of het programma nog wel loopt.

Gebruik een timer elke seconde. In dezelfde interrupt toggel je een uitgang met een ledje. Zie je tenminste elke seconde dat de µC nog 'leeft'.

In principe doe je in een interrupt zo weinig mogelijk en doe je de verwerking buiten de interrupt. In dit geval zal snel een bitje draaien niet zo veel uitmaken.

Moet je toch achter een kristal aan, dan hoeft dit geen 20MHz exemplaar te zijn. Bekijk uit welke frequentie je een zo nauwkeurig mogelijk 1Hz signaal kan halen. 3,6kHz horloge kristallen zijn daar uiteraard zeer geschikt voor. 4MHz of 12MHz zijn ook zeer goed bruikbaar.

Makkelijk timers uitrekenen.

Dat kwartier-op-4-uur is 1:16. Dat is 6%. Dat valt binnen de nauwkeurigheid die Atmel opgeeft (+/- 10%).

Maar in de praktijk is wat atmel opgeeft alleen zo onnauwkeurig als je de boel op de max en/of min temp met mekaar gaat vergelijken. Jou afwijking is dus significant meer dan ik zou verwachten. Onnauwkeurigheden zoals reeds aangehaald doordat je niet de juiste "sleep" dingen gebruikt zullen ook meespelen.

Atmel geeft op dat als je de boel calibreert voor de temp die je gaat gebruiken, je een nauwkeurigheid van (uit m'n hoofd) 2% moet kunnen halen. Dus als het inderdaad precies 15 min op 4 uur is, kan je de code aanpassen om daarvoor te corrigeren. tel bijvoorbeeld 14400-900 = 13500 seconden af. (of 15300 als ie de andere kant op moet)....

Of 2% nauwkeurigheid voor jou genoeg is, moet je zelf bepalen. Het is met "tijd" vaak zo dat het enorm opvalt als er al een kleine afwijking is. Een kristal is niet altijd voldoende nauwkeurig.

Mijn vader wilde z'n lipo van z'n fiets iedere maand een paar uur opladen. Dus heb ik een "28 dagen uit, 8 uur aan" ding voor hem gemaakt. Daarbij vind ik het niet een probleem als dat 29dagen of 27 dagen wordt. Maar of dat voor jou wel een probleem is, weet ik natuurlijk niet.

Als je je programma opbouwt met wait instructies zit je ook met een ander probleem.

Als je bv 10 x 1ms wait doet in een loop dan kom de instructietijd van die loop er ook steeds bij. Als je direct in ASM programmeert valt dat allemaal heel erg goed uit te rekenen omdat je kan opzoeken hoelang een instructie precies duurt je zelf precies weet hoe groot jouw code is kan je dat best goed krijgen.
Helaas weet je nooit precies welke code bascom ervan maakt dus al met al zit er ook hoop o9nzekerheid in je timing.

Toch kan je als je wilt je huidige programma wel een stuk beter krijgen door inderdaad goed te meten hoeveel je programma te snel of te langzaam is. Is het bv te langzaam en duurt het 15 minuten langer dan haal je er gewoon voor 15 minuten aan instructies uit en kijk dan weer opnieuw.

Dus ook zonder interrupts kan je het best redelijk goed krijgen. Je zal het proces enkel een aantal keer moet tunen. Temperatuur schommelingen kunnen wel roet in het eten gooien maar als het ding altijd op kamertemperatuur staat dan is dan temperatuur variatie niet te erg voor je stabiliteit.

... terwijl Atmel de boel moet garanderen tussen -20 en +85 of zoiets. Jij weet dat het 15-30 graden zal zijn.

Als je een relais 6x per dag wilt bedienen zonder dat er een verloop optreedt dan ga je het met een kristal ook niet redden. Tenzij je synchroniseert met een DCF klok. Maar dat is misschien wel met een kanon op een mug schieten.

Om 1 keer per 4 uur een relais te bedienen zonder verloop zou ik de 50Hz van het lichtnet gebruiken. Vrijwel alle wekkers maken daar ook gebruik van.

ondertussen een 16Mhz kristal erbij geplaatst. de wait functies heb ik voorlopig gelaten voor wat ze zijn en op het eerste zicht lijkt dit nu perfect juist te lopen. even een paar dagen laten lopen om te kijken of dit zo blijft. bedankt al voor de tips.

Je kunt timer/counter0 klokken met een 32.768 kHz horloge kristal, daar kan je een nauwkeurige klok mee maken. Zie application note AVR134. Ik weet alleen niet of Bascom hiermee uit de voeten kan..

een willekeurig kristal heeft een tolerantie van 30ppm.

Dat is 2.5 sec per dag. Dus na een maand loopt ie een minuut verkeerd (of beter, KAN ie een minuut verkeerd lopen). Of je dat acceptabel vind moet je zelf weten.