Ich habe eine Schaltung, bei der ein 8-bit Atmega (1284p) zum Einsatz kommt. Dieser empfängt über eine Serielle Schnittstelle Daten vom PC, allerdings ohne Handshake. Der intern freie RAM des AVR ist im Fall mehr als reichlich, um die gesamte Sendung (max. ca. 10KB) in einem Aufwasch zwischenzubunkern. Der AVR ist in C programmiert, ser. Datenempfang per Interrupt. Wie gesagt nur TxD, RxD, GND beschaltet. Bisher läuft der AVR mit einem 'Baudraten'-Quartz von 18,432 MHz. Hab aber das Gefühl, das ist der Overkill. Gibt es eine Faustformel, wieviel MHz man so einem AVR spendieren sollte, um serielle Daten mit einer bestimmten Baudrate ohne Handshake stabil zu empfangen? Nur mal als konkretes Beispiel 115 kbaud.
Michael schrieb: > Gibt es eine Faustformel, wieviel > MHz man so einem AVR spendieren sollte, um serielle Daten mit einer > bestimmten Baudrate ohne Handshake stabil zu empfangen? Da die UART der AVRs recht primitiv ist, braucht sie immer einen "Baudratenquarz", um nicht zu große Baudratenfehler zu erzeugen. Das ist unabhängig von der genutzten Baudrate. Was den Takt betrifft, mit dem der AVR selbst läuft: Das hängt von Deinen Programmierkünsten ab. Die Daten werden in einer ISR 'reinkommen, wenn die brauchbar programmiert ist, braucht man keinen irrwitzig schnell rennenden AVR. Wenn in der ISR aber zu viel passiert, was da besser nichts zu suchen hat (d.h. empfangene Daten bereits auswertena/aufbereiten, statt sie nur in ein Rx-Fifo zu stopfen), dann braucht man logischerweise mehr Rechenleistung. Bei 115200 Baud stehen pro empfangenem Byte (bei 8n1) etwa 86 µs zur Verfügung.
Harald K. schrieb: > Da die UART der AVRs recht primitiv ist, braucht sie immer einen > "Baudratenquarz", um nicht zu große Baudratenfehler zu erzeugen. Zigtausende von AVR Arduinos wissen das nicht, die laufen unbeeindruckt mit 8 oder 16MHz. Bei verschiedensten Baudraten. Wäre ganz nett wenn du denen das nicht mitteilst, denn sonst stellen sie sofort alle den Betrieb ein. Und das wollen wir doch nicht.
:
Bearbeitet durch User
https://www.mikrocontroller.net/articles/Baudratenquarz Die Taktfrequenz muss hoch genug, sein um die Daten schnell genug empfangen, verarbeiten und wieder ausgeben zu können. Sie darf aber nicht höher sein, als für die gegebene Betriebsspannung zugelassen ist (siehe Datenblatt).
Arduino F. schrieb: > Zigtausende von AVR Arduinos wissen das nicht, die laufen unbeeindruckt > mit 8 oder 16MHz. Bei verschiedensten Baudraten. In der Praxis machen wohl die paar wenigen Prozent Fehler nichts aus. Es wird ja eigentlich auch am Beginn jedes Bytes (Startbit) neu synchronisiert. Daher sollte das wirklich eigentlich kein Problem sein. Zumal es ja allgemein akzeptierte Praxis ist, bei den neuen AVRs (tiny0/1/2 und neuer) den UART mit internem RC-Oszillator zu nutzen, der ja auch ein paar Prozent Abweichung im Temperaturbereich haben kann.
Harald K. schrieb: > Da die UART der AVRs recht primitiv ist, braucht sie immer einen > "Baudratenquarz", um nicht zu große Baudratenfehler zu erzeugen. Das ist > unabhängig von der genutzten Baudrate. Wenn du geschrieben hättest: da die Baudrate der AVRs aus der Taktfrequenz über einen Teiler erzeugt wird, lässt sich nur mit einem Baudratenquarz eine 100% exakte Standardbaudrate erzielen. Ansonsten gibt es eine Abweichung, die je nach Baudrate und Einstellung in der Praxis tolerierbar ist, und deren Größe man im Datenblatt nachlesen kann. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > da die Baudrate der AVRs aus der Taktfrequenz über einen Teiler erzeugt > wird, lässt sich nur mit einem Baudratenquarz eine 100% exakte > Standardbaudrate erzielen. Gilt übrigens nur noch für die "alten" AVRs. Die "neuen" haben einen Fractional Baudrate Generator.
Johannes F. schrieb: > Arduino F. schrieb: >> Zigtausende von AVR Arduinos wissen das nicht, die laufen unbeeindruckt >> mit 8 oder 16MHz. Bei verschiedensten Baudraten. > > In der Praxis machen wohl die paar wenigen Prozent Fehler nichts aus. Die Arduinos haben zumindest einen Keramikresonator on board. Letztere haben eine Toleranz von 0,5 Prozent, was für UART-Anwendung völlig ausreichend ist. Dazu kommt noch der Fehler durch die ganzzahlige Teilung im Baudratengenerator. http://www.kreatives-chaos.com/artikel/baudraten-tabelle-fuer-avrs
Angehängte Dateien:
-
AVR-Baudrates.png
110 KB
Arduino F. schrieb: >> Da die UART der AVRs recht primitiv ist, braucht sie immer einen >> "Baudratenquarz", um nicht zu große Baudratenfehler zu erzeugen. > > Zigtausende von AVR Arduinos wissen das nicht, die laufen unbeeindruckt > mit 8 oder 16MHz. Bei verschiedensten Baudraten. Ja, niedrigen. Die höchste, "normale" Baudrate die damit möglich ist, ist 38400, wenn man es etwas exotischer mag auch 76.800. Die klassischen 115.200 sind NICHT möglich, denn der systematische Fehler durch den Bauratenteiler wäre. Ok, für 99% aller Anwendungen reicht das.
Michael schrieb: > Bisher läuft der AVR mit einem 'Baudraten'-Quartz von 18,432 MHz. Hab > aber das Gefühl, das ist der Overkill. Ja und? Das ist heute normal. Außerdem kannst du die CPU in den [[Sleep Mode]] schalten, wenn du Strom sparen musst. > Gibt es eine Faustformel, wieviel > MHz man so einem AVR spendieren sollte, um serielle Daten mit einer > bestimmten Baudrate ohne Handshake stabil zu empfangen? Nur mal als > konkretes Beispiel 115 kbaud. 115.200 Baud sind 11.5kB/s, sprich 86,8us/Byte, das die CPU abholen und mindestens speichern muss. Bei 1MHz CPU-Takt sind das 86 Takte. Nicht viel, reicht aber immerhin für ne kurze ISR. Bei 20 MHz sind es 1720 CPU-Takte, das ist tierisch viel. In den meisten Anwendungen wird man einen möglichst hohen Takt wählen, denn es gibt kein Geld zurück für ungenutzte CPU-Leistung. Siehe oben.
Arduino F. schrieb: > Zigtausende von AVR Arduinos wissen das nicht, die laufen unbeeindruckt > mit 8 oder 16MHz. Bei verschiedensten Baudraten. Mit entsprechenden Baudratenfehlern, was Du geflissentlich ignorierst.
Harald K. schrieb: > Da die UART der AVRs recht primitiv ist Datasheet ATtiny402: "23.3.3.2.5 Auto-Baud The auto-baud feature lets the USART configure its BAUD register based on input from a communication device, which allows the device to communicate autonomously with multiple devices communicating with different baud rates. The USART peripheral features two auto-baud modes: Generic Auto-Baud mode and LIN Constrained Auto-Baud mode. Both auto-baud modes must receive an auto-baud frame, as seen in the figure below."
Michael schrieb: > Gibt es eine Faustformel, wieviel > MHz man so einem AVR spendieren sollte, um serielle Daten mit einer > bestimmten Baudrate ohne Handshake stabil zu empfangen? Nur mal als > konkretes Beispiel 115 kbaud. Das kommt u.a. auch darauf an, womit sich dein AVR sonst noch so beschäftigt, d.h. ob er die Daten schnell genug aus dem USART abholen kann.
Falk B. schrieb: > Die klassischen > 115.200 sind NICHT möglich, Habe das mal für dich aus der boards.txt herausgesucht: uno.upload.speed=115200 unomini.upload.speed=115200 nano.menu.cpu.atmega328.upload.speed=115200 mega.menu.cpu.atmega2560.upload.speed=115200 Und noch ein paar weitere Irgendwas scheint mit deiner Behauptung nicht zu stimmen! Harald K. schrieb: > Mit entsprechenden Baudratenfehlern, was Du geflissentlich ignorierst. Nicht ich ignoriere das, sondern die UART stecken ein paar Prozent locker weg. Üblich sind 8n1, also 10 Bit pro Byte 10% Error wäre 1 Bit aus dem Takt. Darüber funktioniert es garantiert nicht mehr. 2-3% sind noch voll im sicheren Bereich 3 bis ca. 8% sind Wackelkandidaten. Es kommt natürlich auch auf den Partner an, dessen Error addiert sich darauf. Mit Glück gleicht sich das aus.
:
Bearbeitet durch User
Arduino F. schrieb: >> Mit entsprechenden Baudratenfehlern, was Du geflissentlich ignorierst. > Nicht ich ignoriere das, sondern die UART stecken ein paar Prozent > locker weg. Nö. Locker schon gar nicht. Es gibt ein Dokument, aka white paper von Maxim, dort wurde das mal vor Ewigkeiten lang und breit diskutiert. Ergebnis. 3% Fehler sind zwar prinzipiell machbar, es werden aber 1% oder weniger empfohlen. Bei Überabtastung mit Faktor 16 hat man schon mal 6,5% Jitter bei der Erkennung der Startflanke. Dazu kommen die akkumulierenden Fehler durch die leicht falsche Baudrate. > Üblich sind 8n1, also 10 Bit pro Byte > 10% Error wäre 1 Bit aus dem Takt. Darüber funktioniert es garantiert > nicht mehr. > 2-3% sind noch voll im sicheren Bereich Unter "voll im sicheren Bereich" verstehe ich was anderes. > 3 bis ca. 8% sind Wackelkandidaten. Murks. Erst recht im Zeitalter, wo passende Quarze für nen Appel & Ei verfügbar sind. > Es kommt natürlich auch auf den Partner an, dessen Error addiert sich > darauf. Mit Glück gleicht sich das aus. Ja klar, Glück ist ein seit Jahrhunderten bewährtes Ingeniersprinzip . . .
Johannes F. schrieb: > In der Praxis machen wohl die paar wenigen Prozent Fehler nichts aus. Doch, natürlich machen die was aus. Ich habe schon genug Bastelscheiß gesehen, der dann draussen bei Minusgraden keine Kommunikation mehr hinbekommen hat. Wieviel zusätzliche Abweichung pro K erfolgt, läßt sich dem Datenblatt entnehmen. Ist bei den "Classic"-AVRs i.A. mehr als bei den modernen. Und wenn schon durch ungünstigen Quarz und Ganzzahl-Teilung von vornherein eine recht große Abweichung in Richtung "zu schnell" als systematischer Fehler vorliegt, dann wird das natürlich umso eher passieren. > Es > wird ja eigentlich auch am Beginn jedes Bytes (Startbit) neu > synchronisiert. Daher sollte das wirklich eigentlich kein Problem sein. Doch, das kann durchaus ein Problem sein. Wenn nämlich z.B. der Sender etwas zu schnell sendet und die Bytes "dicht an dicht" kommen, also wirklich nur mit einem Stopbit, dann kann es durchaus passieren, dass der Empfänger sich verschluckt, weil er das Startbit des nächsten Bytes garnicht mitbekommen hat. Der sieht dann das erste High/Low im Payload als Begin eines Startbits. Je nach Inhalt der Kommunikation kann es sogar passieren, dass er die Wordsynchronisation ab dann dauerhaft verliert. Bis dann irgendwann mal eine hinreichend lange Pause mit Idle-Pegel kommt. Erst dann wird er wieder synchron. > Zumal es ja allgemein akzeptierte Praxis ist, bei den neuen AVRs > (tiny0/1/2 und neuer) den UART mit internem RC-Oszillator zu nutzen, der > ja auch ein paar Prozent Abweichung im Temperaturbereich haben kann. Aber eben deutlich weniger als die Classic-Teile. Außerdem kann man mit dem dort verfügbaren fraktionalen Prescaler dafür sorgen, dass auch der systematische Fehler geringer ist.
Ob S. schrieb: > Doch, das kann durchaus ein Problem sein. Wenn nämlich z.B. der Sender > etwas zu schnell sendet und die Bytes "dicht an dicht" kommen, also > wirklich nur mit einem Stopbit, dann kann es durchaus passieren, dass > der Empfänger sich verschluckt, [...] OK, danke für deine Erläuterungen. War mir so noch nicht bewusst. Ich selbst habe auch bisher bei "legacy"-AVRs immer Baudratenquarze verwendet, weil ich generell lieber auf der "sicheren Seite" bin. Ob nun 14,756 oder 16 MHz macht ja hinsichtlich Geschwindigkeit nicht den großen Unterschied, und Kosten sind dieselben. Daher ist es schon seltsam, dass Arduino keine Baudratenquarze verbaut.
:
Bearbeitet durch User
Noch was zum Thema AVR CPU-Leistung und hohe Baudraten. Ich hab mal vor Äonen einen DMX512 Player/Recorder gebaut, mit ATmega64 und externem 64kB SRAM und SD-Karte. Der konnte DMX512 mit voller Kapazität mit 250kBaud dauerhaft wiedergeben oder speichern, das macht immerhin ca. 22kB/s. Die mittlere CPU-Last lag bei ~30% @16MHz.
Hallo, man kann auch passende Ganzzahlteilbarebaudratenwerte verwenden. Dann hat man rechnerisch immer 0,000% Abweichung. Man kann locker 250kBaud oder 500kBaud mit 8 oder 16MHz verwenden. Es gibt keinen Grund krumme Baudraten zu verwenden. Außer die Gegenstelle verlangt das unbedingt. Meine klassischen Arduino Boards haben zum Glück mit 115200 Baudrate Uploadspeed keine Probleme bei Zimmertemperatur. Aber mein Arduino Nano ESP32 bricht öfters den Upload ab. Manchmal benötige ich 4 Versuche. Laut meines Wissens wird hierbei mit 921600 Baud geflasht. Müsste ich mich auch einmal damit näher befassen. Komischerweise zeigt mein XIAO ESP32 keinerlei solche Probleme, der wird definitiv mit 921600 Baud geflasht. Im allgemeinen sind krumme bzw. unpassende Baudraten schon kritisch. Ich meine man könnte auch mit sicheren 100kBaud bzw. beim ESP mit 1MBaud flashen. Warum überall krumme Werte verwendet werden erschließt sich mir ehrlich gesagt nicht. Früher ja, aber heutzutage gibt es keinen Grund dafür.
Johannes F. schrieb: > Ich selbst habe auch bisher bei "legacy"-AVRs immer Baudratenquarze > verwendet, weil ich generell lieber auf der "sicheren Seite" bin. Ob nun > 14,756 oder 16 MHz macht ja hinsichtlich Geschwindigkeit nicht den > großen Unterschied, und Kosten sind dieselben. Daher ist es schon > seltsam, dass Arduino keine Baudratenquarze verbaut. Man benötigt keine Baudratenquarze wenn man die Baudrate mit ganzzahligen Teiler passend wählt.
Hach, während ich meine alte Excel-Tabelle etwas schöner gemacht habe zur Kalkulation der Baudraten beim AVR (und als Kommentar gedacht gewesen), gibt es schon zig weitere Kommentare. Vor einiger Zeit wurde ich zu einem ähnlichen Thema satt verhauen, weil ich in Bezug auf die Baudrate da etwas für mich ungewöhnliches aufgetreten ist war: Verwende ich einen CH340G an einem AVR mit 16MHz und 115200 Baud, lief das trotz der Fehler immer problemlos. Betreibe ich die gleiche Controllerschaltung mit CH340N ... funktioniert das dummerweise nicht mehr (was sich mir nicht erschlossen hatte). Ungerechtfertigterweise gab ich dem CH340N die Schuld, der aber (natürlich wurde im Nachbarthread reflexartig als Schuld irgendwelche Abblockkondensatoren und falscher Aufbau etc. pp genannt) mit anderen Controllern als einem AVR problemlos funktioniert hat. Von daher kann wie in der von Falk gezeigten Tabelle eine Abweichung von den 2,08% wirklich schon reichen, dass es nicht mehr richtig läuft ... smile, auch wenn Millionen von Arduinos das nicht wissen und deshalb funktionieren. Excel-Tabelle im Anhang dient zum Spielen mit den Werten von Quarz und Baudrate
Soweit mir bekannt ist unterstützen die meisten seriellen Schnittstellen ICs neben den klassischen Baudraten auch 250.000, 500.000 und 1.000.000 Baud, was sich sehr gut mit den üblichen 4, 8 und 16 MHz Quarzen verträgt. War Arduino da abzieht gefällt mir nicht, und ich hatte auch schon mal Probleme mit dem "neuen" 115200 Baud.
:
Bearbeitet durch User
Veit D. schrieb: > Man benötigt keine Baudratenquarze wenn man die Baudrate mit > ganzzahligen Teiler passend wählt. Ja, natürlich. Aber diese historisch gewachsenen 115200 oder 230400 Baud bspw. sind halt Standard und oft voreingestellt (siehe STK500 und avrdude), und manche Programme können auch nur diese und nicht glatte Baudraten.
Veit D. schrieb: > 14,756 oder 16 MHz macht ja hinsichtlich Geschwindigkeit nicht den >> großen Unterschied ... es macht aber einen großen Unterschied, wenn du aus dem Coretakt noch eine "relativ" genaue Zeitbasis von sagen wir: Eine Sekunde? ableiten willst. Das ist mit 16MHz gar kein Problem und dann bastelt man sich noch etwas wie aus einem Artikel zur "genauen Sekunde" zusammen und dann geht da auch eine Zeitbasis. Hast du einen 14,756 MHz Quarz wirst du damit Schwierigkeiten bekommen, die kleiner sind als die Schwierigkeiten eine Baudrate mit 16 MHz hinzubekommen.
Hier ist ein AVR Baudraten-Rechner (JavaScript): http://www.gjlay.de/helferlein/avr-uart-rechner.html Wenn man z.B: aus "16 MHz" clickt, werden Baudraten Einstellungen und Fehler in % angezeigt. Beispiel: 16 MHz Takt, 76.8 kBaud => Error = 0.2%, sollte also gut genug sein. (Baudraten-Fehler <= 0.2% werden in fett angezeigt). Zusätzlich zum angezeigter Fehler muss noch der Fehler von der Takterzeugung betrachtet werden.
Nemopuk schrieb: > War Arduino da abzieht gefällt mir nicht, und ich hatte auch schon mal > Probleme mit dem "neuen" 115200 Baud. das "zieht" nicht nur Arduino so ab! Schau dir mal Gerät an, was die an Baudraten anbieten: genau immer diegleichen Geschwindigkeiten, angefangen von 300 Bd und einer jeweiligen Verdopplung auf bis 38400 Bd, dann gab es (waren Modemzeiten) einen irgendwie "merkwürdig" gearteten Sprung auf 57600 Bd und jede höhere Baudrate ist dann hiervon eine Verdopplung. Schau dir einfach Kommunikationsprogramme an, was du dort einstellen kannst, dann sind es genau diese Baudraten. Hälst du dich nicht daran (an die "krummen" Baudraten) schließt du schon einen eventuellen Kundenkreis aus.
Veit D. schrieb: > Es gibt keinen Grund krumme Baudraten zu verwenden. Außer die > Gegenstelle verlangt das unbedingt. Ganz genau. Also gibt es sehr oft genau diesen Grund.
..und kleinere Baud-Rate bedeutet nicht kleineren Fehler. Beispiel: 16MHz, 76.8 kBaud => Fehler = 0.2% 16MHz, 57.6 kBaud => Fehler = 0.8% oder größer (abhängig von U2X).
Ralph S. schrieb: > ... es macht aber einen großen Unterschied, wenn du aus dem Coretakt > noch eine "relativ" genaue Zeitbasis von sagen wir: Eine Sekunde? > ableiten willst. Das ist mit 16MHz gar kein Problem Und dank CTC-Modus-Timer ist das doch aber bei 14,7456 etc. genausowenig ein Problem? 14.745.600 = 900 * 2^14.
Ob S. schrieb: > Veit D. schrieb: >> Es gibt keinen Grund krumme Baudraten zu verwenden. Außer die >> Gegenstelle verlangt das unbedingt. > Ganz genau. Also gibt es sehr oft genau diesen Grund. ACK. Zum Beispiel der überaus beliebte CH340 erlaubt nur die traditionellen Baudraten, nicht jedoch "glatte" wie 125k oder 250k: "CH340 supports common communication baud rates: 50, 75, 100, 110, 134.5, 150, 300, 600, 900, 1200, 1800, 2400, 3600, 4800, 9600, 14400, 19200, 28800, 33600, 38400, 56000, 57600, 76800, 115200, 128000, 153600, 230400, 460800, 921600, 1500000, 2000000." CH340 Datasheet, V3C, p. 7 Nachtrag: 128.000 Bd wären eine Option bei 16 MHz, sehe ich gerade.
:
Bearbeitet durch User
Zum CH340/341 ist diese Seite hilfreich: https://github.com/nospam2000/ch341-baudrate-calculation 12 Mhz 8 3 ergibt 500.000 Baud
Ralph S. schrieb: > ... es macht aber einen großen Unterschied, wenn du aus dem Coretakt > noch eine "relativ" genaue Zeitbasis von sagen wir: Eine Sekunde? > ableiten willst. Nein. Die Baudratenquarze enthalten zwar auch andere Primfaktoren als 2^n und 5^n, diese aber nur in homöopathischen Dosen. Deswegen ist es überhaupt kein Problem, einen Sekundentakt daraus abzuleiten. Auch 100ms oder 10ms sind kein Problem. Erst bei 1ms fangen die Probleme an. Wenn du das mit den Primfaktoren nicht begreifst, kannst du das nicht den Baudratenquarzen anlasten...
Nemopuk schrieb: > Zum CH340/341 ist diese Seite hilfreich: > https://github.com/nospam2000/ch341-baudrate-calculation > > 12 Mhz : 8 : 3 ergibt 500.000 Baud [Schrägstriche durch Doppelpunkte ersetzt --jofe] Naja, das ist irgendwelches Gebastel, das bei aktuellen Treibern wohl auch nicht mehr funktioniert.
Ich wiederhole nochmal, weil die Formel in manchen Browsern falsch dargestellt wird: Zum CH340/341 ist diese Seite hilfreich: https://github.com/nospam2000/ch341-baudrate-calculation
1 | 12 Mhz / 8 / 3 ergibt 500.000 Baud |
Johannes F. schrieb: > das bei aktuellen Treibern wohl auch nicht mehr funktioniert. Habe es gerade mit einem alten Arduino Nano Klon mit CH340 getestet - geht (immer noch) einwandfrei. Warum auch nicht? Solche "abweichenden" Baudraten werden von Windows und Linux schon sehr lange unterstützt (wenn die Hardware es kann). Blöd ist nur, dass man sie in manchen Programmen nicht einstellen kann. Bei Cutecom und Hterm geht es jedenfalls. Im "Serial Monitor" von Arduino leider nicht.
:
Bearbeitet durch User
Ralph S. schrieb: > Veit D. schrieb: >> 14,756 oder 16 MHz macht ja hinsichtlich Geschwindigkeit nicht den >>> großen Unterschied > > ... es macht aber einen großen Unterschied, wenn du aus dem Coretakt > noch eine "relativ" genaue Zeitbasis von sagen wir: Eine Sekunde? > ableiten willst. Das ist mit 16MHz gar kein Problem und dann bastelt man > sich noch etwas wie aus einem Artikel zur "genauen Sekunde" zusammen und > dann geht da auch eine Zeitbasis. > > Hast du einen 14,756 MHz Quarz wirst du damit Schwierigkeiten bekommen, > die kleiner sind als die Schwierigkeiten eine Baudrate mit 16 MHz > hinzubekommen. Diese Zitatzeilen habe ich nie und nimmer geschrieben! Ich erbitte mir mehr Sorgfalt.
Nemopuk schrieb: > Johannes F. schrieb: >> das bei aktuellen Treibern wohl auch nicht mehr funktioniert. > > Habe es gerade mit einem alten Arduino Nano Klon mit CH340 getestet - > geht (immer noch) einwandfrei. > > Warum auch nicht? Steht in der von dir verlinkten Seite als Überschrift: "With the new driver my application no longer works" Scheinbar nicht mehr aktuell. Habe es nicht selbst getestet.
Für MIDI brauchte man auch eine spezielle Baudrate, die in der normalen Liste nicht drin steht. Das war damals mein erster Kontakt zu "custom" Baudraten. Ich glaube, da war Windows 98 aktuell.
Ob S. schrieb: > Veit D. schrieb: > >> Es gibt keinen Grund krumme Baudraten zu verwenden. Außer die >> Gegenstelle verlangt das unbedingt. > > Ganz genau. Also gibt es sehr oft genau diesen Grund. Gut. Dann muss ich eine ganz allgemeine Gegenfrage stellen. Warum sind dann auf allen möglichen und unmöglichen Controllerboard keine Baudratenquarze verbaut? Warum sind überall Quarze mit Komma Null verbaut? Wenn Baudratenquarze das Allheilmittel sind, warum sind die dann so selten?
Veit D. schrieb: > Warum sind überall Quarze mit Komma Null > verbaut? Wenn Baudratenquarze das Allheilmittel sind, warum sind die > dann so selten? Vermutlich weil die zugehörigen Chips einen UART mit Fractional Baudrate Generator an Bord haben. Dann ist die Taktfrequenz vollkommen egal und es kann jede Baudrate (bis zu einem Maximalwert natürlich) mit vernachlässigbarem Fehler realisiert werden. Im Gegensatz zu den "legacy" AVRs mit dem primitiven UART, der einfach nur den CPU-Takt durch einen festen Teiler dividiert.
:
Bearbeitet durch User
Veit D. schrieb: > Gut. Dann muss ich eine ganz allgemeine Gegenfrage stellen. Warum sind > dann auf allen möglichen und unmöglichen Controllerboard keine > Baudratenquarze verbaut? Weil halt heute UART-Kommunikation nach Meinung vieler Idoten keine Rolle mehr spielt. Das Wintel-Kartell hat das ja schon im letzten Jahrhundert so verkündet. Nun, es ist bekannt, dass das eine völlige Fehleinschätzung war. Auch heute gibt es noch PC-Boards mit klassischer UART-Funktionalität. Und die gibt es nicht deshalb, weil das niemand mehr braucht. Was die aktuellen Controllerboards betrifft, ist es halt so, dass die moderne UARTs enthalte, die dank fraktionaler Teiler (ggf. in Kombination mit PLL) aus jedem beliebigen Takt hinreichend genau auch die klassischen UART-Bitraten generieren können. Probleme gibt es eigentlich nur im Universum der Dummen, also Arduino. Und da auch nur speziell bei Arduino auf Classic-AVR als Target. Und es war halt einfach ein Fehldesign des Arduino-Scheiß, nicht auf Baudrate-Quarze zu setzen. Hätten die das von Anfang an getan, würde sehr wahrscheinlich deine Frage heute lauten: Warum macht das nicht jeder so? ...
Hallo, dann verstehe ich die Diskussion nicht mehr worum es eigentlich geht. Wenn es alles kein Problem darstellt.
Veit D. schrieb: > Hallo, > > dann verstehe ich die Diskussion nicht mehr worum es eigentlich geht. > Wenn es alles kein Problem darstellt. Es stellt ein Problem dar für Arduino mit Classic-AVR8-Target. Und viele, mit Intelligenz nicht gerade gesegnete, benutzen halt genau das.
Bei der kleinst möglichen CPU-Frequenz hast Du je Byte 80 Zyklen, um den Interrupt zu behandeln, das ist auch in C bequem zu schaffen. Außerdem werden bis zu 3 Bytes gepuffert. Du brauchst also nur am Ende das Flag zu testen und gewinnst damit die Zeit für Prolog und Epilog, sowie andere Interrupts. D.h. Du hast 240 Zyklen für je 3 Byte in den FIFO zu schreiben. Da muß man sich schon extrem ungeschickt anstellen, um Bytes zu verlieren.
:
Bearbeitet durch User
Michael schrieb: > Der intern freie RAM des AVR ist im Fall mehr > als reichlich, um die gesamte Sendung (max. ca. 10KB) in einem Aufwasch > zwischenzubunkern. Nach den 10kB braucht der Sender also nur auf eine Quittung zu warten, ehe er die nächsten 10kB rausrotzt und alles ist in Butter.
Ob S. schrieb: > Doch, das kann durchaus ein Problem sein. Wenn nämlich z.B. der Sender > etwas zu schnell sendet und die Bytes "dicht an dicht" kommen, also > wirklich nur mit einem Stopbit, dann kann es durchaus passieren, dass > der Empfänger sich verschluckt, weil er das Startbit des nächsten Bytes > garnicht mitbekommen hat. Das ist natürlich so. Wenn man serielles Highspeed-Streaming über eine AVR-Uart implementieren will, ist ein Baudratenquarz sicher keine schlechte Idee. Für andere Anwendungen brauchts das nicht unbedingt. Oliver
Veit D. schrieb: > Warum sind > dann auf allen möglichen und unmöglichen Controllerboard keine > Baudratenquarze verbaut? Bei früheren 8051 Boards waren 11,0592MHz Quarze üblich und auch leicht zu beschaffen. Auch die 14,7456MHz Quarze für die 16MHz Typen waren Standard. Vermutlich ist bei den Arduino das Wissen einfach nur verloren gegangen.
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.