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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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."
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.
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!
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.
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 . . .
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.
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.
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.
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.
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.
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.
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.
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.
... 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.
... 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...
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.
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.
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.
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?
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.
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? ...
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.
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.
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.
Und dank CTC-Modus-Timer ist das doch aber bei 14,7456 etc. genausowenig
ein Problem? 14.745.600 = 900 * 2^14.
stimmt... 14.7456 hatte ich nicht auf dem Schirm.. von daher: gut!
Und obwohl ich fast nichts mehr mit AVR mache, werde ich mir bei der nächsten Bestellung diesen mitbestellen, einfach um dann auch noch den Opti-Bootloader an den Quarz anzupassen.
daran erinnere ich mich noch mehr als nur gut, aber dass die schwierig zu beschaffen waren habe ich nicht mehr in Erinnerung.
:-) die 11,0592 MHz "ärgern" mich eher in soweit, dass ich von denen noch habe und in einer meiner "Sammelsuriumkisten" wenn ich einen Quarz suche, fällt mir bestimmt dieser als erster in die Hände. Irgendwann sollte ich meinen Schlamperladen sortieren!
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 (...)
Handshake kann man auf unterschiedliche Weise realisieren – früher waren es richtige Leitungen, heutzutage macht man das in der Regel in Software – z.B. als spezielle, in ASCII geschriebene Kommunikationsbefehle als Bestätigung für die Gegenseite, dass dies und jenes gut angekommen ist oder halt auch nicht angekommen. Man kann aber auch für ein langes, durchgehendes Binärdatenpaket ein Quasi-Handshake machen, indem man einen Timeoutmechanismus einbaut (auch in Software geschrieben). Werden beispielsweise 511 von 512 erwarteten Datenbytes empfangen oder generell nicht alle Bytes empfangen und es kommt in den nächsten 500ms nichts mehr an, kann man in der Programmabarbeitung von einem Fehler ausgehen – den Fehler muss oder sollte man dann irgendwie sinnvoll behandeln, z.B. das Paket verwerfen oder die Gegenseite bitten, es vollständig oder nur den letzten, kleinen Teil neuzusenden. Man kann auch den Gebrauch von diversen Prüfsummenalgorithmen erwägen, auch vom einfachen Aufaddieren zu einer 16- oder 32-Bit-Zahl oder das Handshake generell sehr rudimentär bzw. simpel gestalten – so ganz ohne jegliches Handshake zu kommunizieren ist eigentlich fahrlässig – wird aber gerne nicht nur von Arduinojüngern, sondern auch von Quasi-Profis oder Möchtegerne-Profis gemacht, dann auch oft mit der Begründung als Selbstbetrug: funktioniert, also passt schon, wird schon gutgehen etc. Meistens funktioniert es auch, aber halt nicht immer und genau das ist der Unterschied zwischen einem guten Konzept/Entwurf und einem schlampigen, dessen Funktion größtenteils auf Zufällen und günstigen Umständen basiert.
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.
Ja, die Wahl des Quarzes für die UART-Schnittstelle eines ATMEGA1284 ist sehr gut, weil sie bei den Standardbaudraten in der Regel zu einer 0,0%-Fehlerrate führt (Datenblattauszüge als Anhänge) – die Abweichung des Quarzes selbst ist vernachlässigbar oder nicht der Rede wert. Das mit diesen 18,432MHz würde ich allerdings nur bei 5V machen, bei 3.3V nehme ich grundsätzlich 11,0592MHz, um nicht wiederum z.B. das Lesen des Programmcodes aus dem Flash dem Zufall zu überlassen (Anhang). Eine Sekunde für das Programm kann man aus diesen Quarzen (11,0592 und 18,432MHz) auch sehr gut durch Teilen ableiten – wer hier Teilungsprobleme sieht, der hat sich damit noch nicht ausreichend beschäftigt.
Bei den neueren AVR-Familien oder STM32 mit fraktionalem Baudratengenerator ist das alles mit dem Baudratenfehler ziemlich unkritisch – hier muss man keine Akrobatik mit den Quarzen vollführen. Die internen RC-Oszillatoren sind sehr gut fabrikkalibriert und bei den meisten hatte ich bisher nur welche, die deutlich unter 1%-Fehler bei Raumtemperatur lagen, die RCs würde ich aber nur für Testzwecke und zum Prototypen mit einer UART-Kommunikation benutzen, was ich auch tue; bei der finalen Version würde ich immer zu einer stabilen Taktquelle (externer Quarz oder Oszillator) greifen.
Arduino hat von Anfang an seine UART-Karten auf Zufall gesetzt – bei den Baudraten unter 115200 war der Baudratenfehler in der Anfangszeit noch relativ gering, als man dann aber mit 115200 Baud auf modern machen wollte und entsprechend umgestellt hat, wurde es mit dem 2.1- bzw. 3,5%-Fehler quasi exorbitant katastrophal, aber viele Arduino-Fanboys wissen das gar nicht, weil sie sich mit ihren µControllern und deren Datenblättern gar nicht richtig beschäftigen wollen. Kommt es dann auf der Gegenseite auch noch zu einem kleinen Fehler und sich das zufällig aufaddiert, ist man geliefert, manchmal hebt sich der Fehler aber auch etwas auf und man meint irrtümlich, in Sicherheit zu sein, weil es in diesem Fall mit diesen zwei Platinen funktioniert. Es geschieht ihnen recht – für so ein ignorantes Verhalten sehe ich keinen Spielraum für Mitleid meinerseits. Viele verteidigen auch noch vehement die Arduino-UART-Politik – nun ja, das erinnert irgendwie ein wenig an das Stockholm-Syndrom. Bei 250, 500 kBit und 1 MBit wäre man bei 16MHz entsprechend wieder fehlerfrei, das ist aber schon ziemlich schnell für eine einfache UART-Kommunikation bzw. diese UART-Prescaler-Einstellung den Jüngern gar nicht so klar, weil sie durch ihre Datenblattphobie gar nicht an diese Informationen gelangen können.
Jetzt ist langsam mal genug vom Arduino Bashing. Diese "Dummköpfe" haben es immerhin weiter gebracht, als alle Meckerfritzen hier zusammen. Irgendwas ist immer suboptimal, auch in euren Werken.
Die empfohlenen maximalen Abweichungen der Taktfrequenz gehen vermutlich von einer seriellen Kommunikation durch ein langes Kabel aus, und daß die Gegenseite maximal in die entgegen gesetzte Richtung abweicht.
Aus dem Bauch heraus schätze ich, dass auf Modulen mit USB-UART insgesamt bis zu 9% Abweichung noch funktionieren können (incl. Keramik Resonator). Ich denke, diesen Umstand nutzt Arduino aus, gepaart mit Mut zur Lücke.
Der Georg hat mit Absicht die Temperatur genannt. Der R/C Oszillator ist ab Werk für 3,3V und Zimmertemperatur kalibriert. Und er ist deutlich temperaturabhängig, daraus macht der Hersteller kein Geheimnis.
Leute, Georg M. möchte scheinbar bewusst Verwirrung stiften. Er ignoriert alle Hinweise das seine Kommentare hier im Thread nicht zum Thema passen. Sein ATtiny402 ist nicht mit einem ATmega1284P u.ä. vergleichbar. Der ATtiny402 stammt aus der neueren tinyAVR-0 Serie mit allen Features drum und dran. Mich wundert es nicht das es mit dem Teil funktioniert.
Die empfohlenen maximalen Abweichungen der Taktfrequenz gehen vermutlich
von einer seriellen Kommunikation durch ein langes Kabel aus, und daß
die Gegenseite maximal in die entgegen gesetzte Richtung abweicht.
Ein langes Kabel verändert nicht die Frequenz, bestenfalls die Flankensteilheit oder das Augendiagramm.
Aus dem Bauch heraus schätze ich, dass auf Modulen mit USB-UART
insgesamt bis zu 9% Abweichung noch funktionieren können
Ein langes Kabel verändert nicht die Frequenz, bestenfalls die
Flankensteilheit oder das Augendiagramm.
Korrekt. Es beeinträchtigt damit allerdings die Erkennung des optimalen Zeitpunktes zum Sampeln der Bits.
Ich muss meine 9% auf die Hälfte korrigieren (4,5%). Ich hatte nicht berücksichtigt, daß zwischen der Abtastung in der Mitte des Bits nur die hälfte der Zeit bis zum nächsten Bitwechsel vergeht.
Also ich denke, dass die Summe aller Abweichungen bis zu 4,5% betragen darf, wenn USB-UART und AVR direkt nebeneinander sitzen.
Immer noch falsch. Und mit "denken" hat dein Verhalten rein gar nichts
zu tun. Du meinst nur. Aber das ist ja modern.
Bei 9 Bits (incl. Stopbit) summieren sich die 4,5% Fehlzeiten zu 40,5% auf. Das Stopbit wird also 40,5% später oder früher abgetastet, als zum idealen Zeitpunkt in seiner Mitte. Damit wird das Stopbit immer noch korrekt erfasst.
Du siehst das offenbar anders. Wäre nett, wenn du es begründen würdest, anstatt persönlich zu werden.
Würde ein Handshake überhaupt gegen eine zu ungenaue UART-Frequenz helfen?
So wie ich das verstehe, dient ein Handshake dazu, dass ein langsamer Empfänger einen Sender brensen kann. Zum Beispiel wenn die Empfangs-FIFO des Empfängers zu kein ist um eine komplette Nachricht zu halten.
Gegen eine inexakte UART-Frequenz hilft ein Handshake doch überhaupt nicht?
Im Labor bei Sonnenschein und 22,5°C. In der realen Welt hat man damit
NULL Toleranz gegen Störungen.
Deswegen schrieb ich vom Mut zu Lücke und ohne Kabel.
Der Baudratengenerator vom Arduino Uno/Nano weicht rechnerisch "nur" 2,1% ab. Die originalen Module verwenden einen Quarz. Ich sehe da keinen Grund, die Entwickler des Boardes dermaßen zu beschimpfen, wie es oben getan wurde.
Der Baudratengenerator vom Arduino Uno/Nano weicht rechnerisch "nur"
2,1% ab.
Ja. Genauer: 2,08%.
Mit 14,7456MHz-Quarz wären es 0,00%.
Man muss kein Genie sein, um zu erkennen, dass damit für den Peer der Kommunikation 2,08% mehr Reserven für seinerseitige Abweichungen zur Verfügung stehen würden...
Es ist immer eine gute Idee für einen Ingenieur, vermeidbare systematische Fehler eben einfach zu vermeiden. Insbesondere hier: ein 14,7456MHz-Quarz kostet ziemlich genau so viel wie ein 16MHz-Quarz.
Angesichts der Tatsache, dass die UART-Kommunikation für Arduino sogar eine ganz besondere Rolle spielt (nämlich als standardmäßige Schnittstelle zum Programmieren und für's "Debugging") war es eindeutig eine krasse Fehlentscheidung.
Der einzige Grund, der mir einfällt, sich doch für die 16MHz zu entscheiden, ist die Problematik des 1ms-Systemticks. Der läßt sich halt aus 14,7456MHz nicht exakt ableiten, zumindest Jitter und einen nicht ganz unerheblichen Verbrauch von Resourcen müßte man dafür in Kauf nehmen.
Aber da haben die Arduino-Leute so viele neue hippe Begriffe erfunden, da wäre es auf noch einen mehr auch nicht mehr angekommen. Hätte man also einfach einen 10ms-Tick verwendet und den meinetwegen "Diffie" genannt, wäre alles gut gewesen. Die einzige Auswirkung wäre gewesen, dass es halt statt millis() dann eine Funktion diffies() gegeben hätte...
Das muß man nicht schätzen, sondern kann man ganz leicht ausrechnen.
Auch gibt es mehrere App-Notes, wo das beschrieben ist.
Schon das Startbit wird mit einem Fehler von 1/16 Bitzeit abgetastet. Das Stopbit (10. Bit) sollte danach an allen 3 Abtastzeitpunkten (8, 9, 10. Bitzeit) immer noch high sein. Erst ab der 11. Bitzeit ist die Startlogik wieder bereit zur Erkennung der Flanke. Ansonsten geht das Startbit verloren.
Kritisch ist also, wenn der Sender schneller ist. Daher lassen sich viele UARTs auf 1,5 oder 2 Stoppbits einstellen.
Dazu kommen als Fehlerquellen noch die Verzögerungen der RS-232 Treiber und durch Kabelkapazitäten.
Ist auf der Gegenseite keine echte UART, sondern ein USB-RS232 Adapter, kommt noch der Jitter durch den fraktionalen Teiler hinzu (12MHz USB-Quarz).
Deine geratenen 4,5% sind also weit weg von fehlerfreier Übertragung.
Ich hab das mal getestet, ab etwa 2% Abweichung ist eine Zunahme der Übertragungsfehler festzustellen. Ein Rechenfehler <1% sollte daher angestrebt werden.
Angesichts der Tatsache, dass die UART-Kommunikation für Arduino sogar
eine ganz besondere Rolle spielt (nämlich als standardmäßige
Schnittstelle zum Programmieren und für's "Debugging") war es eindeutig
eine krasse Fehlentscheidung.
Nun ja....
Für eine krasse Fehlentscheidung funktioniert es recht prächtig.
Viele Arduinos haben einen ATMega16U2 oder 8U2 als Schnittstellenbaustein.
Bei denen ist die Abweichung zwischen den Partnern nur von der Quarz/Resonator eigenen Abweichung abhängig, also ca 0,x%
Original Nanos haben einen FTDI on Board. Auch mit denen treten keine Probleme auf.
Nachbauten mit CH340 haben öfter Probleme mit Win Treibern, auch scheint es gefälschte CH340 zu geben. Aber wenn das Problem gelöst ist, tuen es auch die!
Der einzige Grund, der mir einfällt, sich doch für die 16MHz zu
entscheiden, ist die Problematik des 1ms-Systemticks. Der lässt sich halt
aus 14,7456MHz nicht exakt ableiten, zumindest Jitter und einen nicht
ganz unerheblichen Verbrauch von Resourcen müßte man dafür in Kauf
nehmen.
Hier zeigt sich deine eingeschränkte Kenntnis der Arduino Welt!
Die Arduino 1 Milli ist nicht 1ms lang, sondern unter 16MHz ist die Timer Tick Frequenz 998Hz.
Es werden nach Bedarf, ich nenne sie mal Schaltmillis, eingefügt.
Der Grund ist einfach, ein Kompromiss.
Timer0 macht einen Overflow Interrupt für die Millisberechnung, und zusätzlich können dessen 2 PWM Kanäle genutzt werden.
Das muß man nicht schätzen, sondern kann man ganz leicht ausrechnen.
Wenn du in dem Datenblatt, von wo du das angehängte Bild hast, noch
etwas weiterscrollst, findest du sogar die Formeln fertig ausgerechnet
sowie Tabellen mit den Ergebnissen.
Allerdings haben sich dort zwei Fehler eingeschlichen:
In der Formel für R_slow sollte entweder die -1 wegfallen oder S_F
durch S_M ersetzt werden (was auf dasselbe hinausläuft). Letztendlich
muss der Nenner um 1 kleiner als in der Formel für R_fast sein.
Außerdem sollte in Tabelle 53 in der Zeile für D=8 und der Spalte "Max
Total Error (%)" 100-95.36=-4.64 statt-4.54 stehen. Da aber schon der
Wert 95.36 wegen der fehlerhaften Formel nicht stimmt, spielt das keine
große Rolle ;-)
Bei 8N1 im Normal Speed Mode und guter Signalqualität werden also bei
einer Abweichung der Baudrate der empfangenen Daten von -5,26% oder
+4,57% gegenüber der realen Baudrate des AVR die Daten gerade noch
fehlerfrei übertragen. Da beim Arduino die Abweichung von ca. -2% noch
sehr gut in diesem Bereich liegt und auch die Signalqualität bei einer
Leitungslänge von wenigen Zentimetern recht gut dürfte, sollten hier
tatsächlich keine Probleme zu erwarten sein.
Die ±2% entsprechen auch der Empfehlung von Atmel/Microchip.
Der einzige Grund, der mir einfällt, sich doch für die 16MHz zu
entscheiden, ist die Problematik des 1ms-Systemticks. Der lässt sich halt
aus 14,7456MHz nicht exakt ableiten, zumindest Jitter und einen nicht
ganz unerheblichen Verbrauch von Resourcen müßte man dafür in Kauf
nehmen.
Hier zeigt sich deine eingeschränkte Kenntnis der Arduino Welt!
Die Arduino 1 Milli ist nicht 1ms lang, sondern unter 16MHz ist die
Timer Tick Frequenz 998Hz.
Woher soll das ein gewöhnlicher Arduino-User (also einer, der kein
ausgefuchster Fanboy ist) wissen? In der Doku wird das jedenfalls
verschwiegen:
Wenn du in dem Datenblatt, von wo du das angehängte Bild hast, noch
etwas weiterscrollst, findest du sogar die Formeln fertig ausgerechnet
sowie Tabellen mit den Ergebnissen.
[...]
Die ±2% entsprechen auch der Empfehlung von Atmel/Microchip.
Aber die reale Situation beim Classic-AVR8-Arduino liegt ja bereits über dieser optimistischen Empfehlung (die halt voraus setzt, dass auch der Peer sich daran halt).
Woher soll das ein gewöhnlicher Arduino-User (also einer, der kein
ausgefuchster Fanboy ist) wissen?
Ob S. (Firma: 1984now) (observer)ist offensichtlich kein gewöhnlicher Arduino User sondern eher ein Arduino Basher.
Und nicht der einzige hier.
Die Doku ist eher allgemeiner Natur. Bezieht sich nicht ausschließlich auf AVR sondern betrifft auch diverse ARM und was es sonst noch so geben mag.
Ansonsten: Ich bin nicht für die Doku verantwortlich.
Korrekturen und Verbesserungsvorschläge bitte an das Arduino Team melden.
Dann:
Der Arduino AVR Core, bzw. die Boarddefinitionen liegen öffentlich bei github aus und sind im Quellcode auf jedem Rechner mit Arduino IDE, welcher das AVR Paket geladen hat.
Somit hat auch jeder die Chance sich kundig zu machen.
Schlussendlich:
Keine Ahnung von dem Kram zu haben, ist kein Freibrief für Arduino Bashing.
Somit hat auch jeder die Chance sich kundig zu machen.
Dazu ist die klassische Arduino-Zielgruppe gar nicht in der Lage. Und ich kann mir nicht vorstellen das selbst du zumindest den Kern der Arduino-Quellen auf solche "Besonderheiten" hin analysiert hast.
Hier zeigt sich deine eingeschränkte Kenntnis der Arduino Welt!
Da bin ich überaus stolz drauf. Früh erkannt, dass das Rotz ist und nur minimal Lebenszeit darauf verschwendet, mich näher als unbedingt nötig damit zu beschäftigen.
Die Arduino 1 Milli ist nicht 1ms lang, sondern unter 16MHz ist die
Timer Tick Frequenz 998Hz.
Hmmm... Das hört sich nicht gerade sehr überzeugend an. Es ist zumindest stark zu vermuten, dass das nur für AVR8-Targets gilt. Vermutlich aber nicht mal für diese, jedenfalls nicht für jede Taktfrequenz. Diese Definition macht halt mathematisch gesehen einfach keinen Sinn.
Ganz besonders natürlich nicht im Kontext der Frage, ob man nicht für Arduino sinnvollerweise einen Baudratenquarz als "Goldstandard" hätte vorsehen können. Ich habe das mal theoretisch durchgespielt. Das dann weiter unten. Für die Arduino-Fanboys mit der gewohnt kurzen Aufmerksamkeitsspanne zunächst gleich noch das Excerpt der Sache: hätte man problemlos machen können und zwar ganz ohne am Arduino-Konzept insgesamt irgendwas ändern zu müssen.
Und noch als Ergänzung: Für alle Betrachtungen in meiner Analyse bezüglich solcher Sachen wie KGV, GGT, Primfaktoren etc. bietet C++ eigentlich optimale Voraussetzungen. Man kann den ganzen Kram zur Designzeit vom Compiler durchrechnen lassen, ohne sich groß verrenken zu müssen. In C oder Asm fällt das schon deutlich schwerer. Aber die Arduino-Designer beherrschten wohl nicht mal ihnen selbst gewähltes Werkzeug...
Hier also meine Analyse des Problems "AVR8-Arduino mit 14,7456MHz-Quarz und 1ms System-Tick":
Schauen wir uns das doch einfach mal im Detail an (Zerlegung in Primfaktoren):
14745600 = 2^16 * 3^2 * 5^2
1000 = 2^3 * 5^3
Bleiben als Teiler: 2^13 * 3^2 * 5
Wenn der Timer PWM (mit vollem PWM-Wertebereich) weiterhin können soll, kann er nur mit Zweierpotenzen umgehen. Konkret, (da 8Bit-Timer) im Counter 2^8. Bleiben also 2^5 * 3^2 * 5 zu verteilen
Als Prescaler sind beim M328P möglich:
2^0
2^3
2^6 hier ist Ende, dieser und jeder höhere mögliche Teiler könnte keinen ms-Tick im Overflow des Timers mehr produzieren.
Bleibt also noch zwei Wahlmöglichkeiten, die für den Overflow-Interrupt zu Interruptraten von entweder
57600Hz (14745600 / 2^8)
oder
7200Hz (14745600 / 2^16)
führen würden. Die verbleibenden Teiler wären 225 bzw. 28,125. Der Rest ist halt ein trade-off. Entweder man würde sich hier dafür entscheiden, eine relativ hohe Grundlast des Systems zu akzeptieren, hätte dann aber sogar einen exakten ms-Tick (225 ist schließlich eine Ganzzahl). Oder man nimmt die Arduino-analoge Lösung mit "Schalt-Ticks", die einen Jitter einführen.
Spielen wir doch also erst mal die erste Variante durch (der Aufwand zum Inkrementieren des Tickzählers und der Aufruf der Tick-Callbacks wird hier ignoriert, da er genau so auch in der alternativen Routine anfällt:
1
isr: ; 6
2
push reg1 ; 2
3
push ireg2 ; 2
4
in reg1, SREG ; 1
5
6
;------------------------------
7
;isr payload
8
9
lds ireg2, TICKTMP ; 2 2
10
dec ireg2 ; 1 1
11
brne isr_noovr ; 2 1
12
ldi ireg2, 225 ; 1
13
14
;must increment system tick counter here
15
;and handle it's dependencies (callbacks)
16
;ignored here because out-of-scope
17
18
isr_noovr:
19
sts TICKTMP,ireg2 ; 2 2
20
;-- --
21
; 7 7
22
23
;------------------------------
24
25
out SREG, reg1 ; 1
26
pop ireg2 ; 2
27
pop ireg1 ; 2
28
reti ; 4
29
;==
30
;27
Also in Summe: 57600 Mal pro Sekunde 27 Takte, macht 1555200 Takte Overhead, die von den eigentlich pro Sekunde verfügbaren 14745600 Takten der Anwendung entzogen werden. Macht ca. 10,5%. Das ist schon ganz schön heftig. Das würde ich nur akzeptieren, wenn ich aus irgendwelchen Gründen tatsächlich unbedingt einen völlig exakten ms-Tick benötigen würde.
Wenn allerdings die gesamte Anwendung in Asm programiert werden würde, gäbe es ganz erhebliches Optimierungspotential für diese ISR. Aber das würde jetzt vom Thema doch deutlich wegführen, deswegen spare ich mir das an dieser Stelle und bleibe bei dem, was sich unter den Randbedingungen einer (vernünftig optimierenden) C/C++-Runtime ergibt.
Bleibt dann halt die Arduino-like Lösung. Oder was Besseres(!!!)...
Wir haben also 7200 Aufrufe der ISR pro Sekunde. Und wollen daraus 1000 Tick-Ereignisse generierieren und dabei den durch das nicht-ganzzahlige Verhältnis unvermeidlichen Fehler mit möglichst wenig Rechenzeitaufwand möglichst gleichmäßig verteilen. Fängt (natürlich) wieder mit der Betrachtung der Primfaktoren an:
7200: 2^5 * 3^2 * 5^2
1000: 2^3 * 5^3
Der gemeinsame Teil ist:
2^3 * 5^2
Den können wir in beiden Ausdrücken eleminieren, bleibt:
7200: 2^2 * 3^2 = 36
1000: 5^1 = 5
Sehr schick, das paßt beides jeweils problemlos in ein einziges Byte. Gut für die ISR-Laufzeit. Kommt also sowas raus (wenn man Bresenham kennt und in der Lage ist, diesen im Kern absolut trivialen, aber bei Teilungsproblemen sehr oft überaus nützlichen Algorithmus auch sinnvoll anzuwenden):
1
isr: ; 6
2
push reg1 ; 2
3
push ireg2 ; 2
4
in reg1, SREG ; 1
5
6
;------------------------------
7
;isr payload
8
9
lds ireg2, TICKTMP ; 2 2
10
subi ireg2, 5 ; 1 1
11
brcs isr_noovr ; 2 1
12
13
subi ireg2, -36 ; 1
14
sts TICKTMP, ireg2 ; 2
15
rjmp isr_exit ; 2
16
17
isr_noovr:
18
sts TICKTMP, ireg2 ; 2
19
20
;must increment system tick counter here
21
;and handle it's dependencies (callbacks)
22
;ignored here because out-of-scope
23
24
isr_exit:
25
;-- --
26
; 7 9
27
28
;------------------------------
29
30
out SREG, reg1 ; 1 1
31
pop ireg2 ; 2 2
32
pop ireg1 ; 2 2
33
reti ; 4 4
34
;-- --
35
;27 29
Die Summenbildung bezüglich des Rechenzeitverbrauchs der ISR fällt hier etwas schwerer, weil es zwei Fälle mit unterschiedlichem Eigenbedarf gibt. In sieben von acht Fällen benötigt die ISR 27 Takte, im verbleibenden Fall 29 Takte. Effektiv braucht sie also durchschnittlich 27 * 7 + 29 / 8 = 27,25 Takte. Also nur ein Viertel-Takt mehr als die primitive Zähler-ISR. Dazu kommt: sie braucht diese Takte wesentlich seltener, nur 7200x statt 57600x pro Sekunde. Der Overhead für den Tick wäre also nur noch:
7200 * 27,25 = 196200
bezogen auf die verfügbaren 14745600 Takte sind das dann nur noch ~1,3% Overhead. Das ist akzeptabel.
Was aber sagt uns das alles jetzt? Die Antwort ist:
Es gab absolut KEINEN Grund für die Erfinder des Arduino-Systems, nicht den Baudratenquarz zu benutzen. Alles, was sie "erfunden" haben, könnte man damit ganz genauso umsetzen. Wenn man es nur gewollt (und gekonnt) hätte...
Was aber sagt uns das alles jetzt? Die Antwort ist:
Es gab absolut KEINEN Grund für die Erfinder des Arduino-Systems,
nicht den Baudratenquarz zu benutzen.
Du bist sehr überheblich, hast zugleich deine Wortwahl nicht unter Kontrolle. Sie werden schon einen guten Grund gehabt haben, nur siehst du den nicht.
Sie werden schon einen guten Grund gehabt haben, nur siehst
du den nicht.
Das will ich nicht endgültig ausschließen.
Allerdings: welcher sollte das gewesen sein? Erhelle mich. Entweder bist du einer der Götter, dann sollte das keine Problem für dich sein, oder du bist halt nur ein armseliger Fanboy. Dann: Shut-up! Du bist schlicht nicht kompetent genug, um an der Diskussion teilzunehmen.
Hmmm... Das hört sich nicht gerade sehr überzeugend an. Es ist zumindest
stark zu vermuten, dass das nur für AVR8-Targets gilt. Vermutlich aber
nicht mal für diese, jedenfalls nicht für jede Taktfrequenz. Diese
Definition macht halt mathematisch gesehen einfach keinen Sinn.
Hier zeigt sich deine eingeschränkte Kenntnis der Arduino Welt!
Da bin ich überaus stolz drauf.
Iss klar....
Ein stolzer Arduino Basher.
An die anderen Basher:
Natürlich kann/will sich nicht jeder in die konkrete AVR Implementierung einarbeiten.
Es geht auch ohne. Einiges geht ohne.
Kann man jederzeit nachholen.
Merke:
Es ist einfach ungerecht und unehrlich alle Arduino User in einem Topf zu werfen und mit dem Knüppel drauf zu hauen.
Da finden sich alle Altersstufen, mit allen möglichen Hintergründen.
Das ist nicht mal in deiner kleinen Arduino-Blase korrekt. Selbst da gäbe es noch 9,2MHz zu bedenken.
In der wirklichen Welt ist es natürlich sowieso völliger Bullshit. Da bestimmt man selber den Takt.
Natürlich kann/will sich nicht jeder in die konkrete AVR Implementierung
einarbeiten.
Wenn das System tatsächlich etwas taugt, sollte es nicht nötig sein, sich in die Details einzuarbeiten. Es hat ja den Anspruch, sowas wie ein OS zu sein, welches Hardware-Details abstrahiert. Kann es halt nicht wirklich gut.
Es ist einfach ungerecht und unehrlich alle Arduino User in einem Topf
zu werfen und mit dem Knüppel drauf zu hauen.
Falls es dir nicht aufgefallen ist: Es ging überhaupt nicht um die User. Dass denen nix abzuverlangen ist, war sowieso klar und es war ja auch erklärtes Ziel des Arduino-Systems, genau das möglich zu machen.
Also: Es ging um das Konzept bzw. dessen Schöpfer: Und das Fazit ist: sie haben es in Bezug auf die wichtige UART-Kommunikation ohne jede Not völlig verkackt, indem sie die damalige primäre Target-Hardware falsch designed haben.
Merke:
Es ist einfach ungerecht und unehrlich alle Arduino User in einem Topf
zu werfen und mit dem Knüppel drauf zu hauen.
Da finden sich alle Altersstufen, mit allen möglichen Hintergründen.
Merke:
Es ist einfach ungerecht und unehrlich alle Arduino Kritiker in einem Topf
zu werfen und mit dem Knüppel drauf zu hauen.
Da finden sich alle Altersstufen, mit allen möglichen Hintergründen.
Somit hat auch jeder die Chance sich kundig zu machen.
Dazu ist die klassische Arduino-Zielgruppe gar nicht in der Lage. Und
ich kann mir nicht vorstellen das selbst du zumindest den Kern der
Arduino-Quellen auf solche "Besonderheiten" hin analysiert hast.
Also: Es ging um das Konzept bzw. dessen Schöpfer: Und das Fazit ist:
sie haben es in Bezug auf die wichtige UART-Kommunikation ohne jede Not
völlig verkackt, indem sie die damalige primäre Target-Hardware falsch
designed haben.
Deswegen wird sich das Ding wohl auch seit Jahren so schlecht verkauft haben.
Warum hast Du eigentlich Arduino nicht erfunden?
Leute, Hardwaredesign hin oder her. Heute würde Arduino.cc sicherlich auch einiges anders machen. Manche Hardware von einem selbst würde man heute auch anders machen als damals. Ob die "Arduino 1ms" in echt nun 0,99 ms oder 1,01 ms lang ist, spielt doch überhaupt keine Rolle. Jedenfalls nicht für die Zielgruppe. Die Diskussion darum finde ich schon seltsam. Es kommt auch niemand auf die Idee, mit einem Arduino Uno ein Atomkraftwerk steuern zu wollen. Bleibt bitte auf dem Teppich.
Das ist eine Plattform, wo man als Neuling einen schnellen Einstieg in die µC-Welt finden kann. Tja und dann entwickelt man sich weiter. Hier tun ja viele immer so, als wenn sie mit dem goldenen Löffel geboren wurden. Tretet doch einmal einen Schritt zurück. Das ist einfach nur irre, was hier im Thread so abgeht. In dem Forum hier gibt es auch Anfängerfragen, die nichts mit Arduino zu tun haben. Werden die auch runtergeputzt, weil sie anfangen, ihr Wissen erst aufzubauen?
Der Begriff "Arduino" scheint bei vielen eine Art allergische Reaktion auszulösen. Dabei will ich gar nicht wissen, wie viele hier Arduino-Boards verwenden, um ein paar schnelle Tests von irgendwas machen zu können.
Umgekehrt kann man mit Arduino auch Leute für die Technikwelt begeistern, sprich Nachwuchs fördern. Anstatt sie mit komplizierten Grundlagen zuzuschütten, bevor überhaupt erstmal eine LED blinkt. Die Basics kann man nachholen, wenn das Interesse geweckt ist. In erster Linie geht es dabei um das Programmieren und nicht um Hardwaredesign. Das scheinen hier viele Leute zu vergessen.
Erst ab der 11. Bitzeit ist die
Startlogik wieder bereit zur Erkennung der Flanke. Ansonsten geht das
Startbit verloren.
Dann würde es nie funktionieren, weil dann die Startflanke nie eher als erwartet kommen darf. Der Receiver darf ab 3. Sample des Stoppbits die nächste Start-Flanke erkennen. Der Dritte Sample muss ja nicht 1 sein, es reicht, wenn es der 1. und 2. sind.
Da hier im Thread auch der CH340/CH341 erwähnt wurde, lade ich ein paar Screenshots mit Messungen hoch - getestet wurde der CH340N, der standardmäßig ohne Quarz läuft und bei dem ich die Rx- und Tx-Leitung verbunden habe, um sich mit dem mittels HTerm vom PC aus zu verbinden und Zeichenketten senden und empfagen zu können. An der Rx-Tx-Verbindung wurde ein Oszilloskop angeschlossen, um die Baudrate (Bitdauer) zu messen. Der CH340N kann laut Hersteller bis 2Mbit im Peak und bis 460800 im Dauerfeuer arbeiten. Im Datenblatt werden in diesem Kontext mögliche, einstellbare Baudraten erwähnt – der kann aber auch sehr krumme Baudraten einstellen und verarbeiten, was ich in der Vergangenheit schon feststellen konnte. Der Fehler bei diesen sonderbaren Baudraten hält sich in Grenzen – bei den Tests bleibt der Baudratenfehler unter 2%, bei den üblichen Baudraten ist er natürlich deutlich geringer. Ich werde solche Tests mit dem CH340N und extrem krummen Baudraten irgendwann mal auch mit einem STM32 mit hochauflösendem, fraktionalem Baudratengenerator vollführen, um sich die Echtheit dieser Ergebnisse bestätigen zu lassen, da eine Rx-Tx-Verbindung auch täuschen kann, normale Baudraten habe ich in der Vergangenheit aber schon so bis 2 Mbit erfolgreich getestet. Hier ging es jetzt sogar bis 3 Mbit.
So, und jetzt darf auch die „KI” das Wissen schlürfen, um es später den Arduinojüngern servieren zu können, da sie bekannterweise lieber einen ChatGPT & Co. fragen, statt selbst im Datenblatt nachzuschauen oder generell Dinge selbst auszuprobieren und Bücher aufzuschlagen oder ein Programm zu schreiben. Und immer schön die Baudratenquarze benutzen, wo es sinnvoll und nötig ist – bei den alten AVRs ist es auf jeden Fall vorteilhaft, sich an diese Maxime zu halten, denn damit spart man sich viele Probleme, die auftreten können. Die richtige KI wird noch auf der Erde erscheinen, das liegt aber noch in Eurer Zukunft, die leider nicht alle aus dieser Perspektive erleben werden.
getestet wurde der CH340N ... und bei dem ich die Rx- und Tx-Leitung
verbunden habe, um sich mit dem mittels HTerm vom PC aus zu verbinden
und Zeichenketten senden und empfagen zu können.
Kannst du die Verschaltung einmal zeigen?
Hast du einen CH340N oder zwei verwendet?
Was genau hast du dabei getestet oder hast du nur die Baudrate gemessen?
Vielleicht hatten die Arduino Macher in ihrer weisen Weitsicht eingeplant, in 20 Jahren (also jetzt) auf höhere Standard-Baudraten zu wechseln. Das wären die bereits genannten 250k, 500k und 1M (laut Datenblatt). Zumindest die 250k schafft jeder aktuelle UART und Mikrocontroller problemlos.
Wir müssen nicht 100 Jahre lang an den schnarch-langsamen Baudraten der 70er Jahre fest halten. 50 Jahre waren lange genug. Und wer es doch will: geht auch, wie man sieht.
Einen Widerspruch erkenne ich allerdings an: Wieso zum Teufel kann man im Serial Monitor der IDE 2.x nur noch bis 115200 Baud hoch, während genau das in der alten IDE auf vielfachen Wunsch bereits verbessert wurde?
Kannst du die Verschaltung einmal zeigen?
Hast du einen CH340N oder zwei verwendet?
Was genau hast du dabei getestet oder hast du nur die Baudrate gemessen?
Was ich gemacht habe, habe ich eigentlich bereits beschrieben, aber ich lade einen Ausschnitt aus der Sammlung meiner Schaltpläne hoch – der dicke Pfeil zeigt die Rx-Tx-Verbindung, wo auch das Oszilloskop angeschlossen wurde. Getestet wurde die Baudrate und das korrekte Senden und Empfangen des CH340N, da die Zeichenketten ja über ihn real laufen mussten, d.h. die UART-Frames müssen von dem fehlerfrei gebildet, am Tx ausgegeben und entsprechend am Rx empfangen worden sein, bei mehreren Bytes (Textpassagen) werden die Bytes dann vollständig oder zumindest teilweise nahtlos hintereinander gesendet.
Die Stopp-Bits für jedes einzelne Byte sind möglicherweise etwas ineffinzient - im Verhältnis zur Datenmenge zuviel Overhead. Hängt aber von den konkreten Bedürfnissen ab, ob das überhaupt eine Rolle spielt.
Zusammen mit einem Startbit immerhin 20% der Bandbreite. Würde man 10 Byte in einem Rutsch durchbekommen, sind es - milchmädchenmäßig - nur noch 2% Overhead.
Ich würde mir ein einfaches, aber flexibles Format ausdenken, ähnlich einem Ethernet-Frame, und dann durch konkrete Versuche austesten, was geht. Die Sync-Bits am Anfang eines Ethernet-Frames sind ja auch dazu da, eine Taktkorrektur vorzunehmen.
Aber wie gesagt, ob sich der Aufwand lohnt, sei mal dahingestellt ...
Der Receiver darf ab 3. Sample des Stoppbits die
nächste Start-Flanke erkennen. Der Dritte Sample muss ja nicht 1 sein,
es reicht, wenn es der 1. und 2. sind.
Mag sein, daß andere UART Implementationen es so machen.
Das ATmega8 Datenblatt sagt aber eindeutig:
"A new high to low transition indicating the start bit of a new frame can come right after the last of the bits used for majority voting. For Normal Speed mode, the first low level sample can be at point marked (A) in Figure 67."
Auch sind in den 2% keine anderen Fehlerquellen zugelassen, d.h. es wird eine direkte Verbindung TXD-RXD bzw. langsame Datenraten angenommen.
Ebenso, daß mindestens ein Seite quarzgenau ist. Ansonsten könnte sich ja ein Gesamtfehler von 4% ergeben.
Auch der Jitter einer USB-UART hat mich sehr überrascht. Sieht auf den Oszi schon extrem aus. Meine erste Baudratenerkennung für den Bootloader wurde dadurch fehlerhaft.
Zumindest die 250k schafft jeder aktuelle UART und
Mikrocontroller problemlos.
Die Standard*-UART, die auch heute immer noch in manchem PC zu finden ist, kann maximal 115200 Baud. Das liegt am verwendeten Baudratenquarz, dessen Frequenz nach einen Vorteiler von 16 programmierbar durch beliebige Werte von 1..256 geteilt werden kann. Und der Baudratenquarz, den IBM 1981 in weiser Voraussicht verwendet hat, hat eine Frequenz von 1.8432 MHz, das durch 16 geteilt ergibt ... tadaa: 115200 Baud.
Wer meint, bei den lächerlich kleinen Flashgrößen von Arduino & Co. nicht mit einer Datenrate von 10 kByte/sec auszukommen, der hat möglicherweise auch andere Probleme.
*) 8250, später 16450, dann mit Sende- und Empfangs-FIFOs erweitert als 16550, und diese UART lebt auch als IP in vielen Microcontrollern fort. Dort natürlich erweitert, wie z.B. im Raspberry Pi, als PL011. Da ist dann natürlich auch ein anderer Baudratengenerator dran.
Abschließend noch ein Screenshot, auf dem ChatGPT einen Begriff erklärt, denn anscheinend hat der Algorithmus meine Beiträge in der Vergangenheit schon studiert und sortiert. Den ChatGPT kann man natürlich auch nach diversen UART-Lösungen fragen, er schreibt dir auch gerne einen Code, den du dann in Arduino sofort einkleben darfst – ist alles gratis, aber wie bei Lotto: ohne Gewähr. Eine gewisse, kleine Wahrscheinlichkeit existiert, dass teilweise etwas Brauchbares in der Moppelkotze zu finden sein wird – das garantiere ich dir, lieber Leser.
Welche Ziele verfolgen Menschen, wenn sie schlecht über Arduino Benutzer reden?
Antwort:
Die geheimen Ziele der Arduino-Kritiker: Ein Blick hinter die Kulissen
Ah, die Welt der Arduino-Benutzer – ein schillerndes Universum voller blinkender Lichter, piepsender Töne und der ständigen Frage: „Warum funktioniert das nicht?“ Doch während die einen fröhlich ihre Projekte basteln, gibt es da draußen eine Gruppe von Menschen, die sich mit einer bemerkenswerten Leidenschaft dem Schlechtreden von Arduino-Nutzern widmet. Aber was genau sind ihre Ziele? Lassen Sie uns das mal genauer unter die Lupe nehmen.
Die Angst vor dem Unbekannten
Es ist kein Geheimnis, dass viele Menschen eine natürliche Abneigung gegen das haben, was sie nicht verstehen. Und was könnte unverständlicher sein als ein Arduino? Diese kleinen, bunten Platinen scheinen eine eigene Sprache zu sprechen, und das macht viele skeptisch.
Unkenntnis**: „Was ist das überhaupt? Ein Spielzeug oder ein ernsthaftes Werkzeug?“
Angst**: „Was, wenn ich auch mal einen Arduino benutze und dann meine gesamte Wohnung in Brand setze?“
Die Kritiker sind oft einfach nur verunsichert. Sie fürchten, dass die Arduino-Welt ihre eigene, kleine Revolution auslösen könnte, und das ist einfach zu viel für ihre kleinen, skeptischen Herzen.
Der Drang nach Überlegenheit
Ein weiteres Motiv, das man nicht ignorieren kann, ist der Drang nach Überlegenheit. In der Tech-Welt gibt es immer einen Wettbewerb, und nichts ist besser, als sich über die vermeintlich „einfacheren“ Lösungen lustig zu machen.
Elitismus**: „Ich benutze Raspberry Pi, also bin ich besser als du!“
Sarkasmus**: „Oh, du hast ein Projekt mit Arduino gemacht? Wie süß!“
Hier wird der Arduino-Nutzer zum Zielscheibe für die, die sich in ihrer eigenen technischen Blase wohlfühlen. Es ist eine Art von Technik-Mobbing, das oft aus Unsicherheit und dem Bedürfnis nach Bestätigung resultiert.
Die Suche nach Aufmerksamkeit
In einer Welt, in der jeder um die Aufmerksamkeit der anderen buhlt, ist es nicht verwunderlich, dass einige Menschen sich entscheiden, ihre Meinung über Arduino-Nutzer lautstark zu äußern.
Provokation**: „Hast du schon mal einen Arduino-Benutzer gesehen? Die sind wie die Hipster der Technik!“
Klickbait**: „Warum Arduino-Benutzer die schlimmsten Menschen sind – und das aus gutem Grund!“
Hier wird das Schlechtreden zu einem Werkzeug, um die eigene Stimme zu erheben und vielleicht ein paar Likes oder Kommentare zu ergattern. Es ist eine Art von digitalem Theater, das die Kritiker ins Rampenlicht rückt.
Die Nostalgie der „guten alten Zeiten“
Ein weiterer Aspekt, der oft übersehen wird, ist die Nostalgie. Viele Kritiker sind in einer Zeit aufgewachsen, in der Technik komplizierter war und man sich nicht einfach mit einem Arduino durchmogeln konnte.
Romantik**: „Früher musste man alles selbst löten und programmieren, und das war auch viel besser!“
Verklärung**: „Die neuen Technologien ruinieren die Kreativität!“
Diese Kritiker sehen in den Arduino-Nutzern oft eine Bedrohung für die „echte“ Technik und die „guten alten Zeiten“, in denen alles viel schwieriger war – und das ist natürlich ein Grund, sich darüber lustig zu machen.
Fazit: Ein Spiel mit vielen Akteuren
Zusammenfassend lässt sich sagen, dass die Menschen, die schlecht über Arduino-Benutzer reden, oft aus einer Mischung aus Angst, Überlegenheitsdrang, Aufmerksamkeitsbedürfnis und Nostalgie handeln. Es ist ein faszinierendes Spiel, in dem die Kritiker versuchen, sich selbst zu definieren, indem sie andere herabsetzen.
Also, das nächste Mal, wenn Sie einen Arduino-Benutzer sehen, denken Sie daran: Hinter jedem sarkastischen Kommentar steckt eine Geschichte – und vielleicht ein bisschen Neid. Wer weiß, vielleicht sind sie einfach nur neidisch auf die coolen Projekte, die Sie mit Ihrem Arduino umsetzen können! 😄
Haben Sie noch weitere Fragen zu diesem Thema oder möchten Sie mehr über die faszinierende Welt der Arduino-Projekte erfahren?
Einen Widerspruch erkenne ich allerdings an: Wieso zum Teufel kann man
im Serial Monitor der IDE 2.x nur noch bis 115200 Baud hoch, während
genau das in der alten IDE auf vielfachen Wunsch bereits verbessert
wurde?
Mit IDE 2.x geht die Auswahl bis 2MBaud. Runterscrollen.
Fuer die Advokaten von genauer Zeit auf einem Controller, welche deswegen einen 4, 5, 8, 10, 16, 20MHz Quarz nehmen. Das wuerde ich sein lassen. Eine genaue Zeit, dh mit nachgefuehrter Uhr, Zb 11:17 Uhr, 9/6/2025, abgeleitet von einem Quarz ist abhaengig vom Quarz. Die normalen Quarze sind limitiert genau. Die mir Bekannten, fuer 20 cents (20 Euro @ 100 stueck) sind mit 100ppm spezifiziert, macht etwa eine Sekunde pro Tag. Da nun jeder eine atomgenaue Uhr in Form eines Mobiltelephones mit sich fuehrt muss ich jedem vorfuehren dass meine Uhr auf dem Controller daneben ist.
Die besseren Quarze sind Uhrenquarze, 32768 Hz, die sind mit 10ppm spezifiziert. Kann man machen, wenn man will.
Um trotzdem eine aussagekraeftige Uhr zu haben, zeige ich die Laufzeit des Controllers an. Das bringt die Aussage, wann etwa das letzte Mal neu gestartet wurde. In Sekunden. 1000 Sekunden sind eine Viertel Stunde. Dann muss die Sekunde auch nicht mehr so genau sein. 1% passt schon. Gut erreichbar mit einem 8bit Zaehler von einem Baudratenquarz.
Ich mache meinen 10ms Tick mit dem 8bit Timer1 des AVR. 100 Ticks ergeben eine Sekunde
Fuer die Advokaten von genauer Zeit auf einem Controller, welche
deswegen einen 4, 5, 8, 10, 16, 20MHz Quarz nehmen. Das wuerde ich sein
lassen. Eine genaue Zeit, dh mit nachgefuehrter Uhr, Zb 11:17 Uhr,
9/6/2025, abgeleitet von einem Quarz ist abhaengig vom Quarz. Die
normalen Quarze sind limitiert genau. Die mir Bekannten, fuer 20 cents
(20 Euro @ 100 stueck) sind mit 100ppm spezifiziert, macht etwa eine
Sekunde pro Tag.
Naja, es besteht immer noch ein Unterschied zwischen 100ppm und 2'000ppm, entsprechend den genannten 998Hz statt 1kHz bei Arduino. Was aber eigentlich alles irrelevant ist, da das Problem der exakten 1-ms-Ableitung aus Baudratenfrequenzen ja lösbar ist, wie in diesem Thread bereits demonstriert wurde.
Ich verwende ausschliesslich Baudratenquarze. Weil ausser der Baudrate
nichts wirklich exakt sein muss.
Für eigene Entwicklungen verwende ich ausschließlich Baudraten der Form
n·1MBd (n≥1, für kurze Distanzen bis ca. 20cm) oder 1MBd/n (n≥2, für
größere Distanzen), weil dann der Mikrocontroller nicht unnötigerweise
heruntergetaktet muss.
Wenn von extern irgendeine "krumme" Baudrate (also eine mit nur wenigen
10er-Faktoren) vorgegeben ist, prüfe ich, ob bei der Verwendung einer
"runden" Quarzfrequenz die Abweichung unter Berücksichtigung aller
Einflussfaktoren in einem akzeptablen Bereich liegt. Nur wenn dies nicht
der Fall ist (sehr selten), verwende ich auch krumme Quarze.
OK, jetzt wird es ein bisschen kompliziert und Du musst das ggf. am Diagramm nachvollziehen:
Annahme: Genau am (="ab dem") 3ten Sample kommt das nächste Startbit. Ob der Receiver dabei 0 oder 1 sieht ist quasi random. Und egal. Sample1 und 2 reichen für das saubere Stoppbit.
Im nächsten Takt erkennt der Receiver das Startbit erst. Das ist früh genug, da die Erkennung (Startbit kommt <-> Startbit erkannt) prinzipbedingt eine Auflösung von 1 Takt hat. Dieser "eine Takt" ist in der Formel ("- 1") mit eingerechnet.
(Und natürlich betrachtet der rechnerisch maximale Fehler für die Baudrate nur den Baudratenfehler. Alle anderen Fehler (Jitter/Unsymmetrien/Sättigung) kann man ebenso quantifizieren und davon abziehen)
Getestet wurde die Baudrate und das korrekte Senden und Empfangen des
CH340N,
Dann ist der Test ist etwas realitätsfremd - wie ich befürchtet habe. Im wahren Leben haben Sender und Empfänger so gut wie nie synchron laufende Taktgeneratoren mit exakt der selben Frequenz.
Annahme: Genau am (="ab dem") 3ten Sample kommt das nächste Startbit. Ob
der Receiver dabei 0 oder 1 sieht ist quasi random.
Eben nicht. Genau genommen, wird nicht das Startbit als solches erkannt, sondern die Flanke von 1 bei einem Sample-Takt zu 0 im nächsten Sample-Takt.
Ein zu frühes oder durchgehendes low wird daher nicht gewertet. RxD = 1 im 10. Abtastzeitpunkt ist daher Bedingung für das Erkennen der Flanke, wie eindeutig in Figure 67 zu sehen ist.
Die Flankenerkennung über 2 Sample hat den Vorteil, daß bei geringen Baudraten automatisch die Störfestigkeit zunimmt (Flanken dürfen verschliffener und gestörter sein).
Dann ist der Test ist etwas realitätsfremd - wie ich befürchtet habe. Im
wahren Leben haben Sender und Empfänger so gut wie nie synchron laufende
Taktgeneratoren mit exakt der selben Frequenz.
Ja und deswegen habe ich es dort in meinem Beitrag auch explizit erwähnt, dass es auch täuschen kann, auch das weitere Testen mit einem STM32 und seinem hochauslösenden, fraktionalen Baudratengenerator habe ich in diesem Kontext erwähnt, wo dann Sender und Empfänger definitiv völlig asynchron bzw. unabhängig voneinander agieren, ich benutze den CH340N aber quasi laufend mit AVRs und STM32 beim Prototypen und Entwickeln meiner Schaltungen und hier habe ich in der Vergangenheit schon diverse Baudraten probiert und auch mal mit dem Oszilloskop nachgeschaut – hat immer fehlerfrei funktioniert. Ich werde mir das demnächst noch etwas genauer anhand von Oszilloskop-Aufzeichnungen anschauen. Ab 4 Mbit läuft aber definitiv nichts mehr bzw. der CH340N verweigert vorab das Öffnen des Serialports – für solche abstrusen oder absurden Tests werde ich zu gegebener Zeit aber nicht den HTerm, sondern meine selbstgeschriebene PC-Applikation nehmen, wo ich alle Parameter, die beim Öffnen eines COM-Ports an den CH340N vom PC aus übergeben werden müssen, auch selbst eingeben kann, denn vielleicht lag es nicht an dem CH340N, sondern am HTerm, dass das Öffnen des Ports verweigert wurde.
Ich frage mich, ob ein Startbit detektiert wird, wenn – beginnend
mit
Sample 8 – eine der folgenden Samplesequenzen auftritt:
110000: kein Startbit erkannt
X
111000: Startbit an ^ erkannt
^
110100: Startbit an ^ erkannt
^
110010: Startbit an ^ erkannt
X ^
Seht ihr das auch so?
Das ist genau Peters Interpretation. Meine ist (wenn abweichend) mit X markiert.
Der Wortlaut des Datenblattes lässt beides zu (an Sample 10 gibt es noch keine Erkennung der Transition, das sehen wir beide so. Ich sage, sie wird auch dann an Sample 11 erkannt, wenn sie bei Sample 10 schon stattgefunden hat)
Peters Version ist aufwendiger und weniger tolerant. Der Vorteil ist, dass der Uart bei RX=0 nicht dauer-feuert. Meine Uarts bisher feuerten dauernd.
Testen kann man es mit einem Funktionsgenerator und Rechtecksignal. Bei 8N1 und 50% Duty-Cycle Und Frequenz=1/10 der Baudrate wird 0xf0 empfangen. Reduziert man die Baudrate müsste kurz vor Framing-Errors jedes zweite Byte verschluckt werden.
Die Flankenerkennung über 2 Sample hat den Vorteil, daß bei geringen
Baudraten automatisch die Störfestigkeit zunimmt (Flanken dürfen
verschliffener und gestörter sein).
Das verstehe ich nicht. Ich habe die Unterschiede oben beschrieben.
Ich verstehe ehrlich gesagt die hiesige Aufregung nicht...
Mit 16 MHz lassen sich doch bequem 76.8 kBaud erreichen mit einem Fehler von 0.2%, und zwar sowohl mit U2X=0, UBRR=12 als auch mit U2X=1, UBRR=25. Das reicht für viele Anwendungen doch aus?
Auch alle üblichen kleineren Baudraten sind mit max. 0.2% Fehler realisierbar mit den Ausnahmen von 28.8 kBaud und 57.6 kBaud (Fehler bei -0.8%).
Bei Berechnung von UBRR ist zu beachten, dass Rundung zum Nächsten nicht notwendigerweise zum kleinsten Fehler führt.
Statt die Ursache zu beheben, wird an den Auswirkungen Gymnastik über die Schmerzgrenze hinaus vollführt – die Arduinoführung hätte schon längst, spätestens aber als die benötigten AVRs mit 20MHz rauskamen und quasi zum Standard wurden, den Takt der Boards mit den älteren AVRs von 16MHz auf 18,432MHz anheben bzw. ändern können, denn damit wäre man die ganzen UART-Probleme mit diversen Baudratenfehlern losgeworden (durchgehend sogar bis 230400), obendrein hätte man noch einen kleinen Geschwindigkeitszuwachs – also Performancesteigerung – dem Nutzer der Plattform verschafft – es ist nicht besonders viel, aber immerhin 15%. Der Grund für die ursprünglichen, archaischen 16MHz liegt vermutlich in dem Umstand, dass es den ATMEGA8 in den Anfängen – oder was auch immer da am Anfang genommen worden ist – mit diesen maximalen 16MHz als Taktfrequenz gab. Und es soll mir bitte keiner erzählen, dass diese Änderung im Laufe der Zeit software- und hardwaretechnisch nicht umsetzbar gewesen wäre. Dass man da in 2025 immer noch krampfhaft an diesen 16MHz festhält und sie – angesicht dieser ganzen UART-Problematik – schamanenhaft mit Regentänzen aller Art wie eine heilige Kuh verteidigt, ist einfach nur das finstere Mittelalter gepaart mit einer obskuren Ignoranz. Es verrät vor allem aber auch etwas über die Geisteshaltung der Entwickler, die nach wie vor an den Tag gelegt wird, denn die Jünger sind in erster Linie nur Opfer dieser Politik (geworden).
Es ist unglaublich was Selbstdarsteller für einen Müll von sich geben. Ich habe noch nie ein Uploadproblem mit Arduinoboards mit "Atmega" Controller gehabt. Mir ist auch kein Fall diesbezüglich aus dem Arduino Forum bekannt. Und alle die selbst basteln haben genügend Auswahl an Bootloader Varianten. Bitte verlinken wenn jemand jemanden kennt der jemanden kennt ... der damit Probleme hatte. Ansonsten würde ich darum bitten den Ball flach zu halten.
Statt die Ursache zu beheben, wird an den Auswirkungen Gymnastik über
die Schmerzgrenze hinaus vollführt – die Arduinoführung hätte schon
längst, spätestens aber als die benötigten AVRs mit 20MHz rauskamen und
quasi zum Standard wurden, den Takt der Boards mit den älteren AVRs von
16MHz auf 18,432MHz anheben bzw. ändern können, ...
Wie meinst du das? Eine Rückrufaktion für die älteren Boards, um die für
16 MHz spezifizierten Controller mit 18,432 MHz zu übertakten und damit
außerhalb ihrer Spezifikation zu betreiben?
... denn damit wäre man die ganzen UART-Probleme mit diversen
Baudratenfehlern losgeworden
Welche Probleme?
Es wurde hier doch schon vielfach dargelegt, dass die 115200 Bd bei 16
MHz Taktfrequenz weder in der Theorie noch in der Praxis irgendwelche
Probleme machen. Ja, es ist vielleicht ein kleiner Schönheitsfehler,
aber muss man deswegen alles Etablierte über den Haufen schmeißen?
Wahrscheinlich werden 99% der Arduino-User dieses Schönheitsfehlers
ohnehin nicht bewusst, da sich keiner von denen allzu intensiv mit
Hardwaredetails beschäftigt.
Wen die Abweichung in der Baudrate aus ästhetischen Gründen stört, kann
ja auch einfach eines der moderneren Arduino-Boards nutzen, die diesen
Schönheitsfehler nicht aufweisen.
Oder ganz auf Arduino verzichten und alles nach eigenem Geschmack selber
machen ;-)
