Kurze Zwischenfrage: Ich habe bei meinen bisherigen AVR - Spielerein noch nie einen Baudratenquarz eingesetzt, immer interner Oszillator oder externer 4 od. 8Mhz Quarz und hatte noch nie Probleme mit RS232 - Kommuniktion mit dem PC. Bin ich ein Glückspilz oder ist der Baudratenquarz für eine andere Art der seriellen Kommunikation gedacht?
Hallo, mit dem internen Oszillator ist es ein Glücksspiel, der kann beachtlich abweichen. Allerdings benutze ich den zum Debug durchaus auch, notfall ändere ich die F_CPU-Definition per Versuch & Irrtum. Bei üblichen Raumtemperaturen ist er dann durchaus stabil genug. Bei 4 und 8 MHz sind die gängigen Baudraten mit einer ausreichend kleinen Abweichung einzustellen, da gibt es dann kein Problem. Spätestens bei höheren Raten über 38400 wird der Fehler ohne Baudratenquarz einfach zu hoch. Liste dazu ist ja im AVR-Datenblatt zu finden. Gruß aus Berlin Michael
PCs sind meist recht fehlertolerant an der seriellen Schnittstelle, da passiert meist nix wenn man mit "glattem" Quarz oder gar interner Taktversorgung bastelt. Viel schwieriger wirds aber wenn man als Kommunikationspartner eben keinen PC hat sondern einen weiteren µC oder ein anderes Gerät mit serieller Schnittstelle. Für den schnellen Pfusch zwischendurch mit serieller Ausgabe am PC sind die Notlösungen also durchaus machbar aber wenn man was haben will das an jeder Schnittstelle funktioniert sollte man schon ordentlich designen. bye Frank
@ Gast (Gast) >Bin ich ein Glückspilz oder Quasi. > ist der Baudratenquarz für eine andere Art >der seriellen Kommunikation gedacht? Nöö, das ist schon RS232 und seine Verwandten (Midi, whatever). Siehe Baudragtenquarz MfG Falk P S Man KANN RS232 SICHER mit dem internen RC-Oszillator betreiben, wenn man a) den Oszillator kalibriert (per OSCCAL und Cal. Byte) b) den Oszillator kalibriert (per 32K Uhrenquarz und Timer) MfG Falk
@ Frank L. (hermastersvoice) >PCs sind meist recht fehlertolerant an der seriellen Schnittstelle, da >passiert meist nix wenn man mit "glattem" Quarz oder gar interner >Taktversorgung bastelt. Klar, was vor allem die vielen Threads mit "Hilfe, mein UART geht nicht" beweisen . . . >durchaus machbar aber wenn man was haben will das an jeder Schnittstelle >funktioniert sollte man schon ordentlich designen. Eben. MfG Falk
Es wäre schön, wenn Atmel bei der Takterzeugung der AVR-UARTs mal bei anderen Herstellern abgucken würde. Die benötigen keine "Baudratenquarze", und können trotzdem zuverlässige und ausreichend genaue Baudraten erzeugen - selbst bei äußerst niedrigen Quarztakten. Warum tut sich Atmel da so schwer?
Und wie machen die das? Aber was die Frage angeht: Baudratenquarze sind stinknormale Quarze. Lediglich schwingen die auf einer Frequenz, aus der man ohne Rundungsfehler den Schnittstellentakt ableiten kann :-> Mit dem internen RC kann man die Schnittstelle auch fahren. Kalibrieren sollte man den RC dann natürlich, aber sonderlich stabil auf Dauer ist das dann nicht unbedingt. Und den Temperaturdrift des RC sollte man auch berücksichtigen.
> Und wie machen die das? Sieh Dir beispielsweise die USCI im MSP430F54xx an. Oder die USART des deutlich älteren MSP430F16xx. Die brauchen übrigens auch keine "Fuses", mit denen die Taktquelle festgelegt werden muss (beliebter AVR-Fehler), sondern können dies zur Programmlaufzeit beliebig konfigurieren.
@ Rufus t. Firefly (rufus) (Moderator) Benutzerseite >Sieh Dir beispielsweise die USCI im MSP430F54xx an. Oder die USART des >deutlich älteren MSP430F16xx. Ist recht clever gemacht, muss man zugeben. Aber auch ein Baudratenquarz ist keine Hexerei. Einbauen, fertig. >Die brauchen übrigens auch keine "Fuses", mit denen die Taktquelle >festgelegt werden muss (beliebter AVR-Fehler), sondern können dies zur >Programmlaufzeit beliebig konfigurieren. Ist nur ein Problem für Anfänger, die Profis schreiben die Fuses richtig und gut. Das interessiert Atmel verständlicherweise nicht. Wäre mir auch egal. MFG Falk
> Ist nur ein Problem für Anfänger, die Profis schreiben die > Fuses richtig und gut. So kann man das natürlich auch darstellen. > Das interessiert Atmel verständlicherweise nicht. > Wäre mir auch egal. Und damit verschenkt man Möglichkeiten zum Stromsparen. Im "Standby"-Betrieb kann man einen MSP430 mit einem langsamen, intern erzeugten Takt versorgen (VLO); tritt ein externes Ereignis ein, und wird Rechenleistung benötigt, so kann mal eben schnell auf den HF-Quarz umgeschaltet werden, und vor dem "Schlafenlegen" wird wieder der langsame Oszillator verwendet. Wollen "Profis" keine stromsparenden Anwendungen realisieren?
Rufus t. Firefly schrieb: > Wollen "Profis" keine stromsparenden Anwendungen realisieren? Schon, aber Profis wissen, dass es dafür dann geeignetere Controller als AVR gibt grins Das richtige Werkzeug für das richtige Problem :-)
Seit xmega gibt es auch Taktquellenwechsel on the fly und außerdem einen Fractional Baud Rate Divider bei jeder der 8 UARTs die zum Beispiel der ATxmega128A1 hat. Da reicht auf jeden Fall die Interne Taktquelle+PLL bzw. DFLL. Bei den normalen Megas sollte man aufpassen, dass auch bei kalibriertem Oszillator man die Temperatur nicht zu sehr verändert (von der Temperatur beim kalibrieren).
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.