Forum: Mikrocontroller und Digitale Elektronik Arduino Serial.flush Timeout


von Lothar (Gast)


Lesenswert?

Es sieht so aus als muss Serial.flush genutzt werden, damit alle Daten 
im Sendepuffer auch immer gesendet werden.

In der Arduino Doku steht aber auch:

Serial.flush wartet bis alle ausgehenden Daten gesendet wurden

Nun habe ich im Arduino Source Code nachgesehen, dort steht tatsächlich:

void HardwareSerial::flush()
{
  ...
  while (transmitting && ! (*_ucsra & _BV(TXC0)));
  ...
}

Serial.setTimeout hat also hier keinen Effekt

Das bedeutet aber doch, wenn sich z.B. das serielle Kabel lösen würde, 
hängt sich hier das Programm auf. Was kann man da machen?

Alles was mir dazu einfällt, ist kompliziert: Timer-Interrupt nutzen, um 
das hängen zu erkennen. HardwareSerial abändern und Serial.setTimeout in 
flush einfügen ...

von foobar (Gast)


Lesenswert?

> Das bedeutet aber doch, wenn sich z.B. das serielle Kabel lösen würde,
> hängt sich hier das Programm auf. Was kann man da machen?

Warum sollte es? Die UART schiebt die Daten raus, egal ob da nen Kabel 
drin steckt oder nicht.

von foobar (Gast)


Lesenswert?

> Es sieht so aus als muss Serial.flush genutzt werden, damit alle Daten
> im Sendepuffer auch immer gesendet werden.

Hab zwar nie Arduino genutzt, aber laut Doku ist nen flush nicht nötig 
- es wird auch so alles gesendet. Mit flush wartet man nur, bis alles 
gesendet wurde.

Meiner Erfahrung nach, liegt das Problem, das Anfänger anscheinden mit 
nem flush beheben, üblicherweise woanders - nen flush ist nur in 
seltenen Ausnahmen nötig.

von Einer K. (Gast)


Lesenswert?

Gestählt, durch langjährige Arduino Erfahrung, muss ich dem foobar 
uneingeschränkt zustimmen.


Lothar schrieb:
> Alles was mir dazu einfällt,...

Lothar, vielleicht solltest du mal sagen, welche Probleme dich wirklich 
plagen. Denn höchst vermutlich buddelst du auf der falschen Baustelle.

von Dudschleera (Gast)


Lesenswert?

foobar schrieb:
> egal ob da nen Kabel drin steckt oder nicht.

einen Kabel?

foobar schrieb:
> nen flush ist nur in seltenen Ausnahmen nötig.

einen Flush?

Der Akkusativ ist dem Nominativ sein Tod.

Deutsche Sprache - schwäre Sprache.
https://wortwuchs.net/grammatik/kasus/

von Lothar (Gast)


Lesenswert?

foobar schrieb:
> Anfänger

Da es um einen Port von 8051 auf Arduino geht bin ich auf Arduino wohl 
tatsächlich Anfänger ...

Die Ursache warum es nur mit flush funktioniert ist vermutlich gefunden. 
Diese serielle Schnittstelle ist über RS485 angeschlossen und es müssen 
alle Daten aus dem Sendepuffer raus bevor der Transceiver umgeschaltet 
wird.

Wird sogar hier erklärt:

https://www.mikrocontroller.net/articles/RS-485

Eine Überwachung mit Timer-Interrupt ist somit zum sicheren Betrieb mit 
Timeout erforderlich.

Wird z.B. hier erklärt:

https://oscarliang.com/arduino-timer-and-interrupt-tutorial/

Da die Timer 0-2 von der Arduino Software genutzt werden - für millis 
und so - und die Timer 3-5 frei sind auf dem Arduino MEGA kann ich also 
den Timer 5 dafür nehmen. Jetzt muss ich als AVR Nicht-Nutzer "nur" noch 
rausfinden, wie man auf dem ATMEGA2560 mit Timern arbeitet.

Es gibt zwar auch mehrere Arduino Timer Libraries. Wenn ich das aber 
richtig verstanden habe, nutzen die alle millis - also Polling - und 
würden sich mit dem Programm aufhängen.

von Einer K. (Gast)


Lesenswert?

Lothar schrieb:
> Da die Timer 0-2 von der Arduino Software genutzt werden
Eigentlich nur Timer0

Lothar schrieb:
> und es müssen
> alle Daten aus dem Sendepuffer raus bevor der Transceiver umgeschaltet
> wird.
Das ist ein guter Grund für einen Flush.


Was hast du denn jetzt für ein Problem mit den Timern?
Eben noch ein Flush Problem und jetzt Timer....

Wie hängt das zusammen?
Was willst du wirklich erreichen?

von Manfred (Gast)


Lesenswert?

foobar schrieb:
> Hab zwar nie Arduino genutzt,

Eine optimale Voraussetzung, hier Tipps zu geben :-(

> aber laut Doku ist nen flush nicht nötig - es wird auch so alles gesendet.
> Mit flush wartet man nur, bis alles gesendet wurde.

Ich habe eine Anwendung, wo ich den Arduino kurz nach seiner Aktion 
schlafen lege. Serial brauche ich nur für die Kalibrierung oder 
Fehlersuche.

Hier gab es Ärger, dass der schlafen geht, bevor die Daten vollständig 
raus sind - da hilft Serial.flush(), bevor dann
LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF); aus der "#include 
"LowPower.h" zuschlägt.

Lothar schrieb:
> Das bedeutet aber doch, wenn sich z.B. das serielle Kabel lösen würde, hängt 
sich hier das Programm auf.

Das tut es hier nicht, Daten gehen stumpf raus, ob etwas dran hängt oder 
nicht, ist egal.

von Lothar (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:
> Was willst du wirklich erreichen?

Also wenn Du wirklich helfen willst. Ich hatte doch geschrieben:

Lothar schrieb:
> Port von 8051 auf Arduino

Beim 8051 braucht es keinen Flush da kein Sendepuffer. Auf Arduino muss 
nun aber diese Flush Funktion aufgerufen werden. In der Flush Funktion 
hat man ein Loop ohne Timeout hinprogrammiert. Es braucht also eine 
Möglichkeit im Programm festzustellen ob diese Flush Funktion zu Ende 
ausgeführt wurde oder ob das Programm dort hängt.

Für sowas gibt es z.B. den Watchdog. Der würde aber einen Reset machen. 
Ich würde einen Fehler ausgeben wollen. Dafür könnte man einen Timer vor 
dieser Flush Funktion starten und danach stoppen. Wenn die Flush 
Funktion hängt zeigt sich das in der Timer ISR - Timer läuft schon zu 
lange.

Wenn Du eine bessere Lösung hast kannst Du es ja sagen.

Was keine Lösung ist: Natürlich hat die Flush Funktion beim Testen 
bisher noch nie gehangen. Dieser unwahrscheinliche Fall muss aber 
dennoch abgesichert werden. Meiner Meinung nach.

Warum man in der Arduino Software nicht einfach in Serial.flush auch den
Serial.setTimeout eingebaut hat - woher soll ich das wissen.

von Einer K. (Gast)


Lesenswert?

Lothar schrieb:
> Also wenn Du wirklich helfen willst.
Bei einer solchen Ansage, sagt meine Empfindung:
Du willst keine Irrtümer einsehen.

So können wir beide nicht zusammen kommen.


Lothar schrieb:
> Warum man in der Arduino Software nicht einfach in Serial.flush auch den
> Serial.setTimeout eingebaut hat - woher soll ich das wissen.

Ich kanns dir sagen: Weil es völlig Sinn befreit wäre das zu tun.


Lothar schrieb:
> Es braucht also eine
> Möglichkeit im Programm festzustellen ob diese Flush Funktion zu Ende
> ausgeführt wurde oder ob das Programm dort hängt.

Wenn Serial.flush() zurückkommt, ist es auch fertig.
Und es kommt auf jeden Fall zurück.
Es sei denn, die Interrupts sind abgeschaltet.
Und dann tuts auch dein Timer Interrupt nicht mehr
Das ist dann aber eine Dummheit des Programmierers.


Lothar schrieb:
> Dafür könnte man einen Timer vor
> dieser Flush Funktion starten und danach stoppen. Wenn die Flush
> Funktion hängt zeigt sich das in der Timer ISR - Timer läuft schon zu
> lange.
Habe ich dir schon widerlegt.

Lothar schrieb:
> Dieser unwahrscheinliche Fall muss aber
> dennoch abgesichert werden. Meiner Meinung nach.
Deine Meinung in Ehren.
Aber hier irrst du.



Klarer:
Du jagst deine eigenen Hirngespinste/Ängste ums Dorf.
(meine Meinung zu diesem Thema)


Nachtrag:
OK, der WDT kann hier seinen Einsatz bekommen.

von Kaj (Gast)


Lesenswert?

Lothar schrieb:
> Natürlich hat die Flush Funktion beim Testen
> bisher noch nie gehangen. Dieser unwahrscheinliche Fall muss aber
> dennoch abgesichert werden. Meiner Meinung nach.
Dann erklaere doch mal deine Meinung: Warum sollte flush(), deiner 
Meinung nach, haengen? Wie soll das gehen?

Schau doch mal bitte in das Datenblatt des uC, lies was die Flags der 
Schnittstelle machen und wie Schnittstelle ueberhaupt funktioniert. Dann 
wirst du (hoffentlich) verstehen, das du versuchst ein Problem loesen, 
das gar nicht existiert.

von Manfred (Gast)


Lesenswert?

Arduino Fanboy D. schrieb:
> Lothar schrieb:
>> Es braucht also eine
>> Möglichkeit im Programm festzustellen ob diese Flush Funktion zu Ende 
ausgeführt wurde oder ob das Programm dort hängt.
>
> Wenn Serial.flush() zurückkommt, ist es auch fertig.
> Und es kommt auf jeden Fall zurück .

Lothar will es nicht begreifen und ist wohl auch nicht in der Lage, das 
einfach zu probieren!

Ich schrieb es auch schon: Ich habe ein Gerät mit Serial.flush(), wo 
seit über einem Jahr keine Schnittstelle angeschlossen ist, da hängt 
nichts, das Ding funktioniert einfach vor sich hin. Die Daten gehen ins 
Nirgendwo, der ProMini geht schlafen ... wäre das anders, wäre alle paar 
Tage mein Akku leer.

von Lothar (Gast)


Lesenswert?

Ich habe durchaus schon einiges probiert um zu sehen was da vor sich 
geht. Wenn ich das so mache, dann würde ich erwarten, dass spätestens 
nach dem delay das Byte raus ist:

Serial.write(msg[0]);
delay(1000);

Ist aber nicht so, erst mit flush geht das Byte raus:

Serial.write(msg[0]);
Serial.flush();
delay(1000);

Das ist wohl so wegen dem Sendepuffer in der Arduino Software. Aber 
selbst das hier ändert daran nichts:

#define SERIAL_TX_BUFFER_SIZE 1

https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/HardwareSerial.h

von Kaj (Gast)


Lesenswert?

Zeig doch bitte mal ein minimales, compilierbares Beispiel, das deinen 
"Problem" zeigt.

Beitrag #5596115 wurde von einem Moderator gelöscht.
von Einer K. (Gast)


Lesenswert?

Lothar schrieb:
> Wenn ich das so mache, dann würde ich erwarten, dass spätestens
> nach dem delay das Byte raus ist:
>
> Serial.write(msg[0]);
> delay(1000);
>
> Ist aber nicht so, erst mit flush geht das Byte raus:

Das kann ich nicht bestätigen.
Meine Tests zeigen, dass Serial keine Bytes zurückhält.
Alles wird sobald wie möglich Ausgegeben.

von Thomas W. (diddl)


Lesenswert?

Arduino Fanboy D. schrieb:
> Das kann ich nicht bestätigen.
> Meine Tests zeigen, dass Serial keine Bytes zurückhält.
> Alles wird sobald wie möglich Ausgegeben.

richtig


Das flush() bewirkt nur, dass die Ausführung des Code anhält bis das 
letzte Zeichen gesendet wird.

Der Controller wartet bis der Sendebuffer wieder frei ist.

von Lothar (Gast)


Lesenswert?

Thomas W. schrieb:
> dass die Ausführung des Code anhält bis das
> letzte Zeichen gesendet wird

Also ich habe mal gelernt dass es - egal ob bei PC Programmierung oder 
Mikrocontroller - keine Funktion geben darf die das Programm anhält und 
auf etwas wartet. Das ist Busy Waiting und das macht man nicht.

Wenn ich bei der PC Programmierung eine Bibliothek mit so einer Funktion 
habe dann muss ich entweder dafür einen neuen Thread aufmachen damit das 
Hauptprogramm nicht hängen bleiben kann. Oder einen Timeout Timer.

Bei Mikrocontroller habe ich mit Serial.flush jetzt zum ersten Mal eine 
Funktion gesehen die ein Busy Waiting while drin hat.

> Der Controller wartet bis der Sendebuffer wieder frei ist

Also wenn ich das Datenblatt richtig verstanden habe ist das nicht so. 
Der Controller hat nur ein Byte Senderegister. Wenn es dort rausgeht 
gibt es ein Polling Flag oder einen Interrupt falls aktiv. Das hält das 
Programm nicht an.

Serial.flush verwendet aber einen 64 Byte Sendebuffer in Software. 
Daneben steht übrigens dieser Kommentar: "We're using a ring buffer (I 
think)"

https://github.com/arduino/ArduinoCore-avr/blob/master/cores/arduino/HardwareSerial.h

von Thomas W. (diddl)


Lesenswert?

Lothar schrieb:
> Serial.flush verwendet aber einen 64 Byte Sendebuffer in Software.

Ich meinte mit "Sendebuffer" schon den 64 Byte Sendebuffer

Lothar schrieb:


> Also ich habe mal gelernt dass es - egal ob bei PC Programmierung oder
> Mikrocontroller

Da gebe ich dir schon recht.

Aber trotzdem gibt es Fälle wo es durchaus Sinn macht, zu warten ...

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Lothar schrieb:
> Bei Mikrocontroller habe ich mit Serial.flush jetzt zum ersten Mal eine
> Funktion gesehen die ein Busy Waiting while drin hat.

Das gibt's doch ständig. Alle möglichen Bibliotheken für Displays, 
SD-Karten und somit auch FAT-Libraries, I²C und darauf basierende 
Komponenten machen das so; insbesondere im Arduino-Umfeld. Selbst 
analogRead wartet, bis eine ADC-Wandlung abgeschlossen ist. Das ist m.E. 
der Hauptgrund, warum Embedded-Bibliotheken oft schlecht skalierbar bzw. 
wiederverwendbar sind - wenn mehrere davon blockierende Funktionen 
haben, beeinflussen die sich gegenseitig bzw. brauchen einfach zu viel 
Zeit. Daher werden ja auch oft RTOS genutzt, um das Problem zu 
umgehen...

Lothar schrieb:
> Ist aber nicht so, erst mit flush geht das Byte raus:
>
> Serial.write(msg[0]);
> delay(1000);

Ist vielleicht das delay(1000) zu kurz um auf alles zu warten? Setze vor 
dem delay mal einen Pin, schließe ein Oszilloskop an diesen sowie den 
UART-TX-Pin an und schau ob danach alles raus kommt.

: Bearbeitet durch User
von Lothar (Gast)


Lesenswert?

Niklas G. schrieb:
> analogRead wartet, bis eine ADC-Wandlung abgeschlossen ist

Habe ich bisher noch nicht genutzt aber - echt jetzt? Ich würde das so 
machen dass ein analogRead den ADC startet und spätestens nach Timeout 
eine globale Variable zurückgibt und diese globale Variable wird in 
einer ISR vom ADC geupdatet wenn der fertig ist. Alles was dann 
passieren kann ist dass analogRead noch den alten Wert zurückgibt wenn 
der ADC noch nicht fertig war. Aber hängen kann es dann nicht.

Wenn ich analogRead mal verwende würde ich dann auch sicherheitshalber 
einen Timeout Timer nutzen. Wie ich das bei Serial.flush auch grade 
versuche.

Thomas W. schrieb:
> Aber trotzdem gibt es Fälle wo es durchaus Sinn macht, zu warten ...

Schon möglich aber mein Hauptprogramm muss noch andere Dinge 
zeitkritisch erledigen. Wenn es auf die serielle Schnittstelle warten 
muss dann wenigstens mit Timeout.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Lothar schrieb:
> Habe ich bisher noch nicht genutzt aber - echt jetzt?

Ich würde die Referenz so verstehen:
https://www.arduino.cc/reference/en/language/functions/analog-io/analogread/

It takes about 100 microseconds (0.0001 s) to read an analog input, so 
the maximum reading rate is about 10,000 times a second.

Lothar schrieb:
> Ich würde das so
> machen...
Und dann beschwert sich wer, dass das API suggeriert, der ADC sei 
schneller als er tatsächlich ist...

Lothar schrieb:
> Wenn ich analogRead mal verwende würde ich dann auch sicherheitshalber
> einen Timeout Timer nutzen. Wie ich das bei Serial.flush auch grade
> versuche.
Das muss auch ohne gehen. Einen Timer nur für den UART abzustellen ist 
overkill...

von Einer K. (Gast)


Lesenswert?

Gerade das Arduino Framework (ich nenne es mal so) zielt auf schnelle 
Erfolge für unbedarfte Anwender.
Liefert Komfort Funktionen für ein breites Spektrum an µC.

Will man was spezielles, muss man es selber bauen.

Klarer:
Wenn dir die Serial Klasse nicht gefällt, dann nutze sie nicht!
Bau dir was eigenes.

Serial.print() und seine Brüder sind auch blockierend, wenn der 
Ringpuffer voll ist.
Kehren also erst zurück, wenn alle übergebenen Zeichen im Ringpuffer 
versenkt werden konnten.

Serial.availableForWrite() sagt dir wieviel Platz noch im Ringpuffer 
ist.
Zusätzlich könnten noch ein(zwei?) Byte im UART Sendepuffer stecken.


---
analogRead() ist wirklich recht primitiv.
Nutzt kaum die Fähigkeiten der verschiedenen AVR ADC aus
Hat sogar noch einen Fehler im Bauch, bei der ADC Vorteiler Berechnung.
Bei 1,  8 und 16MHZ ist alles OK, aber bei krummen Frequenzen, z.B. bei 
einem Baudrate Quarz kanns klemmen.

Wenn du möchtest, kann ich dir eine "verbesserte" ADC Lib zukommen 
lassen.

von Kaj (Gast)


Lesenswert?

Lothar schrieb:
> Also ich habe mal gelernt dass es - egal ob bei PC Programmierung oder
> Mikrocontroller - keine Funktion geben darf die das Programm anhält und
> auf etwas wartet. Das ist Busy Waiting und das macht man nicht.
>
> Wenn ich bei der PC Programmierung eine Bibliothek mit so einer Funktion
> habe dann muss ich entweder dafür einen neuen Thread aufmachen damit das
> Hauptprogramm nicht hängen bleiben kann. Oder einen Timeout Timer.
Das ist so pauschal ja erstmal Unfug. "Ich hab das mal so gelernt...", 
hast du das auch mal hinterfragt? Ganz einfaches Beispiel:

Ein Konsolenprogramm das eine Nutzereingabe erwartet. Natuerlich 
blockiert das Programm an der stelle und wartet bis der Nutzer seine 
Eingabe gemacht hat. Warum sollte man fuer sowas einen Thread aufmachen 
(und was soll der Rest des Programms in der Zeit machen?), oder 
irgendwelche Timer nutzen? Wenn das Programm ohne Nutzereingabe nicht 
weitermachen kann, dann muss es halt an der Stelle warten.

von Michael U. (amiga)


Lesenswert?

Hallo,

natürlich kann man auch auf einem Microcontroller einen Timer laufen 
lassen, der zyklisch nachschaut, ob der Sendebuffer endlich leer ist.
Dazwischen kann man entweder in der loop() auf die Fertigmeldung des 
Timer warten (wie sinnvoll in disem Fall...), man kann natürlich auch in 
der Wartezeit auch die Mining-Funktiuon für die Bitcoins laufen lassen..

PS: mir fällt in vielen Arduinoprogrammen auf, daß die serielle stur auf 
den default 9600 Baud gelassen wird. 38400 und 76800 gehen mit der 
gleichen geringen Fehlerrate, 115200 üblicherweise auch noch, obwohl der 
Fehler da mit 2,1% dicht an der Grenze ist.

Schon bei 38400 ist der Sendebuffer in einem viertel der Zeit leer...

Gruß aus Berlin
Michael

von Einer K. (Gast)


Lesenswert?

Michael U. schrieb:
> natürlich kann man auch auf einem Microcontroller einen Timer laufen
> lassen, der zyklisch nachschaut, ob der Sendebuffer endlich leer ist.
> Dazwischen kann man entweder in der loop() auf die Fertigmeldung des
> Timer warten (wie sinnvoll in disem Fall...), man kann natürlich auch in
> der Wartezeit auch die Mining-Funktiuon für die Bitcoins laufen lassen..

Ja und nein...
Im Falle Arduino wird der SendePuffer auf jeden Fall irgendwann leer.
Es sei denn die Interrupts sind aus, aber dann hilft auch kein Timer 
Interrupt mehr.

Michael U. schrieb:
> PS: mir fällt in vielen Arduinoprogrammen auf, daß die serielle stur auf
> den default 9600 Baud gelassen wird. 38400 und 76800 gehen mit der
> gleichen geringen Fehlerrate, 115200 üblicherweise auch noch, obwohl der
> Fehler da mit 2,1% dicht an der Grenze ist.

Einerseits hast du natürlich recht...
Aber ist denn immer eine hohe Geschwindigkeit sinnvoll?

Ok.. die Kabellänge spielt keine Rolle, wenn der USB Adapter mit auf dem 
Board steckt.

Andererseits gibt es auch keine Flusskontrolle, weder in Hardware, noch 
Software. Da kann es schon passieren, dass die Verarbeitungszeiten auf 
dem µC zu lang sind, um hohe Datenraten zu verarbeiten.

Und das letzte, vielleicht (für mich) wichtigste Argument, für dauerhaft 
9600Baud, man muss nicht dauernd umstellen.

Aber, wie fast immer:
Die Anforderungen bestimmen die Grenzen und sinnvollen Werte.

von Lothar (Gast)


Lesenswert?

Kaj schrieb:
> Ein Konsolenprogramm das eine Nutzereingabe erwartet

Auf einem Mikrocontroller? Und da soll nix währenddessen passieren? Wie 
Batterie prüfen, irgendwelche I/Os nachsehen. Hatte ich noch nie. Ich 
habe z.B. aktuell - nicht auf Arduino - einen PID-Regler dem man seriell 
die Parameter ändern kann. Das wäre nicht so gut wenn der während der 
seriellen Kommunikation nix macht.

Beim PC ist es sogar zwingend für serielle Kommunikation einen Timeout 
oder Thread zu machen. Führt zwar jetzt hier zu weit aber damit das 
Programm nicht hängt oder merkwürdige Sachen macht braucht es entweder - 
einfach - DoEvents oder - mehr Aufwand aber gerne gesehen - Invoke: 
asynchroner Thread.

Die einzige Möglichkeit das zu vermeiden wäre das Konsolenprogramm in 
eine Datei schreiben zu lassen und das davon getrennte Hauptprogramm die 
Datei zu prüfen und es dort wenn fertig abzuholen. Das ist aber nicht 
mehr modern.

von Michael U. (amiga)


Lesenswert?

Hallo,

Arduino Fanboy D. schrieb:
> Michael U. schrieb:
>> natürlich kann man auch auf einem Microcontroller einen Timer laufen
>> lassen, der zyklisch nachschaut, ob der Sendebuffer endlich leer ist.
>> Dazwischen kann man entweder in der loop() auf die Fertigmeldung des
>> Timer warten (wie sinnvoll in disem Fall...), man kann natürlich auch in
>> der Wartezeit auch die Mining-Funktiuon für die Bitcoins laufen lassen..
>
> Ja und nein...
> Im Falle Arduino wird der SendePuffer auf jeden Fall irgendwann leer.
> Es sei denn die Interrupts sind aus, aber dann hilft auch kein Timer
> Interrupt mehr.
Das bezig sich einerseits auf den Ausgangspunkt, daß man den AVR 
schalfen schicken will, da ist dann auf Dauer direkt Batteriekapazität.

>
> Michael U. schrieb:
>> PS: mir fällt in vielen Arduinoprogrammen auf, daß die serielle stur auf
>> den default 9600 Baud gelassen wird. 38400 und 76800 gehen mit der
>> gleichen geringen Fehlerrate, 115200 üblicherweise auch noch, obwohl der
>> Fehler da mit 2,1% dicht an der Grenze ist.
>
> Einerseits hast du natürlich recht...
> Aber ist denn immer eine hohe Geschwindigkeit sinnvoll?
>
> Ok.. die Kabellänge spielt keine Rolle, wenn der USB Adapter mit auf dem
> Board steckt.
> Andererseits gibt es auch keine Flusskontrolle, weder in Hardware, noch
> Software. Da kann es schon passieren, dass die Verarbeitungszeiten auf
> dem µC zu lang sind, um hohe Datenraten zu verarbeiten.

Mit 115200 habe ich real auch nie ein Problem gehabt, wenn der 
USB-Wandler per Dupontkabeln o.ä. angeschlossen war. Von ewig langen 
Leitungen rede ich hier natürlich nicht, eben für Debug-Zwecke.
Ich habe schon mehrfach den Zustand gehabt, daß zu umfangreiche 
Debug-Ausgaben letztlich meinen Ablauf ausgebremst haben. Auch 
Serial.print() wartet, wenn der Sendebuffer voll ist...

Die Verarbeitungszeit spielt erst beim Empfangen eine Rolle, wenn mehr 
Zeichen kommen als der serielle Buffer aufnehmen kann ohne daß sie 
abgeholt werden.
Beim Senden muß der Empfänger damit klarkommen. Wenn ich auf dem AVR 
eben nur selten Bytes sende, sind die Pausen dazwischen eben länger.

> Und das letzte, vielleicht (für mich) wichtigste Argument, für dauerhaft
> 9600Baud, man muss nicht dauernd umstellen.
Ist jeweils meine erste Änderung in fremden Sketchen, die ArduinoIDE 
merkt sich das sowieso und steht damit immer auf den 115200...

> Aber, wie fast immer:
> Die Anforderungen bestimmen die Grenzen und sinnvollen Werte.

So ist es.

Gruß aus Berlin
Michael

Das gilt sowieso immer

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.