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?
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.
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.
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.
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
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?
@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?
@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 :)
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?
@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.
@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.
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?
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
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.
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.
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).
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... :)
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.
@ 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.
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.
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
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).
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.
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.
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
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).
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.
