Hallo zusammen, gilt die Aussage von folgendem Artikel auch für die Xmegas von Atmel?! http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART "WICHTIGER HINWEIS 2 Auf Grund permanent wiederkehrender Nachfrage sei hier AUSDRÜCKLICH darauf hingewiesen, dass bei Verwendung des UART im asynchronen Modus dringend ein Quarz oder Ouarzoszillator verwendet werden sollte! Der interne RC-Oszillator der AVRs ist recht ungenau! Damit kann es in Ausnahmefällen funktionieren, muss es aber nicht! Auch ist der interne Oszillator temperaturempfindlich. Damit hat man dann den schönen Effekt, dass eine UART-Schaltung die im Winter noch funktionierte, im Sommer den Dienst verweigert. " Die xmega haben einen intern kalibrierten 2MHz bzw. 32MHz Oszillator! Siehe Datenblatt Xmega: "A DFLL can be enabled for automatic run-time calibration of the oscillator to compensate for temperature and voltage drift and optimize the oscillator accuracy." Ich schalte die DFLL ein und benötige nur 9600 Baud. Aktuell funktioniert es mit zwei Prototypen. Ob aber in der Serie?! Danke für Eure Meinungen! Michael
Funktioniert auch in der Serie. Der intern erzeugte Takt ist bei den Xmegas hinreichend stabil.
Hi Moby, vielen Dank für Deine Antwort :-)... @all: Allgemeiner Konsens?! VG, Michael
Hallo, ich kann Dir nur aus meiner Erfahrung mit einem Bussystem berichten, dass ich keine Probleme mit dem internen Oszillator des XMega und der USART (RS485) habe. Ich betreibe ein Steuerungssystem (ein Master und drei Slaves) mit 2MHz internem Takt und 9600 Baud, wobei der Busmaster über ein Graphikdisplay verfügt. Wenn die Graphik neu aufgebaut werden muss, schalte ich den internen Takt auf 32MHz um und konfiguriere gleichzeitig die Kommunikationsparameter neu. Am RS485-Bus habe ich zeitweise über einen FT232R auch einen PC hängen der den Datentransfer mitprotokolliert, ich habe bisher noch keine Fehlübertragung beobachtet. Auch mit 115200 Baud funktioniert das System einwandfrei. Durch die Möglichkeit des XMega die Konfigurationsparameter über BSCALE und BSEL sehr genau einzustellen, ergibt sich bei meinen getesteten Kombinationen aus CPU_Takt und Baudrate ein maximaler Fehler von 0,08%, da darf dann der Prozessortakt schon etwas ungenauer sein und die Kommunikation wird noch immer funktionieren (meine Meinung). Grüße, Robert.
MichaeL schrieb: > Aktuell > funktioniert es mit zwei Prototypen. Ob aber in der Serie?! Wie groß ist Deine Serie und wo werden die Teile eingesetzt? Wie sehr schwankt die Raumtemperatur? Wieviel Ärger gibt es, wenn es einmal mit der Baudrate nicht funktioniert? Persönlich würde ich immer einen Quarz einsetzen.
Ich hatte im Winter Probleme mit einem Xmega. Solange der Chip noch kalt war (ca 10°C) hatte ich am PC (über UART-Kabel) bis zu 20% falsche Zeichen empfangen. Nach einigen Minuten Betrieb wird es dann besser, wenn der Chip wärmer wird. Zum test habe ich mal einen Fön drauf gehalten, da fällt die serielle Kommunikation ruck zuck wieder aus. Mein Empfehlung: Auch bei Xmega ist UART Kommunikation mit R/C Oszillator nicht empfehlenswert. Für eine Debug-Ausgabe mag es reichen, mehr würde ich damit aber nicht machen.
Hallo @*, danke für Eure Antworten. Mmmmh die Antworten von m.n. und stefanus sind natürlich nicht so erfreulich. Habt Ihr das DFLL gesetzt? Michael
Bei einer überschlägigen Rechnung kommt man darauf, dass bei exaktem Sender der Empfänger 5% Toleranz bezüglich des Taktes zulässt. Lässt man für Sender UND Empfänger Toleranz zu, wird das zu 2,5%. Bei AVRs kann man mittels fuses die Frequenz auf einen Toleranzbereich von 1% bringen, also kann man die UART durchaus am internen Takt betreiben. Da aber sowohl Temperatur als auch Spannungsschwankungen als auch Bauteilealterung die Frequenz verbiegen, fühle ich mich wesentlich wohler, wenn die UART per Quarztakt betrieben wird. Der hat immer weniger als 0,1% Toleranz.
Mit der DFLL und der internen 32768 Hz Referenz ist der Takt für die CPU immer genauer als 1%, im Bereich von 0-85°C. Alte XMEGAs hatten da Probleme, die USB-Serie läuft sehr stabil und für UART völlig hinreichend. Noch stabiler geht´s mit Uhrenquarz am TOSC als Referenz für die DFLL.
Hab grad eine Serie mit dem XMega eingestampft, weil die Boards keinen Quarz drauf haben. Im Testaufbau hats zufällig mit dem internen Taktsystem funktioniert. Das interne Xmega Taktsystem ist schon um einiges besser als das der normalen Megas, aber ersetzt noch nicht 100% den externen Quarz! SG Choose
Choose schrieb: > Hab grad eine Serie mit dem XMega eingestampft, weil die Boards keinen > Quarz drauf haben. Im Testaufbau hats zufällig mit dem internen > Taktsystem funktioniert. Welchen XMEGA hast Du verwendet?
Choose schrieb: > Hab grad eine Serie mit dem XMega eingestampft, weil die Boards > keinen > Quarz drauf haben. Im Testaufbau hats zufällig mit dem internen > Taktsystem funktioniert. Das interne Xmega Taktsystem ist schon um > einiges besser als das der normalen Megas, aber ersetzt noch nicht 100% > den externen Quarz! > > SG Choose Welche Applikation? Wie konfiguriert? Vermutlich hatte das Einstampfen ganz andere Gründe als ein instabiler Takt...
Hallo zusammen, so jetzt mal ganz nüchter bzgl. dem intern kalibrierten Takt: Quelle Datenblatt: XMEGA A4U 8387D–AVR–02/2013 36.1.14.1Calibrated 32.768kHz Internal Oscillator characteristics Genauigkeit +-0,5% 36.1.14.3Calibrated and tunable 32MHz internal oscillator characteristics Factory calibration accuracy = +- 1,5% User calibration accuracy = +-0,2% DFLL calibration step size = 0,22% Bei "User Calibration accuracy" gehe ich davon aus, dass hiermit das DFLL Feature gemeint ist. Hierbei wird sowohl die Temperaturdrift als auch die Spannungsversorgungsdrift kompensiert. Wenn der uC hält was das Datenblatt verspricht (wovon man ausgehen muss)sollte der interne Takt bei weitem stabil genug sein. @m.n.: Temperaturbereich -20 bis 70°C / Schnelle Test mit Eisspray keine Auffälligkeiten. Spezifizierter Temperaturbereich -40 bis 85°C. @Choose: Hast Du das DFLL Feature aktiviert?! Michael
Bei den U Typen (die Bugfreieren), keine Probleme... ältere Typen habe ich nicht getestet... Steht auch aktuell was in der "elektronik" vom 11. Februar... wurde ja auf der embedded verteilt... der Artikel wurde aber von einem Ing. von Ineltek veröffentlicht... (die ja quasi Atmel vertreiben)... Zitat: "Neuere AVRs verfügen über einen Temperatursensor, der die Kalibrierung des RC-Oszillators im Register OSCCAL abhängig von der Temperatur mit 1-2% Abweichung ermöglicht, was für UARTs ausreicht. ATXMegas haben einen im kompletten Spannungs- und Temperaturbereich auf 1% kalibrierten 32-kHz-RC-Oszillator." Grüße Basti
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.