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.
andere Frage: was ist die max. Frequenz für ext. Schwinger 16 oder 32MHz
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?
Das Zauberwort nennt sich: DFLL. Damit ist eine Kalibrierung der internen Oszis (2 MHZ oder 32 MHz) zur Laufzeit durchführbar.
@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?
Travel Rec hat in der Codesammlung seinen Wav-Recorder. Ich glaub der läuft auf 32MHz. Einfach mal nachschaun.
@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.
wo ist dan rechenvorteil dem mega128 gegenüber? die netten perephrie features vom xmega lassen wir mal außen vor.
Da gibt es genug zu zu lesen im Forum. Vom Prinzip her ist der ATxmega überhaupt nicht mit einem ATmega128 zu vergleichen.
@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.
Der interne RAM hängt an CLKPER, der externe an CLK2PER. CLK2PER kann halt 2x schneller als CLKPER sein.
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... :)
Hat mal einer die DFLL ausprobiert? Ist der Oszi danach genau? Und wie sieht es mit der Temperaturabhängigkeit aus?
Jau, Laut Datenblatt sind +/-1% Genauigkeit zu erreichen. Eine Temperaturabhängigkeit kann ich im Datenblatt aber nicht finden.
1 | /* Enable necessary Clock sources. 32MHz and 32kHz Oscillator */
|
2 | OSC.CTRL = OSC_RC32MEN_bm | OSC_RC32KEN_bm; |
3 | /* Wait for Oscillators to become stable */
|
4 | while(!(OSC.STATUS & OSC_RC32MRDY_bm)); |
5 | while(!(OSC.STATUS & OSC_RC32KRDY_bm)); |
6 | |
7 | /* Start Calibrating the 32MHz Clock using
|
8 | * the internal calibrated 32kHz Oscillator */
|
9 | OSC.DFLLCTRL = (0 << OSC_RC32MCREF_bp); |
10 | DFLLRC32M.CTRL = DFLL_ENABLE_bm; |
11 | /* Set as System Main Clock */
|
12 | CCP = CCP_IOREG_gc; |
13 | CLK.CTRL = CLK_SCLKSEL_RC32M_gc; |
Eine UART Verbindung klappt problemlos und bisher absolut ohne Fehler, was aber nicht unbedingt was heißen muss.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.