Atmega uC tidmätning (microsec) [Löst]

MrFreeze · Inlägg av **MrFreeze** » 17 januari 2007, 15:57:29

Hej !

Finns det någon slags program-counter på Atmegan som bara räknar helt
dumt klockcykler eller något annat sätt att kunna mäta en kort tid mellan till exempel
två interrupts ?

Dom enda lösningar jag hittat består av en timer som räknar millisekunder
i en global variabel men även om man skulle kunna få den (timern) att räkna
snabbare(typ hundradels millisekunder) så känns det varken som en
kostnadsfri (processor kraft) eller elegant lösning.

finns det något enkelt sätt att komma undan det här (helst utan extra kretsar) ?

Tackar på förhand

/Ludde

vfr · Inlägg av **vfr** » 17 januari 2007, 16:23:42

Nu är jag ingen expert på AVR men nog måste det gå att få bättre uupplösning på timer än 1ms???

Timer är väl annars ett utmärkt sätt att mäta som inte tar upp mycket CPU-kraft.

Mupp · Inlägg av **Mupp** » 17 januari 2007, 16:32:11

Först är det nog bäst att fundera lite över vilka storleksordningar vi pratar om här. Du säger att du vill mäta antalet nanosekunder mellan två händelser, på en avr. Om vi för resonemangs skull antar att denna avr är klockad i 10 MHz så är en klockcykel 100ns lång. Så redan där ligger ju en lägsta gräns för vad som är intressant att mäta, avbrott registreras ju i diskret tid definierat av klockcykelns längd, för att vara lite luddig. Vill du då mäta antalet klockcykler mellan två avbrott så kan man tänka sig två sätt att göra det utan några yttre komponenter, antingen mha en timer eller att göra samma sak som timern, dvs räkna, i mjukvara. Vilket som är billigast beror ju på. Timern är ju en kostnad, behöver du alla timers till nåt annat så blir det ju lurigt. Om du gör det i mjukvara låser du å andra sidan upp processorn till att inte göra annat än räkna, och i andra fall än det triviala där du helt enkelt vill räkna cykler fram till nästa avbrott (vilket som helst) så får du problem med jitter, dvs svaret du får behöver inte vara korrekt eftersom du inte räknar då ett avbrott hanteras. Vidare kan tänkas en viss overhead om du gör det i mjukvara som gör att du räknar fel, tex så kanske (rimligtvis) din räknarloop längre än en cykel, och då blir det ju svårt att veta exakt när avbrottet kommer.

Kontentan, fundera lite över hur stor noggrannhet du vill ha, vilka storleksordningar vi pratar om, och vad som är att betrakta som dyrt i just den här tillämpningen.

Edit: ordföljd, dessutom ska jag påpeka att naturligtvis går det att få större noggrannhet än 1ms mha en timer i en avr, jag har inte träffat på någon som inte går att klocka som huvudklockan.

Edit2: ja ibland kan det ju naturligtvis vara bra att räkna rätt...

MrFreeze · Inlägg av **MrFreeze** » 17 januari 2007, 17:07:52

Tackar tackar!

Jo bättre upplösning än 1ms går ju att fixa till, men det går väl knappast att
fixa nano sekunds uppösning till exempel.
På en 10mhz så är ju en klockcykel 0,1microsec men overhead
på en interrupt osv gör ju att man inte kan mäta ens 1microsec antar jag,
dessutom käkar det ju upp all processor kraft om timern ska pinga
som en galning.
Eller kan man använda en timer som en klocka (alltså inte en timer som
'händer' efter en viss tid och då vet man att en viss tid har gått utan mer
som en klocka som man kollar på för att få den exakta tiden 'nu' ?

Vilken upplösning jag behöver, hmm, jo det är ju en bra fråga!

Tanken är att jag får pwm insignaler från en interrupt och en
timer genererar utsignaler (pwm:ar också) medans huvudloopen räknar ut en massa saker
och det hade varit väldigt smidigt att ha "tiden" som till exempel klockcykler.

Upplösningen då, ja om jag mäter en pwm på 1-2msec så hade det ju varit
bra att ha en upplösning på typ 1/1000 eller 1ns då alltså 16 cycler på
en atmega16mhz.

Om jag sänker upplösningen till 1/256 så kan ju en timer-räknare använda
max ~60 cycler och det kan ju funka, men det blir ju inte mycket kraft över
till alla beräkningar...

Det bästa hade ju varit att kunna ha det hela i software, men om det
inte finns (eller det blir för processor-kostsamt), hur skulle man kunna göra
annars?

/Ludde
[EDIT]nanosec ->microsec

bengt-re · Inlägg av **bengt-re** » 17 januari 2007, 17:12:17

"Upplösningen då, ja om jag mäter en pwm på 1-2msec så hade det ju varit
bra att ha en upplösning på typ 1/1000 eller 1ns då alltså 16 cycler på
en atmega16mhz. "

Öhh... en tusendel av 1 ms är 1us... och en tusendel av detta är en ns...

Man behöver inte heller ha jämna tiopotenser, går bra med 50 eller 200 eller 167ns klocka också... Finessen med uC är att det är rätt bra på att räkna..

peter555 · Inlägg av **peter555** » 17 januari 2007, 17:13:07

Hur räknar ni egentligen, en klockcykel är 100ns vid 10 MHz.

Edit: Bengt-re hann före

MrFreeze · Inlägg av **MrFreeze** » 17 januari 2007, 18:02:40

Ojdå, jo där blev det ju fel ska såklart vara mikro sekunder och inte nano...

Editerar...

bengt-re · Inlägg av **bengt-re** » 17 januari 2007, 18:54:29

Din uC lär ju ha någon timer eller CCP-modul om du har tur. Med timer så kan ju få 100ns uppslösning, men med 16-bitar hamnar du nära gränsen för overflow om det var någon till några ms som du ville mäta. Antagligen så kan du koppla på en post eller pre scaler för att dela ner klockan ett steg. Problemet om du inte har någon CCP-modul blir att du måste programmässigt hitta triggervilkoren - och då detta tar mer än en klockcykel så kommer du att få lite jitter (ungefär 4 Tcy), Detta jitter om du delar ner klockan med 4 sjunker då till ungefär 1 LSB och det kan man ju leva med (?!) Meningslöst att ha upplösning som drunknar i jitter likssom....

MrFreeze · Inlägg av **MrFreeze** » 17 januari 2007, 19:29:39

*läser databladet igen*

Jaha, alltså jag kan egentligen bara koppla på en timer och 'läsa' av
hur länge den har räknat (!) ?
Prescalad etter triggande en func. som räknar 'överslagen'.

Det skulle lösa mitt problem perfekt !

eller har jag missat något / det är inte så det funkar ?

/Ludde

bengt-re · Inlägg av **bengt-re** » 17 januari 2007, 20:30:02

Yepp - det är så du måste göra om du inte har någon CCP. Fördelen med progrmstyrda metoden är att man kan trigga på bitmönster om man vill. Inte aktuellt i detta fallet, men ändå

MrFreeze · Inlägg av **MrFreeze** » 18 januari 2007, 17:20:47

Okay, tack så mycket för hjälpen !!

/Ludde *pillar vidare*