Beeinflusst Serial.print mein Programm negativ?

Ich programmiere noch nicht lange Arduinos. In meinem code sind meist sehr viele Serial.print(ln) um zu sehen und verstehen was passiert.
Nun frage ich mich ob diese Serial.print mein Programm negativ beeinflussen? Sollte man diese Programmzeilen später wieder entfernen? Sollte man alle entfernen oder ist es ok ein paar drin zu lassen?

Serial Ausgaben brauchen Zeit, wenn du mehr auszugeben versuchst als übertragen werden kann. (Bei 9600 1 Zeichen/ms)
Gibst du weniger aus, und der Ausgabepuffer wird nie randvoll, bremst Serial nicht merklich.

  1. Serial.print braucht Zeit. Für die Zeit der Sendung ist Arduino beschäftigt. Um Zeit zu sparen kann man mit einer höheren Baudrate arbeiten. Die neue Baudrate muß auf Sender und Empfängerseite eingestellt werden.

  2. Serial print ("text") braucht RAM. Serial.print(F("Text")); nimmt den Text aus dem FLASH ohne in RAM zwischenspeichern ( gilt für Strings , nicht für Variablen der Zahlen.

Ja, es ist besser serielle Ausgaben in einem endgültigen Sketch zu entfernen, wenn sie nicht gebraucht werden. Das gilt aber für jeglichen Code der nicht gebraucht wird.

Grüße Uwe

(deleted)

Bist Du sicher daß diese Geschwindigkeit unterstützt wird?
Grüße Uwe

(deleted)

Ich würde eine so hohe Baudrate nicht verwenden. Sie ist nicht 100% betriebssicher und es besteht auch keine Notwendigkeit sich so hohe Werten zu nehmen.
Grüße Uwe

Für die Zeit der Sendung ist Arduino beschäftigt

Hardwareserial nutzt extra Hardware, die sonst nichts zu tun hat.
Wenn du nur so viel ausgibst wie du auch mitlesen kannst, spielt die Geschwindigleit keine Rolle.

Wenn eine hohe Baudrate tatsächlich gebraucht wird, ist alles anders und deine Frage mit "weg damit" zu beantworten.

@Uwe:
Warum bietet denn Arduino in der IDE diese Baudrate an, wenn sie nicht betriebssicher ist? das setzt doch dann nur wieder eine mögliche Fehlerquelle , die u.U. eine langwierige Fehlersuche auslösen kann, weil man dann ja gar nciht damit rechnet, dass das Programm nur wegen der Baudrate für die COM mit dem Serialmonitor spinnt.
Dann sollte die IDE oder der Compiler eigentlich eine Warnung ausgeben, dass es nicht betriebssicher ist, diese Baudrate zu verwenden.

LG Stefan

Die Baudrate entspricht der Frequenz der Übertragenen Bits. Bei einer Baudrate von 2 000 000 sind das 2Mhz. Wenn man die auf irgendwelche zufälligen Kabel losläßt kann einiges unerwünschte wie falsche Datenübertragung passieren. Bei der seriellen Schnittstelle ist normalerweise keine Kontrolle aktiviert.

Grüße Uwe

Welche Baudrate zuverlässig funktioniert häng von der Software/Hardware ab. Theoretisch ist die Baudrate über USB egal. Hast du einen USB->UART Wandler, schaut's schon anders aus. Wobei Atmel besser funktioniert als STM32. BluePill kriegt regelmäßig Schluckauf ab 9600 Baud ohne Hardwarehandshake.

wenn sie nicht betriebssicher ist?

Du bist verwirrt!

Natürlich ist die Baudrate völlig ok.
Und ebenso natürlich, können IDE und AVR damit prächtig umgehen.
(einzig für die Butter muss man dann selber Sorge tragen)

Problem 1 lauert an ganz anderer Stelle.
Da keinerlei Handshake/Protokoll verwendet wird, besteht jederzeit die Gefahr, dass irgendwelche Buffer überlaufen, und dieser Überlauf nicht korrekt behandelt wird.
Und natürlich ist die Gefahr bei höherer Baudrate eben auch größer.

Problem 2 hat Uwe ganz gut beschrieben.
Wobei die Verbindung auf einem UNO oder Mega kurz genug ist, um diese Sorge zu mildern.
Auch die üblichen Widerstände auf dem Board, zwischen ATMega2560 und ATMega16U2 verdienen Beachtung. Einerseits gut, dass sie da sind (gegen Rauch), auch gut, dass sie Reflektionen dämpfen.
Aber dass sie die Anstiegsflanken verschleifen, dass muss nicht so gut sein.

Also Vorsicht mit der Porzellankiste!

Die Baudrate/Uart(Kutsche) ist also nicht das Problem, sondern das Porzellan!
Fein in Butter eingießen, dann überlebt auch das Geschirr.

Z.B. verwendet man bei hohen Datenraten eher Differenzialschaltungen USB - SATA - LVDS
Auch bei langen Strippen Ethernet - RS485 - RS422 - SCSI

(deleted)

Wobei Atmel besser funktioniert als STM32. BluePill kriegt regelmäßig Schluckauf ab 9600 Baud ohne Hardwarehandshake.

Dann machst du was falsch!

z.B. DMA nicht verwenden
Oder sonst was .....

Denn natürlich ist der STM32F103 um Größenordnungen leistungsfähiger als die genannten AVR.
Auch in Sachen serieller Anbindung.

Hierzu verwende ich das mitgelieferte blaue USB-Kabel.

Die eingestellte Baudrate hat keinen Bezug zum USB Kabel.

(deleted)

Aber das Kabel auf eine Nichtfunktionlität der seriellen Schnittstelle....

Nur auf USB, nicht auf die Serielle, wofür eben die Baudrate zuständig ist.
Das ist eine Nebelkerze.

Wenn das Kabel mit der 9600er Einstellung läuft, dann tuts auch die 2MHz Einstellung perfekt.

Ich wiederhole:

Die eingestellte Baudrate hat keinen Bezug zum USB Kabel.

(deleted)

zwieblum:
Theoretisch ist die Baudrate über USB egal.

Wenn Du einen Prozessor mit nativer USB-HW hast, z.B. mega32u4 oder STM32F103 ( und diese Schnittstelle nutzt ), dann ist das auch ganz praktisch so. Dann muss noch nichtmal der Wert in Serial.begin und im seriellen Monitor übereinstimmen.

Peter-CAD-HST:
Und ich hatte immer angenommen das USB auch eine serielle Schnittstelle ist.

Bitte keine Haarspaltereien. Hier weis doch jeder, das mit 'serieller Schnittstelle' immer die UART gemeint ist. Ansonsten gibt's noch viele andere 'serielle' Schnittstellen :wink:

Peter-CAD-HST:
Dann hab ich was verpasst.
Und ich hatte immer angenommen das USB auch eine serielle Schnittstelle ist.

Mag sein, dass du was verpasst hast!
Denn USB ist sehr wohl seriell, aber hat keine einstellbare Baudrate, sondern eine fixe (vom jeweiligen Standard abhängige) Datenrate.

Es macht also keinen Unterschied ob du 1200Baud, oder 2000000Baud einstellst.
Die Daten auf dem USB Kable sind gleich schnell, bzw gleich getaktet.

So ...

Habe mir das Eingangsposting nochmal ernsthaft durchgelesen!

Mir fällt auf:
Das (scheinbare) Problem taucht auf, wenn man dein großes Programm mit endlos vielen Ausgaben pflastert.
Da kann man zwar mit einer höheren Baudrate gegen an gehen, aber mehr als ein Flicken ist das nicht.

Da möchte ich eine wirksame Strategie empfehlen:

Das Programm in Module aufteilen.
Diese Module einzeln und umfangreich testen.

Leitmotiv:
Getestete Sachen sind in Ordnung!
Taucht später ein Fehlverhalten auf, liegt es nicht an dem Modul, oder der Test war Mist.

Im Endeffekt kostet es viel Zeit und Gehirnschmalz diese Tests durchzuführen.
Ist aber dennoch effektiver als Programme als Ganzes in der Tiefe zu debuggen.
(wie man auch schon an der Eingangsfrage sieht)

Der positive Effekt:
Man erhält einen prallen Werkzeugkasten, gefüllt mit hervorragend gut getesteten Modulen.
Das erleichtert die spätere Arbeit ungemein.

Aus dem gerade präsentiertem Blickwinkel:

Sollte man diese Programmzeilen später wieder entfernen?

Ja, wenn der jeweilige Einzeltests abgeschlossen ist, ja, auf jeden Fall.
Im fertigen Programm ist dann keine einzige (ablenkende) Debugzeile mehr.