www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Taktfrequenz vom ATxmega


Autor: Stefan94 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin.

Eigentlich habe ich ne recht leichte Frage. Jedoch kann mir das 
vorläufige
Datenblatt von Atmel keine genaue Antwort liefern.
Ich will nur wissen, mit welcher Frequenz ich den ATxmega laufen lassen 
kann. Es wird immer nur von einem max. internen 32MHz Oszi gesprochen, 
aber in Verwendung einer PLL soll folgendes machbar sein:
"The PLLFAC bits set the multiplication factor for the PLL. The 
multiplication factor can be in the range from 1x to 31x. The output 
frequency from the PLL should not exceed 200 MHz. The PLL must have a 
minimum output frequency of 10 MHz."
Bedeutet das, dass der Systemtakt auf 200 MHz hochgeschraubt werden 
kann? Ich deute jedenfalls diese Aussage unter Berücksichtigung des 
Schaltbildes so.
Hat schon jemand damit Erfahrungen gemacht?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
200Mhz gehen für einzelne periphere Module (Timer), nicht aber für den 
CPU-Kern. Dieser ist bis maximal 32Mhz spezifiziert. Da das Clock-Modul 
über diverse Teiler verfügt, kann man verschiedene Module mit 
verschiedenen Frequenzen takten. Ausprobiert hatte ich für den Kern mal 
64Mhz, was auch funktionierte, aber für Serien würde ich maximal 20% 
übertakten, falls dies wirklich nötig ist.

Autor: Stefan94 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank ... das leuchtet ein.
Weißt du, mit welcher Taktrate ich einen USART fahren kann? Bei einem 
internen 32MHz Takt und einem PLL-Multiplikator von 6 könnte ich ja 
192MHz erreichen. Und laut Datenblatt soll der Output einer PLL die 
200MHz nicht überschreiten, was damit ja gewährleistet wäre.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Laut Manual kann das UART maximal doppelt so schnell wie die CPU laufen, 
also 64MHz. Außerdem kann es Double-Speed, also fclk/8, was 8MBit 
Datentransferrate entspricht.

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
andere Frage: was ist die max. Frequenz für ext. Schwinger 16 oder 32MHz

Autor: Stefan94 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kopiere mal einfach aus dem Datenblatt:

External clock options:
– 0.4 - 16 MHz Crystal Oscillator
  This oscillator can operate in four different modes, optimized for
  different frequency ranges, all within 0.4 - 16 MHz.
– 32 kHz Crystal Oscillator
  A 32 kHz crystal oscillator can be connected between TOSC1 and TOSC2
  by enabling a dedicated Low Frequency Oscillator input circuit.


=> also maximal 16MHz

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ist denn der interne Takt so genau das man damit auch die Uart usw. 
Problemlos betreiben kann?
Oder sollte man dann doch auf ein externes Quarz zurückgreifen?

Autor: Stefan94 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Zauberwort nennt sich: DFLL. Damit ist eine Kalibrierung der 
internen Oszis (2 MHZ oder 32 MHz) zur Laufzeit durchführbar.

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefan94

Dein Datenblatt Auszug ist schon richtig aber....

ich kopiere mal auch aus dem gleichen Datenblatt:

32 MHz, Ext. Clk VCC = 3.0V 18.35mA
32 MHz, Ext. Clk, T= 85°C VCC = 3.0V 18.4mA

siehe dazu "DC Characteristics"

ist das ein Fehler im Datenblatt?

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@wt:

Die 16MHz beziehen sich auf die maximale Frequenz, wenn du einen Quarz 
anschließt. Du kannst ja auch einen externen Oszillator anschließen und 
dann kannst du 32MHz maximal "reingeben".

Aber im Grunde ist es egal ob du 16MHz oder 32MHz extern reingibst, denn 
der XMega hat eine interne PLL, damit kannst du die 16MHz zu 32MHz 
CPU-Takt verwandeln.

Ich denke, dass in vielen Fällen, besonders wenn das UART eher langsam 
ist (9600 Baud beispielsweise) sogar der interne Oszillator ausreichen 
wird. Ich hatte bisher mit dem internen Oszillator (2 MHz) und 9600 Baud 
UART gar keine Probleme :)

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke

um uart mit 9600 zu betreiben, reichen sicherlich ein paar MHz aus. Mich 
interessiert max. Dampf, was die Maschine kann, und da war ich ein 
bißchen vom Datenblatt irritiert:)

Hat schon jemand 32MHz getestet?

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec hat in der Codesammlung seinen Wav-Recorder. Ich glaub der 
läuft auf 32MHz. Einfach mal nachschaun.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@wt:
Nun ja, wenn du wirklich das Maximum rausholen möchtest, dann gönne 
deinem µC am besten doch einen 16MHz Quarz, dann biste auf der sicheren 
Seite.

Autor: wt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo ist dan rechenvorteil dem mega128 gegenüber? die netten perephrie 
features vom xmega lassen wir mal außen vor.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gibt es genug zu zu lesen im Forum.
Vom Prinzip her ist der ATxmega überhaupt nicht mit einem ATmega128 zu 
vergleichen.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@wt:

Du kannst die 16MHz über die interne PLL auf bis zu 200MHz erhöhen wenn 
du magst. Natürlich kannst du auch gleich einen 32MHz Oszillator 
anschließen, kostet auch kaum mehr und nimmt auch nicht mehr Platz weg.

Ich mache das so: 16MHz rein, PLL auf 4x stellen => 64MHz Takt. Dann den 
CPU-Takt auf Divisionsfaktor 2 stellen. Das gibt dann:
 - 32MHz CPU Takt
 - 64MHz Peripherietakt (Speicher etc.)

Die Architektur des XMegas und der Mega AVRs sind sehr verschieden. Beim 
XMega wurde halt auch ordentlich aufgeräumt, was die ganzen Altlasten 
anging. Ist halt wirklich schon ein schmuckes Teil mit einer modernen 
Hardwarearchitektur. Macht aber ne menge Arbeit die Projekte darauf 
anzupassen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. N. wrote:
> @wt:
>
> Du kannst die 16MHz über die interne PLL auf bis zu 200MHz erhöhen wenn
> du magst. Natürlich kannst du auch gleich einen 32MHz Oszillator
> anschließen, kostet auch kaum mehr und nimmt auch nicht mehr Platz weg.
>
> Ich mache das so: 16MHz rein, PLL auf 4x stellen => 64MHz Takt. Dann den
> CPU-Takt auf Divisionsfaktor 2 stellen. Das gibt dann:
>  - 32MHz CPU Takt
>  - 64MHz Peripherietakt (Speicher etc.)

Der RAM läuft auf 64MHz gescheit? Habe dazu (noch) keine Info im 
Datenblatt finden können.

Wie kann man sonst einen Timer mit 64MHz betreiben, ohne den RAM so 
schnell einzustellen?

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab zwar bloß flüchtig drübergeschaut, aber so wie ich das gelesen hab 
muss der Ram Synchron zum Core laufen, also maximal auf 32MHz. Wobei man 
ja auch den Core übertakten kann... Fänds aber sehr schick wenn man 
SRAM, DMA und externe Speicherinterface auch schneller takten könnte. 
Wobei 32MHz ja auch schon sauber ist.

Sebastian

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im XMega A Manual steht im Punkt 25.4 "EBI Clock":

The EBI is clocked from the Peripheral 2x (Clk2PER) Clock. This clock 
can run at the CPU Clock frequency, but it can also run at two times the 
CPU Clock frequency.

Wobei sich die 64MHz natürlich nur auf die Frequenz des SRAM Controllers 
bezieht. Natürlich wird nicht alle 15,63ns ein Speicherzugriff gemacht 
:)

Es sind, wenn ich meine Messung richtig interpretiert habe, 6 Taktzyklen 
für einen Speicherzugriff notwendig (LPC Mode nur ein ALE Signal). Wenn 
CPU Clock und EBI Clock gleich schnell sind, bedeutet dies, dass man 6 
CPU Taktzyklen auf die Beendigung des Befehles warten muss. Ist die EBI 
Clock jedoch doppelt so schnell wie die CPU Clock, dann braucht man nur 
noch 3 CPU Taktzyklen zu warten.

Allerdings sind 15,63ns Read/Write Zeit beim SRAM schon recht gering, da 
braucht man schon einen sehr schnellen RAM oder man baut sich wieder ein 
Waitstate ein.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. N. wrote:
> Im XMega A Manual steht im Punkt 25.4 "EBI Clock":
>
> The EBI is clocked from the Peripheral 2x (Clk2PER) Clock. This clock
> can run at the CPU Clock frequency, but it can also run at two times the
> CPU Clock frequency.
>
> Wobei sich die 64MHz natürlich nur auf die Frequenz des SRAM Controllers
> bezieht. Natürlich wird nicht alle 15,63ns ein Speicherzugriff gemacht
> :)

Schon, aber was ist mit dem internen SRAM? Das hängt laut "Clock 
Distribution" im Kapitel über die Clocks und Oscillators am ClkPER und 
die läuft bei dir ja mit 64MHz, dann oder nicht?

Andererseits soll es durch diese Clock Verteilung doch möglich sein, die 
Peripherals schneller zu takten als den Core. Wenn da aber jetzt der RAM 
noch mit dranhängt, und der nur FCPUmax verträgt, dann wäre das ja 
Unsinn.

Hmm, wo ist der Haken.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der interne RAM hängt an CLKPER, der externe an CLK2PER. CLK2PER kann 
halt 2x schneller als CLKPER sein.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon, aber wie schnell darf CLKPER sein? :-) Anscheinend schneller als 
die Maximale Taktfrequenz des Prozessors, sonst hätte man die nicht an 
zwei verschiedene Takt"Bäume" gehängt, oder wie sehe ich das?

Ok, habe den Grund gefunden warum das zwei einzelne Taktbäume sind: Man 
kann die Peripherals anhalten und den Prozessor weiterdaddeln lassen. 
Ansonsten müssen sie synchron sein (wie oben schon genannt).

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich realisiere gerade eine Studienarbeit mit dem XMega128A1 und 
durchforste gerade auch das Datenblatt. An vielen Stellen muss ich 
mehrmals nachlesen, weil ich es einfach nicht glauben kann, was da 
steht, was der Xmega alles so können soll... Ich glaube ich habe einen 
neuen Lieblingscontroller gefunden... :)

Autor: Stefan94 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat mal einer die DFLL ausprobiert? Ist der Oszi danach genau? Und wie 
sieht es mit der Temperaturabhängigkeit aus?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jau,

Laut Datenblatt sind +/-1% Genauigkeit zu erreichen. Eine 
Temperaturabhängigkeit kann ich im Datenblatt aber nicht finden.
  /* Enable necessary Clock sources. 32MHz and 32kHz Oscillator */
  OSC.CTRL = OSC_RC32MEN_bm | OSC_RC32KEN_bm;
  /* Wait for Oscillators to become stable */
  while(!(OSC.STATUS & OSC_RC32MRDY_bm));
  while(!(OSC.STATUS & OSC_RC32KRDY_bm));

  /* Start Calibrating the 32MHz Clock using
   * the internal calibrated 32kHz Oscillator */
  OSC.DFLLCTRL = (0 << OSC_RC32MCREF_bp);
  DFLLRC32M.CTRL = DFLL_ENABLE_bm;
  /* Set as System Main Clock */
  CCP = CCP_IOREG_gc;
  CLK.CTRL = CLK_SCLKSEL_RC32M_gc;

Eine UART Verbindung klappt problemlos und bisher absolut ohne Fehler, 
was aber nicht unbedingt was heißen muss.

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich würde ja mal interessieren wie die das mit der internen Referenz 
hinbekommen. Die interne Referenz leidet doch unter den gleichen 
Ungenauigkeiten und Temperatureinflüssen wie der interne Oszillator...

Bei einer externen Referenz kann ich mir solche Werte und noch besser 
sehr gut vorstellen. Aber vielleicht weiß ja jemand wo das der "Trick" 
bei ist.

Autor: Stefan94 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Simon K.

wie kommst du auf die +/-1% ?
Ich habe eine Angabe im Preliminary zur A1-Familie die gleiche Angabe 
gefunden (Seite 70). Aber ich deute diese Prozentzahl als Abweichung 
OHNE DFLL.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, stimmt. Auf Seite 81 im A1 Datasheet 11/08 ist ein Diagramm für den 
32k Oszillator angegeben (Frequenz vs. Temperatur). Da per DFLL dieser 
als Referenz genutzt wird, hat der Ausgang der DFLL genau die gleichen 
Schwankungen, wie diese Referenz Clock.

Würde ich zumindest mal vermuten.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin noch nicht so ganz durch den USART durchgestiegen. Bekommt man 
mit einem 16 MHz Quarz möglichst exakte Baudraten, auch 115200 und mehr, 
oder wäre man wie beim AVR mit einem 14,7456MHz Quarz besser bedient, 
auch wenn der Core dann (etwas) langsamer läuft?

Das Excel File, das Atmel anbietet, funktioniert unter OOo leider nicht 
und Excel hab ich nicht. Daher kann ich es damit nicht herausfinden.

http://www.elektronik-projekt.de/thread.php?threadid=5882

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst mit einem 16 MHz Quarz alle gängigen Baudraten erzeugen, da es 
einen Fractional Baud rate divider gibt.

Übrigens benötigt man für den ATxmega nicht mal einen Quarz, da der 
interne 32MHz Oszillator auf +/-1% getrimmt werden kann (mit On Board 
Kalibrationswerten).

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Du kannst mit einem 16 MHz Quarz alle gängigen Baudraten erzeugen, da es
> einen Fractional Baud rate divider gibt.
Ja, den hab ich noch nicht ganz kapiert. Knackpunkt ist halt, ich kann 
auch bei einem normalen AVR bei 16MHz eine Baudrate von 115200 
einstellen, aber eben mit ein paar Prozent Abweichung. Wenn man nur 
einzelne oder wenige Zeichen hintereinander sendet ist das auch kein 
Problem. Aber wenn man 10 oder 20 Zeichen ohne Pause sendet gibts 
irgendwann Datensalat, weil sich der Empfänger nicht mehr 
synchronisieren kann.
>
> Übrigens benötigt man für den ATxmega nicht mal einen Quarz, da der
> interne 32MHz Oszillator auf +/-1% getrimmt werden kann (mit On Board
> Kalibrationswerten).

Das hab ich schon mitbekommen. Aber da hab ich das gleiche Problem wie 
oben schon geschrieben. +/- 1% kann bei hohen Baudraten und größeren 
Datenmengen schon zuviel sein. Außerdem vermute ich mal, dass man die 
Auto Kalibrierung in regelmäßigen Abständen machen muss, wenn sich z.B. 
die Umgebungstemperatur stark ändert. Ich kann mir nicht vorstellen, 
dass der nach einmaliger Kalibrierung dauerhaft stabil ist.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nene,
Also mal ein Beispiel. Bei mir ist es Seite 328 im Datenblatt.
Setze BSCALE auf -7.

Nach der Formel für BSEL bei BSCALE < 0 ergibt das:

Macht:

Wenn ich mich jetzt nicht vertan habe. Das sollte in jedem Fall 
ausreichen.

Die Kalibrierung ist ein Digital Frequency Locked Loop und ist die ganze 
Zeit aktiviert und führt die Frequenz immer nach.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will die Frage nochmal anders formulieren.

Komme ich mit dem internen 32MHz Oszillator bei einer Baudrate von 
115200 zuverlässig auf eine Abweichung von unter 0,5%? Idealerweise 
0%.

Sorry, hab deine Antwort zu spät gesehen. Sieht ja vielversprechend aus. 
Danke.

Bei der Gelegenheit: ist es möglich, das Excel File irgendwie für OOo 
gangbar zu machen? Wäre recht hilfreich und hätte die Frage gespart

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab schon reingeguckt ins Sheet, aber sieht irgendwie so aus als müsste 
man den ganzen Makroteil neu schreiben.

Aber das Datenblatt, bzw. die AppNote zur xmega UART ist auch hilfreich. 
Man sollte für die möglichst genaueste Einstellung ein sehr niedriges 
BSCALE anstreben (<0). Wenn BSCALE > 0 ist, verliert man Genauigkeit 
(Das braucht man, wenn der ausgerechnete BSEL Wert zu groß ist für das 
Register).

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Hab schon reingeguckt ins Sheet, aber sieht irgendwie so aus als müsste
> man den ganzen Makroteil neu schreiben.
Schade, hätte die Sache etwas erleichtert. Na mal schauen.
>
> Aber das Datenblatt, bzw. die AppNote zur xmega UART ist auch hilfreich.
> Man sollte für die möglichst genaueste Einstellung ein sehr niedriges
> BSCALE anstreben (<0). Wenn BSCALE > 0 ist, verliert man Genauigkeit
> (Das braucht man, wenn der ausgerechnete BSEL Wert zu groß ist für das
> Register).

Ich hab die AppNote schon durch. Das mit dem BSCALE hab ich einfach noch 
nicht ganz verstanden. Aber grundsätzlich ein möglichst niedriger BSCALE 
Wert und dann nach oben arbeiten, bis man einen BSEL Wert mit möglichst 
geringer Abweichung gefunden hat.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.