Ich weiss auch nicht wieso die meisten Leute mit Daten-, Parity- und Stop-Bits und der Baudrate überfordert sind?
Ich bin jetzt seit 1976 beruflich mit der Entwicklung beschäftigt und die serielle Schnittstelle war immer für die meisten ein Horror, auch für Techniker und Ings.
Vermutlich weil man auf beiden Seiten 4 Parameter gleich einstellen muss, damit die Verbindung funktioniert. Nur mit kindlichem Rumspielen bekommt man es eben meist nicht hin.
Hinzu kommt noch, dass es oft mehr als nur 3 Drähte benötigt, da sind noch ein paar Statusleitungen, welche man im einfachsten Fall brücken muss, damit der Sender überhaupt etwas sendet.
tatsächlich reden wir hier über die Arduino Serial Class und den Arduino UART pins mit nur 2 Kabeln, nämlich TX und RX (und GND), und da brauchen wir uns ja gottseidank um start, stop und parity keine Gedanken zu machen und ich sehe da auch keine Verbindung zu "kindlichem Rumspielen", dafür wurde das Arduino-Serial ( per "Wiring") ja schließlich genau so konzipiert.

[quote] Ob Default-Werte sinnvoll sind, wurde nicht gefragt, [!quote]
Doch, eigentlich war genau das gemeint mit "keine Ahnung, warum auch immer von allen Leuten 9600 benutzt wird....", das bezog sich aufs default 9600 wie Arduino es eingestellt hat und auch auf die sehr häufig unveränderte Übernahme ins eigene Programm

wäre es besser, den Datenstrom am Arduino runterzuregeln durch delays oder millis, und nicht dem Bus am Arduino mit Gewalt (Serial.begin(2400) ) den Hahn zuzuquetschen bis nichts gar mehr reingeht
Und wo liegt der Unterschied?
Mit beiden varianten wird die nutzbare Bandbreite begrenzt. Nur kommt die Herabsetzung der Baudrate ohne zusätzlichen Code aus und lässt sich auch einfach wieder aufheben. Bei Geräten, bei welchen man keinen Einfluss auf den Code hat, ist das Herabsetzen der Baudrate die einzige Möglichkeit, wenn ein Empfänger "überfahren" wird. Wobei es eigentlich noch die genormten Handshakes gäbe!
Der Unterschied ist, dass das Arduino Programm jede Mengen Daten versucht in den Serial Buffer reinzuschaufeln, der aber die ganze Ladung nicht durchschaufeln kann bei 2400 baud, sodass der Serial Buffer ständig überläuft. Es werden also unnütz viele Daten produziert, die sich vor dem Serial Buffer stauen, überlaufen und verloren gehen (für dev0, wie i_make_it richtig schrieb). Also war der Vorschlag, die Daten-Masse durch delays etc. zu begrenzen, wenn eh auf der anderen Seite nur ein Bruchteil verarbeitet werden kann - dann kann man ja immer noch mit 2400 baud übertragen aber hat vor den Serial- und Processing-Engpässen nicht ganz so viel Müll produziert.