Klockjitter i AVR:ens RC-oscillator

[blueint]

http://www.scienceprog.com/avr-internal ... -research/



Verkar som AVR RC-oscillatorn har fått signifikant högre jitter sedan 2005-2006 enligt artikeln. Rätt bra att veta om man flyttar kod avsett för en äldre version till en nyare. T.ex på ATtiny 2313 v4.2 kan det variera upp till 60 ns vid en cykel på 200 ns (~5 MHz).

[Icecap]

Kan det vara att det är med flit? Man använder ju jitter för att skapa en spektrumspridning vilket gör det enklare att klara EMC-krav.

[blueint]

Fast då skulle ju kristalloscillator vara ödesdiger..

[Icecap]

Kristalloscillator med inbyggt jitter kallas "Spread spectrum oscillator", googla gärna vetja eller KOLLA HÄR

[sodjan]

> Rätt bra att veta om man flyttar kod avsett för en äldre version till en nyare.

Jag kan inte tänka mig speciellt många fall när just det har någon avgörande
betydelse. De flesta fokuserar mer på frekvensstabilitet över tiden o.s.v.

[vfr]

Kan det vara att det är med flit? Man använder ju jitter för att skapa en spektrumspridning vilket gör det enklare att klara EMC-krav.

Intressant tillämpning på jitter!

Många ggr så är ju jitter av ondo och man vill ha så lite som möjligt. Det var ju kul att man använder det praktiskt för det ändamålet. Och visst, egentligen är det ju ganska självklart när man tänker efter.

En kollega på ett tidigare jobb utvecklade en UART som använde sig av jitter för att köra ett 600 bauds modem på en 32kHz kristall. Det säger sig ju vid en enklare räkning att den divisionen (32768/600) inte går jämt ut. Genom att då dela med olika divisionsfaktorer för varje cykel, så fick man en divisionsfaktor som ett bråk, d.v.s inte ett heltal. I praktiken så blev det jitter, men det spelade ingen roll.

[Birger1234]

Kan tänka mig flera kritiska applikationer där du inte vill ha in mera jitter
PLL, USB och kvalitets applikationer för CODEC's. Codecs med för mycket
fas jitter låser inte, en del har till och med inbyggd jitter detektor som slår
till om det skevar för mycket.

[sodjan]

> Kan tänka mig flera kritiska applikationer...

I en AVR ?

[jesper]

Och som kör på RC-oscillatoren?

[blueint]

Kommunikation till låg kostnad..

[sodjan]

> Och som kör på RC-oscillatoren?

OK, jag ger upp. Vad är poängen ?
Vad har RC-osc med detta att göra ??

[snigelen]

Hela tråden handlar om RC-oscillatorn i AVR. Hur sedan jämförelsen med en kristall gått till begriper jag inte. Här är orginalet till "nyheten" för den som är slängd i japanska (det finns en översätt-länk).

http://elm-chan.org/docs/avr/jitter.html

[sodjan]

Ah, OK...
Jag fick för mig att det hela handlade om jitter i kristalloscillatorer.
Sorry...

[monstrum]

Förstår inte riktigt oscilloskopbilderna. Hur har dom triggat när bägge flankerna ser ut att fluktuera? De bilderna säger väl ingenting, mer än att jittret inte är 0.000%. Ska man se något så får man ju se till att trigga på en flank så att den är referens.

Edit: Var lite snabb, triggningen sker naturligtvis på en tidigare flank, men fortfarande säger inte bilderna något då jittret naturligtvis multipliceras med antalet cykler (vilket man inte ser) innan.

Edit2: Återigen lite snabb... Det framgår ju faktiskt enligt bilden att man triggat 10 us före det man ser. Dock förstår jag inte TS:

T.ex på ATtiny 2313 v4.2 kan det variera upp till 60 ns vid en cykel på 200 ns (~5 MHz).

60 ns på 10 us ja, dvs fortfarande i princip försumbart för de allra flesta applikationer.

[Icecap]

Och det viktiga belysas inte: hur väl passa frekvensen över "lång" tid?

Först o främst är det ingen vettig som designer tidskritiska applikationer som baseras på en RC-oscillator, alltså faller det argument.
Därnäst är jitter ingen garanti gör att frekvensen svänger över tid, om vi tar en UART som exempel brukar de sampla 16 gg/bit och om jitter'n faktisk drar iväg åt fel håll under de 16 samplingar kan det bli lite problematisk, det är helt sant men ingenstans framgår en så enkel upplysning.

Om man delar RC-oscillatorns frekvens med t.ex.16 och sedan kollar vilken jitter som finns ur den delade frekvens kan det likaväl fortfarande vara 60ns och då är det ju än mer likgiltigt.