Hallo,
ich habe folgendes Problem. Ich betreibe einen Timer des XMega (Hi-Res
Erweiterung) mit 120 MHz und generiere damit ein Rechtecksignal mit
variabler Frequenz (Frequency (FRQ) Waveform Generation).
Es besteht jedoch kein linearer Zusammenhang zwischen dem Compare-Match
Wert und der Frequenz des am Pin anliegenden Signals. Folgende Messungen
habe ich durchgeführt.
1
CCA (Compare Match) gemessene Frq. res. Per.-Frq.
2
100 577,4 kHz 117 MHz
3
50 1,111 MHz 113 MHz
4
20 2,5 MHz 105 MHz
5
10 4,292 MHz 94 MHz
6
5 6,667 MHz 80 MHz
7
4 7,519 MHz 75 MHz
8
2 10,0 MHz 60 MHz
9
1 12,05 MHz 48 MHz
10
0 14,93 MHz 29 MHz
Den Wert für die resultierende Peripherie Frequenz habe ich mit der im
Datenblatt Angegebenen Formel:
Wie kommt es zu diesem Zusammenhang? Ist er irgendwo im Datenblatt oder
einer Application Note beschrieben?
Jo R. schrieb:> Den Wert für die resultierende Peripherie Frequenz habe ich mit der im> Datenblatt Angegebenen Formel:>
>> Wie kommt es zu diesem Zusammenhang? Ist er irgendwo im Datenblatt oder> einer Application Note beschrieben?
Nachdenken.
Dein Timer ist im Grunde nur ein Teiler. Wenn der Timer bei jedem 2.ten
Taktsignal einen Compare Match auslöst dann tritt dieses Ereignis
logischerweise halb so oft auf, wie du Pulse im Taktsignal hast. Du hast
damit die Frequenz effektiv halbiert.
Löst der Timer nur bei jedem 3.ten Taktisgnal den Compare Match aus,
dann kommen die Compare Matches logischerweise mit 1/3 der Frequenz des
Taksignales.
Allgemeiner: Löst der Timer bei jedem n-ten Taktisgnal einen Compare
Match aus, dann tritt das Ereignis 'Compare Match' mit 1/n der
Taktfrequenz auf.
Das erklärt schon mal, warum in der Formel F_per und CCA vorkommen und
warum F_per durch CCA geteilt wird.
Warum CCA+1
Ganz einfach. Damit der Timer 3 Takte abzählt, muss er zählen: 0, 1, 2
d.h. der Compare Match muss bei 2 kommen, damit 3 Takte vergehen. der
Zählerstand 0 ist ja auch noch da.
Und dann bleibt noch das * 2
Wenn du mit dem Compare Match, bei jedem Auftreten eines Compare Match
einen Ausgangspin toggelst, dann brauchst du logischerweise 2 Compare
Matsches, bis du den Ausgang von 0 über 1 wieder auf 0 zurückgebracht
hast.
Eine 'Schwingung' beginnt bei 0 und endet wenn der Ausgang wieder 0
wird. Daher brauchst du 2 Compare Matches und daher halbiert sich die
bisher errechnete Frequenz noch.
Deine Tabelle res. Per.-Frq. kann nicht stimmen.
Aus der Formel ist völlig klar, dass der Wert kleiner werden muss, wenn
CCA größer wird.
1/2 ist nun mal größer als 1/3 und das ist größer als 1/4, etc.
Je größer der Nenner in einem Bruch wird, desto kleiner wird der Wert
des Bruches.
> Es besteht jedoch kein linearer Zusammenhang zwischen dem> Compare-Match Wert und der Frequenz des am Pin anliegenden Signals.
Das ist richtig.
Siehe Formel.
Es ist ein 1/n Zusammenhang.
Vielen Dank für die ausführlichen Antworten. Aber ich habe mich wohl
leider missverstädnlich/falsch ausgedrückt. Es ist kein linearer
Zusammenhang.
Mein Problem ist: Ich takte den Timer mit 120MHz. Wenn ich jetzt den
CompareMatch auf z.B. CCA=10 stelle, dann müsste ich einen Takt mit der
Frequenz von 5,45 MHz am Pin haben. Gemessen beträgt dieser aber nur
4,292 MHz.
jor schrieb:> Mein Problem ist: Ich takte den Timer mit 120MHz. Wenn ich jetzt den> CompareMatch auf z.B. CCA=10 stelle, dann müsste ich einen Takt mit der> Frequenz von 5,45 MHz am Pin haben. Gemessen beträgt dieser aber nur> 4,292 MHz.
2 Möglichkeiten
* Fehlmessung
* Nachdem wir davon ausgehen können, dass sich der Timer wohl kaum
verzählen wird, werden dann wohl die 120Mhz nicht so ganz stimmen.
Wo kommen die denn her?
Aber wie in der Tabelle zu sehen ist müssten sich dann die 120 MHz
verändern wenn ich ausschließlich den CCA Wert im Programm verändere.
Fehlmessung kann ich natürlich nicht ganz ausschließen aber ich messe
mit einem Rigol DS1102E und traue diesem zu, dass es sich bei CCA=0
(14,93MHz) nicht um >400% vermisst
Die 120 MHz kommen aus der internen PLL mit Faktor 4. Diese wird über
einen externen Quarzoszillator versorgt mit 30MHz.
Der externe Quarzoszillator hat an seinem Ausgang laut Oszi einen Takt
von 29,94MHz. Damit schließe ich persönlich den Messfehler aus.
Jo R. schrieb:> Aber wie in der Tabelle zu sehen ist müssten sich dann die 120 MHz> verändern wenn ich ausschließlich den CCA Wert im Programm verändere.
Ach, jetzt versteh ich.
Du hast die Timer Frequenz aus der gemessenen zurückgerechnet!
Das sieht in der Tat dann seltsam aus.
>Die 120 MHz kommen aus der internen PLL mit Faktor 4. Diese wird über>einen externen Quarzoszillator versorgt mit 30MHz.>Der externe Quarzoszillator hat an seinem Ausgang laut Oszi einen Takt>von 29,94MHz. Damit schließe ich persönlich den Messfehler aus.
Autsch. IMHO verträgt (lt. Datenblatt) der XMega 4...16Mhz externen
Oszillator. Das gilt zumindest für den XMega128A1.
Läuft der XMega sicher mit externem Quarz??
Nein mit externem Quarzoszillator. Im Datenblatt steht nicht explizit
drin in welchem Bereich die external clock liegen darf aber in einem
Diagramm (Active Supply Current vs. Frequency) geht sie auf jeden Fall
bis 32 MHz.
Wie gesagt Probleme mit der Taktversorgung schließe ich eigentlich aus
da bei großen Compare-Match-Werten CCA die Taktversorgung stimmt.
Initialisierung Takt:
1
CLKSYS_XOSC_Config(OSC_FRQRANGE_12TO16_gc,// Frequency range for high-frequency crystal, does not apply for external clock or 32kHz crystals.
2
false,// True of high-quality watch crystals are used and low-power oscillator is desired.
3
OSC_XOSCSEL_EXTCLK_gc);// Combined selection of oscillator type (or external clock) and startup times.
4
CLKSYS_Enable(OSC_XOSCEN_bm);
5
do{}while(CLKSYS_IsReady(OSC_XOSCRDY_bm)==0);
6
CLKSYS_PLL_Config(OSC_PLLSRC_XOSC_gc,4);// Configuration of the internal high-frequency PLL
7
CLKSYS_Enable(OSC_PLLEN_bm);// enables the selected oscillator
8
CLKSYS_Prescalers_Config(CLK_PSADIV_1_gc,CLK_PSBCDIV_2_2_gc);// Configuration System Clock Prescalers
9
do{}while(CLKSYS_IsReady(OSC_PLLRDY_bm)==0);
10
CLKSYS_Main_ClockSource_Select(CLK_SCLKSEL_PLL_gc);// selects the main system clock source
11
CLKSYS_Disable(OSC_RC2MEN_bm);// disable the internal 2 MHz RC Oscillator
ich schrieb:> 5 Sekunden ins Datenblatt geschaut:>> • External clock options> – 0.4 - 16 MHz Crystal Oscillator> – 32.768 kHz Crystal Oscillator> – External clock
also unter einem Quarzoszillator versteht man bzw. ich eine fertige
Oszillatorschaltung die einen bestimmten Takt liefert. dieser ist in
meinem Fall 30MHz und an XTAL1 angeschlossen. Im Datenblatt wird diese
Art von Taktversorgung "External clock" genannt.
ich schrieb:>> CLKSYS_XOSC_Config( OSC_FRQRANGE_12TO16_gc,>> 12TO16... da stehts auch!
Das hat wenn man als Eingang "external Clock" wählt keinen Einfluss. Ich
hätte da beliebig etwas angeben können.
Ach so, dann hab ich dich falsch verstanden.
Man hat doch beim xmega die möglichkeit die fper auf einem Pin aus zu
geben, oder? Das würd ich mal versuchen.
Ich würde auch mal versuchen deine 30MHz über den Vorteiler an die PLL
zu geben, so wie auch der interne 32MHz Oszillator angeschlossen ist.
Das Datenblatt sagt: fFRQ = fPER/(2*(CCA+1))
Gemessen hast Du: fFRQ = fPER/(2*(CCA+4))
Scheint so, als wenn bei der hohen fPER da noch drei zusätzliche Takte
verbraten werden, bis der Teiler wieder scharf ist.
Der Timer läuft bis 32Mhz und an CPU_PER und nicht CPU_PERx4. Du hast
den HiRes Modus noch nicht korrekt verinnerlicht. Im HiRes Modus läuft
der Timer immer noch mit CPU_PER also mit max. 32MHz und gleichem Takt
wie die CPU. Die somit erzeugbaren Frequenzen beziehen sich max. auf
32MHz. Dabei zählt der Timer intern aber +4 statt +1 und vergleicht die
untersten 2 Bits mit einem speziellen Hardware Comparator der mit
CPU_PERx4 laufen kann.
Anders ausgedrückt: zeige uns im Datenblatt wie du den Timer mit
CLK_PERx4 takten kannst statt mit CLK_PER=CLK_CPU.
Imk HiRes Modus taktet man mit CLK_PERx4 nur einen schnellen 2Bit
Comparator der die untersten 2 Bits der Compare Register vergleicht.
Ergo: Frequenzauflösung des Timer wie bei 32MHz aber PWM Auflösung um
Faktor 4 erhöht so als ob die Compare Register mit 32x4 MHz laufen
würden.
Gruß Hagen
Thread beobachten
Seitenaufteilung abschalten