AVR - Taktfrequenz für Seriell ohne Handshake

[Michael (breitstern)]

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.

[S. L. (sldt)]

Datenblatt: 'Examples of Baud Rate Setting'

[Harald K. (kirnbichler)]

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.

[Arduino F. (Firma: Gast) (arduinof)]

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.

[Mario M. (thelonging)]

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).

[Johannes F. (jofe)]

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.

[Oliver S. (oliverso)]

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

[Johannes F. (jofe)]

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.

[Mario M. (thelonging)]

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

[Falk B. (falk)]

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.

[Falk B. (falk)]

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.

[Harald K. (kirnbichler)]

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.

[Georg M. (g_m)]

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."

[Rainer W. (rawi)]

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.

[Arduino F. (Firma: Gast) (arduinof)]

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.

[Falk B. (falk)]

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 . . 
.

[Ob S. (Firma: 1984now) (observer)]

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.

[Johannes F. (jofe)]

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.

[Falk B. (falk)]

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.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

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.

[Ralph S. (jjflash)]

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

[Nemopuk (nemopuk)]

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.

[Johannes F. (jofe)]

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.

[Ralph S. (jjflash)]

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.

[Johann L. (gjlayde)]

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.

[Ralph S. (jjflash)]

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.

[Ob S. (Firma: 1984now) (observer)]

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.

[Johann L. (gjlayde)]

..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).

[Johannes F. (jofe)]

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.

[Johannes F. (jofe)]

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.

[Nemopuk (nemopuk)]

Zum CH340/341 ist diese Seite hilfreich:
https://github.com/nospam2000/ch341-baudrate-calculation

12 Mhz  8  3 ergibt 500.000 Baud

[Ob S. (Firma: 1984now) (observer)]

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...

[Johannes F. (jofe)]

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.

[Nemopuk (nemopuk)]

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

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.

[Veit D. (devil-elec)]

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.

[Johannes F. (jofe)]

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.

[Nemopuk (nemopuk)]

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.

[Veit D. (devil-elec)]

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?

[Johannes F. (jofe)]

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.

[Ob S. (Firma: 1984now) (observer)]

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? ...

[Veit D. (devil-elec)]

Hallo,

dann verstehe ich die Diskussion nicht mehr worum es eigentlich geht. 
Wenn es  alles kein Problem darstellt.

[Ob S. (Firma: 1984now) (observer)]

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.

[Peter D. (peda)]

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.

[Peter D. (peda)]

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.

[Oliver S. (oliverso)]

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

[Peter D. (peda)]

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.

[Veit D. (devil-elec)]

Hallo Peter,

okay, lasse gelten.  :-)  :-)

[Ralph S. (jjflash)]

Johannes F. schrieb:
> 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.

Peter D. schrieb:
> Bei früheren 8051 Boards waren 11,0592MHz Quarze

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!

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Michael schrieb:
> 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.

[Nemopuk (nemopuk)]

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.

[Georg M. (g_m)]

Das Senden funktioniert fehlerfrei
ATtiny402
VDD: 3.0 V
Temp: 21°C
Main Clock: 2.5 MHz
UART: 115200 Bd

[Falk B. (falk)]

Georg M. schrieb:
> Das Senden funktioniert fehlerfrei
> ATtiny402
> VDD: 3.0 V
> Temp: 21°C
> Main Clock: 2.5 MHz
> UART: 115200 Bd

Bei diesem einen Exemplar an einen sonnigen Sonntag bei dir auf dem 
Tisch. Ob das in einer Massenanwendung auch so ist? Oder wenn es mal 
-15° sind?

[Nemopuk (nemopuk)]

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.

Georg M. schrieb:
>> VDD: 3.0 V
>> Temp: 21°C

Falk B. schrieb:
> Ob das ... auch so ist ... wenn es mal
> -15° sind?

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.

[Veit D. (devil-elec)]

Hallo,

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.

[Falk B. (falk)]

Nemopuk schrieb:
> 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

Genau! Solche Bauchgefühlsexperten brauchen wir!

Echte Experten rechnen!

https://www.analog.com/en/resources/technical-articles/determining-clock-accuracy-requirements-for-uart-communications.html

3,3% maximal! Ich würde nicht mehr als 1% empfehlen, im Extremfall 
vielleicht 2%.

[Nemopuk (nemopuk)]

Falk B. schrieb:
> 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.

[Falk B. (falk)]

Nemopuk schrieb:
> 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.

[Georg M. (g_m)]

Veit D. schrieb:
> Sein ATtiny402 ist nicht mit einem ATmega1284P u.ä. vergleichbar.

Ja, der ist kleiner und billiger.

[Veit D. (devil-elec)]

Hallo Georg, du hast die Unterschiede noch nicht verstanden.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Ein Screenshot zum „Thema” ATTINY402

[Nemopuk (nemopuk)]

Falk B. schrieb:
> 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.

[Falk B. (falk)]

Nemopuk schrieb:
> Damit wird das Stopbit immer noch
> korrekt erfasst.

Im Labor bei Sonnenschein und 22,5°C. In der realen Welt hat man damit 
NULL Toleranz gegen Störungen.

[Johann L. (gjlayde)]

Mal ne ganz andere Frage:

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?

[Nemopuk (nemopuk)]

Falk B. schrieb:
> 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.

Johann L. schrieb:
> Würde ein Handshake überhaupt gegen eine zu ungenaue UART-Frequenz
> helfen?

Ich denke in diesem Punkt wie du: hilft nicht

[Falk B. (falk)]

Johann L. schrieb:
> Gegen eine inexakte UART-Frequenz hilft ein Handshake doch überhaupt
> nicht?

BINGO!

[Ob S. (Firma: 1984now) (observer)]

Johann L. schrieb:

> Würde ein Handshake überhaupt gegen eine zu ungenaue UART-Frequenz
> helfen?

Nein.

> Gegen eine inexakte UART-Frequenz hilft ein Handshake doch überhaupt
> nicht?

So ist es. Der Handshake arbeitet auf Wort-Ebene. Ist also darauf 
angewiesen, dass die Wordsynchronisation funktioniert.

[Ob S. (Firma: 1984now) (observer)]

Nemopuk schrieb:

> 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...

[Peter D. (peda)]

Nemopuk schrieb:
> Aus dem Bauch heraus schätze ich

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.

[Arduino F. (Firma: Gast) (arduinof)]

Ob S. schrieb:
> 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!


Ob S. schrieb:
> 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.

[Yalu X. (yalu) (Moderator)]

Peter D. schrieb:
> Nemopuk schrieb:
>> Aus dem Bauch heraus schätze ich
>
> 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.

[Yalu X. (yalu) (Moderator)]

Arduino F. schrieb:
> Ob S. schrieb:
>> 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:

  https://docs.arduino.cc/language-reference/de/funktionen/time/millis/

[Ob S. (Firma: 1984now) (observer)]

Yalu X. schrieb:

> 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).

[Arduino F. (Firma: Gast) (arduinof)]

Yalu X. schrieb:
> 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.

[Roland F. (rhf)]

Hallo,
Arduino F. schrieb:
> 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.

rhf

[Ob S. (Firma: 1984now) (observer)]

Arduino F. schrieb:

> 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:

isr:                     ; 6
  push reg1            ; 2
  push ireg2           ; 2
  in reg1, SREG        ; 1

;------------------------------
;isr payload

  lds ireg2, TICKTMP   ; 2   2
  dec ireg2            ; 1   1
  brne isr_noovr       ; 2   1
  ldi ireg2, 225       ;     1

;must increment system tick counter here
;and handle it's dependencies (callbacks)
;ignored here because out-of-scope

isr_noovr:
  sts TICKTMP,ireg2    ; 2   2
                       ;--  --
                       ; 7   7

;------------------------------

  out SREG, reg1       ; 1
  pop ireg2            ; 2
  pop ireg1            ; 2
  reti                 ; 4
                       ;==
                       ;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):

isr:                    ; 6
  push reg1           ; 2
  push ireg2          ; 2
  in reg1, SREG       ; 1

;------------------------------
;isr payload

  lds ireg2, TICKTMP  ; 2   2
  subi ireg2, 5       ; 1   1
  brcs isr_noovr      ; 2   1

  subi ireg2, -36     ;     1
  sts TICKTMP, ireg2  ;     2
  rjmp isr_exit       ;     2

isr_noovr:
  sts TICKTMP, ireg2  ; 2

;must increment system tick counter here
;and handle it's dependencies (callbacks)
;ignored here because out-of-scope

isr_exit:
                        ;--  --
                        ; 7   9

;------------------------------

  out SREG, reg1      ; 1   1
  pop ireg2           ; 2   2
  pop ireg1           ; 2   2
  reti                ; 4   4
                      ;--  --
                      ;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...

[Johann L. (gjlayde)]

Jessas wie kompliziert.
Einfach Bresenham und gut is.

https://de.wikipedia.org/wiki/Bresenham-Algorithmus

[Ob S. (Firma: 1984now) (observer)]

Johann L. schrieb:
> Jessas wie kompliziert.
> Einfach Bresenham und gut is.

Lustig. Genau das ist ja, was ich getan habe, wozu die Arduino-Inventors 
aber scheinbar nicht fähig waren. Trotz optimaler Vorausetzungen...

[Nemopuk (nemopuk)]

Ob S. schrieb:
> 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.

[Ob S. (Firma: 1984now) (observer)]

Nemopuk schrieb:

> 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.

[Nemopuk (nemopuk)]

Ob S. schrieb:
> Allerdings: welcher sollte das gewesen sein? Erhelle mich

Ich weiß es auch nicht. Mir würden sie mit 14,756 MHz besser gefallen.

[Arduino F. (Firma: Gast) (arduinof)]

Ob S. schrieb:
> 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.
Ja, AVR.
Da gibts nur 8 und 16MHz

Und den Grund für die 998Hz habe ich dir genannt.
PWM.
So hat man den vollen 8Bit Wertebereich für PWM.
Doppelverwendung des Timer0

Ob S. schrieb:
> Arduino F. schrieb:
>
>> 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.
1. Es geht auch ohne. Einiges geht ohne.
2. 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.

[Ob S. (Firma: 1984now) (observer)]

Arduino F. schrieb:

> Ja, AVR.
> Da gibts nur 8 und 16MHz

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.

[Roland F. (rhf)]

Hallo,
Arduino F. schrieb:
> 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.

rhf

[Arduino F. (Firma: Gast) (arduinof)]

Ob S. schrieb:
> Arduino F. schrieb:
>
>> Ja, AVR.
>> Da gibts nur 8 und 16MHz
>
> Das ist nicht mal in deiner kleinen Arduino-Blase korrekt. Selbst da
> gäbe es noch 9,2MHz zu bedenken.
Welches AVR Arduino Board läuft mit 9,2MHz?


Ob S. schrieb:
> Da bestimmt man selber den Takt.
Natürlich auch mit Arduino möglich.
Wer will, findet auch Wege.



______________







Roland F. schrieb:
> Hallo,
> Arduino F. schrieb:
>> 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.
>
> rhf

Bla bla bla....

[Rick (rick)]

Ob S. schrieb:
> 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?

[Veit D. (devil-elec)]

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.

[Bruno V. (bruno_v)]

Peter D. schrieb:
> 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.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

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.

[Rainer W. (rawi)]

Gregor J. schrieb:
> 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?

[Nemopuk (nemopuk)]

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?

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Rainer W. schrieb:
> 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.

[Frank E. (Firma: Q3) (qualidat)]

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 ...

[Peter D. (peda)]

Bruno V. schrieb:
> 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.

[Harald K. (kirnbichler)]

Nemopuk schrieb:
> 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.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

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.

[Nemopuk (nemopuk)]

Gregor J. schrieb:
> Abschließend noch ein Screenshot

Ist ja schön, dass du hier den "Abschluss" des Themas bestimmst.

[Yalu X. (yalu) (Moderator)]

Harald K. schrieb:
> Nemopuk schrieb:
>> 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 spielt beim Arduino überhaupt keine Rolle, da dieser seinen eigenen
USB-UART-Konverter mitbringt.

[Arduino F. (Firma: Gast) (arduinof)]

Frage an Aria:
> 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.

1. 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.

2. 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.

3. 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.

4. 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?

[Veit D. (devil-elec)]

Nemopuk schrieb:

> 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.

[Veit D. (devil-elec)]

Yalu X. schrieb:
> Harald K. schrieb:
>> Nemopuk schrieb:
>>> 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 spielt beim Arduino überhaupt keine Rolle, da dieser seinen eigenen
> USB-UART-Konverter mitbringt.

Spielt auch mit FDTI keine Rolle.

[Nemopuk (nemopuk)]

Veit D. schrieb:
> Mit IDE 2.x geht die Auswahl bis 2MBaud. Runterscrollen.

Huch! Du hast Recht.  Ich könnte schwören, dass es vorgestern noch nicht 
ging.

Na, dann ziehe ich diese Kritik gerne wieder zurück.

[Pandur S. (jetztnicht)]

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

[Johannes F. (jofe)]

Pandur S. schrieb:
> 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.

[Pandur S. (jetztnicht)]

Aeh, ja, genau. Ich verwende ausschliesslich Baudratenquarze. Weil 
ausser der Baudrate nichts wirklich exakt sein muss.

[Georg M. (g_m)]

Ästhetisch: 16.000
Hässlich:   14.7456

[Yalu X. (yalu) (Moderator)]

Pandur S. schrieb:
> 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.

[Harald K. (kirnbichler)]

Yalu X. schrieb:
> Das spielt beim Arduino überhaupt keine Rolle, da dieser seinen eigenen
> USB-UART-Konverter mitbringt.

Das war in der Geschichte der Arduinos aber anders, die Ur-Modelle 
hatten eine 9polige Sub-D-Buchse.

https://en.wikipedia.org/wiki/Arduino#/media/File:Arduino316.jpg

Und wegen der Kompatibilitäterätä und so ...

[Bruno V. (bruno_v)]

Peter D. schrieb:
> Das ATmega8 Datenblatt sagt aber eindeutig:

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)

[Rainer W. (rawi)]

Gregor J. schrieb:
> 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.

[Rainer W. (rawi)]

Yalu X. schrieb:
> Das spielt beim Arduino überhaupt keine Rolle, da dieser seinen eigenen
> USB-UART-Konverter mitbringt.

Sprichst du vom Arduino Pro Mini? ;-)

[Nemopuk (nemopuk)]

Rainer W. schrieb:
> Sprichst du vom Arduino Pro Mini? ;-)

Den gibt es schon lange nicht mehr (original). Und der, den es gab, 
dessen Bootloader lief mit unproblematischen 57600 Baud.

[Peter D. (peda)]

Bruno V. schrieb:
> 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).

[Yalu X. (yalu) (Moderator)]

Ich frage mich, ob ein Startbit detektiert wird, wenn – beginnend mit
Sample 8 – eine der folgenden Samplesequenzen auftritt:

110000: kein Startbit erkannt

111000: Startbit an ^ erkannt
   ^
110100: Startbit an ^ erkannt
    ^
110010: Startbit an ^ erkannt
     ^

Seht ihr das auch so?

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

Rainer W. schrieb:
> 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.

[Bruno V. (bruno_v)]

Yalu X. schrieb:
> 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.

[Bruno V. (bruno_v)]

Peter D. schrieb:
> 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.

[Peter D. (peda)]

Bruno V. schrieb:
> Meine Uarts bisher feuerten
> dauernd.

Wird RXD dauerhaft auf low gesetzt, empfängt der AVR einmalig 0x00 + 
Frame-Error.
Einige neuere Typen haben aber auch eine Break-Erkennung.

[Johann L. (gjlayde)]

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.

[Nemopuk (nemopuk)]

Johann L. schrieb:
> Mit 16 MHz lassen sich doch bequem 76.8 kBaud erreichen mit einem Fehler von 
0.2%.
> Das reicht für viele Anwendungen doch aus?

Ja. Es ist halt seltsam, daß Arduino ohne Not den Bootloader 
ausgerechnet auf 115.200 Baud gewechselt hat.

Wer es braucht, kann für seine Anwendung gleich auf 250.000 Baud oder 
ein Vielfaches davon gehen. Die 115.200 auszulassen ist keine Schande.

[Gregor J. (Firma: Jasinski) (gregor_jasinski)]

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).

[Veit D. (devil-elec)]

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.

[Arduino F. (Firma: Gast) (arduinof)]

Gregor J. schrieb:
> nur Opfer dieser Politik
Nur komisch dass deine angeblichen Opfer keine Probleme mit den 16MHz 
haben.
Irgendwas scheint mit deiner Projektion nicht zu stimmen.

[Nemopuk (nemopuk)]

Gregor J. schrieb:
> schamanenhaft mit Regentänzen aller Art wie eine heilige Kuh
> verteidigt

Zeige mal

[Yalu X. (yalu) (Moderator)]

Gregor J. schrieb:
> 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 ;-)