Hi zusammen,
nur mal so ne lockere Frage zwischendurch:
Haben serielle Ausgaben (also z.B. Serial.print() oder Serial.println()) eigentlich irgendeine Auswirkung auf die Performance oder allgemein auf das Verhalten des Mikrocontrollers?
Wenn ich eine "Firmware" fertig habe, sollte ich dann auf den "Serienmodellen" die serielle Ausgabe abschalten oder ist das völlig egal?
LG
Daniel
Natürlich. Neben dem zusätzliche Speicherverbrauch, benötigt die Ausgabe von Daten selbstverständlich auch Rechenzeit. Je langsamer die eingestellte Baudrate ist, desto mehr Zeit vird verbraucht.
Es ist demnach ratsam, serielle Ausgaben die nicht mehr benötigt werden, im Produktionscode zu deaktivieren.
in so einem Fall einfach selber mesen:
void setup()
{
Serial.begin(115200);
delay(500);
Serial.println(F("Start..."));
uint32_t startmicros = micros();
const char text[] = "Ausgabetext mit einer gewissen Länge";
for (byte b = 0; b < 255; b++)
{ Serial.println(text); }
uint32_t endmicros = micros();
Serial.print(F("Start bei: "));
Serial.println(startmicros);
Serial.print(F("Ende bei: "));
Serial.println(endmicros);
Serial.print(F("Laufzeit: "));
Serial.println(endmicros - startmicros);
delay(3000);
startmicros = micros();
for (byte b = 0; b < 255; b++)
{ Serial.println(); }
endmicros = micros();
Serial.print(F("Start bei: "));
Serial.println(startmicros);
Serial.print(F("Ende bei: "));
Serial.println(endmicros);
Serial.print(F("Laufzeit nur \\r\\n: "));
Serial.println(endmicros - startmicros);
}
void loop()
{
}Hier findest Du ein Beispiel mit dem einfachen Ein/Ausschalten von Debugausgaben.
Ganz wesentlich dafür, wie stark die Auswirkungen sind, ist es, ob der Puffer der seriellen Schnittstelle vollläuft. Normalerweise schreiben die Serial.xxx() Befehle die zu sendenden Daten nur in den Sendepuffer und kehren daher recht schnell wieder zurück. Da sind die Auswirkungen auf die Performance rel. klein. Das eigentlich Senden geschieht dann in einem Interrupt, der die Daten aus dem Puffer liest, und an die Sende HW übergibt. Wie schnell das Leeren des Puffers geht, hängt von der Baudrate ab. Bei den häufig verwendeten 9600 Baud kann nur ca jede ms ein Zeichen aus dem Puffer wieder gelöscht werden. Bei längeren Texten dauert das also.
Kritisch wird es, wenn man so oft Serial.print() aufruft, dass der Puffer volläuft. Dann wartet der Aufruf so lange, bis wieder Platz ist. Und dann sind die Auswirkungen auf die Performance schon recht massiv. Das kann das Verhalten des Sketch vollkommen verändern.
Der Speicherverbrauch ist eigentlich weniger wichtig, solange es noch ausreichend ist. Wenn nicht hat man ja schon während der Entwicklung beim Debugging Probleme.
Wenn ich nichts abhole, würde das ja bedeuten, das an der Stelle stehen geblieben würde.
Wer sorg jetzt dafür, das das nicht passiert?
Da muss ja irgendwo ein timeout drin stecken.
Wir reden hier doch vom Senden. Da erledigt das Abholen der Interrupt, der Teil der Serial Klasse ist. Das kann man nur unterbinden, indem man die Interrupts abschaltet, was dann aber sowieso zu massiven Problemen führt.
Das ist ja auch ein Grund, weshalb man keine Serial.xxx Befehle innerhalb von ISR's verwenden darf. Wenn da der Puffer vollläuft ist Schluß, den während einer ISR sind andere Interrupts abgeschaltet.
Noch einmal nachdenken, bitte!
Ein Programm aus meiner Wühlkiste:
Vielleicht hilfts ja irgendwem....
Als Ausgabemedium kann hier alles dienen, welches das Print Interface implementiert.
#include <Streaming.h> // die Lib findest du selber ;-)
Print &cout = Serial; // cout Emulation für "Arme"
struct Logger: Print
{
Print *print {nullptr};
Print *operator=(nullptr_t) {return print = nullptr;}
Print *operator=(Print &p) {return print = &p;}
virtual size_t write(const byte data) override
{
size_t anzahl {1};
if(print) anzahl = print->write(data);
return anzahl;
}
};
Logger logger;
void setup()
{
Serial.begin(9600);
logger = Serial; // aktivieren
logger << F("Start: ") << F(__FILE__) << endl;
logger = nullptr; // deaktivieren
logger << "Diese Meldung siehst du nicht" << endl;
logger << "Diese Meldung auch nicht" << endl;
logger = Serial; // aktivieren
logger << "Diese Meldung siehst du" << endl;
logger << "Diese Meldung siehst du auch" << endl;
logger.println(42);
}
void loop()
{
}
Ich hätte es jetzt einfach so gemacht:
#define DEBUG false
void setup() {
#if DEBUG
Serial.begin(115200);
#endif
}
Sollte dann irgendwo ein Serial.println() stehen, sollte das ja dann wirkungslos sein, oder?
Leider nein, das wäre schön einfach.
Als Grundlage #4 reduziert die Zeit für Serial um ungefähr ein Zehntel ohne Serial.begin, also besser, aber 64 ms bleiben dann doch als unnütze Zeit. Getestet mit einem Nano, ist aber egal.
Daher ist die bedingte Kompilierung doch besser.
Das ist nicht so einfach.
Je höher die Baudrate ist, desto häufiger ist der controller in der ISR, um ein neues Zeichen an den UART weiterzugeben.
Was man wirklich als Verzögerung bemerkt, ist ein voller Ausgabepuffer, der die Stream::write() Methode zum Hängen bringt. Und das kann (statt die Ausgaben vernünftig einzuschränken) natürlich durch höhere Baudraten vermieden oder verkürzt werden.
Aber wenn man nicht schneller sendet als verzögerungsfrei auf die Leitung passt, ist man mit 500 Zeichen/s (auch bei 9600) natürlich schneller als mit 5000 Zeichen/s bei 115200.
...flutet den armen kleinen Ausgabepuffer gewaltig. Das sollte man schon während der Entwicklungsphase vermeiden.
Aber dass auch ohne Serial.begin() die Serial.print Anweisungen merklichen Overhead verursachen, ist gut zu wissen.
Um mehr Informationen als im Normalbetrieb vorgesehen zu erhalten, wäre es doch hübsch, einfach bei Bedarf den SerialMonitor an USB zu aktivieren. (Schlimm genug, dass das einen Reset auslöst, wenn man nicht aufpasst.)
Hallo,
wenn die Ausgabe nicht mehr nachkommt passiert noch viel Schlimmeres. Die gesamte IDE schmiert ab bzw. friert ein. Weder das Terminal noch die IDE kann man schließen. Ich vermute ein Java Problem. Weil wenn nur der Controller hängt hat ja das Terminal / IDE damit nichts zu tun. Da hilft nur per Taskmanager alles abschießen. Wer sowas erwartet sollte nicht das IDE Terminal verwenden sondern was anderes wie hterm oder so. Das löst mit Connect/Disconnect auch keinen Controller Reset aus.
Das würde ich nicht so sehen. In den meisten Fällen sind zur Entwicklung und zur Fehlersuche mehr Ausgaben erforderlich, als im laufenden "Produktionsbetrieb". Da halte ich eine bedingte Compilierung z.B. mit Debugmacros durchaus für sinnvoll.
Beispiel:
#define DEBUG 1
#if (DEBUG == 0)
#define dbgp(...) // Serial.print
#define dbgpn(...) // Serial.println
#if defined ESP8266 || defined ESP32
#define dbgpf(...) // Serial.printf nur auf ESP definiert
#endif
#define dbgbeg(...) // Serial.begin
#else
#define dbgp(...) Serial.print(__VA_ARGS__)
#define dbgpn(...) Serial.println(__VA_ARGS__)
#if defined ESP8266
#define dbgpf(...) Serial.printf(__VA_ARGS__)
#else
#define dbgpf(x, ... ) {char dbgBuf[80]; snprintf_P( dbgBuf, sizeof(dbgBuf), PSTR( x ), ##__VA_ARGS__ ) ; Serial.println( dbgBuf ); }
#endif
#define dbgbeg(...) Serial.begin(__VA_ARGS__)
#endif
Gruß Tommy
Habe ich so noch nicht erlebt. Ich wüsste auch nicht, wie die IDE das überhaupt mitbekommen sollte. Wenn die Ausgabe den Sendepuffer vollschreibt, heißt das aus Sicht der IDE doch nur, dass ständig Daten kommen. Das sollte die abkönnen - zumindest bei den üblichen Baudraten.
Sehe ich auch nicht so. Ich habe Sketche, die sind so groß, dass der Speicher nicht ausreicht um an allen sinnvollen Stellen Debugausgaben zu machen. Da habe ich verschiedene Debug-defines drin, um beim Testen immer nur an den jeweils relevanten Stellen die Debugausgaben zu aktivieren. Es sind also sowieso immer ein Teil der 'Testausschriebe' stillgelegt. Und ich sehe nicht, dass da was faul ist.
Ausserdem gibt es gegbenenfalls ja auch noch die 'produktiven' Serial Ausgaben, die man im Normalbetrieb nicht von Testausgaben unterbrechen möchte.
Du widersprichst eher meinem zweiten Satz "Es wäre doch hübsch, ..."
Kann man natürlich so sehen, dass es Sachen gibt, die nach der Inbetriebnahme keinen mehr was angehen.
Genauso wie der erhöhte Speicherbedarf kein Argument ist, sollte unmerklich verminderte Performance egal sein bei einem Sketch, der die allermeiste Zeit feststellt, dass nichts zu tun ist.
Mit den 16 MHz eines "normalen" Arduino hat man für hier übliche Anwendungen mehr als reichlich Leistung.
Ob die meisten DEBUG Ausgaben während der Entwicklung es wert sind, für immer in einem #ifdef konserviert zu zu werden, ist eine andere Frage.
Das habe ich nicht bedacht. Stimmt !
Hallo,
warum immer die alten Makros? Warum nicht ...
constexpr bool DEBUG {true};
...
if (DEBUG) { Serial.print ... }
...
Das abschmieren der IDE + eigenes Terminal kann ich jederzeit provozieren. Einfach ohne Pause irgendwelche Daten ausgeben lassen. Nach paar Sekunden geht nichts mehr. Der Rechner ist noch bedienbar aber die IDE samt Terminal ist tot. Wenn man Glück hat kann man noch das Terminal schließen. Das hilft aber nicht weil die IDE auch tot ist. Probiert es aus. Eine höhere Baudrate hilft nur bedingt, es dauert nur etwas länger bis es einfriert.
Es gibt auch Software, die immer wieder weiterentwickelt wird und es neue Releases gibt. Da möchte ich nicht jedesmal beim Testen einer neuen Version die Debug Ausgaben händisch neu einfügen.
imho ist dein Ansatz mehr zum Tippen 
dbgp(F("ich schreib mal was raus"));vs
if (DEBUG) { Serial.print(F("ich schreib mal was raus"));}selbst das F-Macro kann man noch in das Debug-Makro integrieren.