Serial.begin(115200); that thing must require a lot more space than I ever imagined.
Device in question is an esp32
So my question is do any of you do this and can I ever turn it on from inside the program?
Serial.begin(115200); that thing must require a lot more space than I ever imagined.
Device in question is an esp32
So my question is do any of you do this and can I ever turn it on from inside the program?
If you mean "can I un-comment it programmatically?" the answer is "no".
I use the ESP's log_x printing, which preforms faster than Serial.thingy.
well I was thinking in the html screen I make to interact with it I could have the Serial.begin under an if statement. but I suppose of course it would be there obviously.
Since both Serial and log_x use the same hardware UART, there's probably you reason you couldn't send data with Serial at the same baud that log_x uses. If so, I can't see reason for the latter to be faster.
As you realized, it is not possible to save the flash memory by disabling it at runtime. You must do it at compile time.
Here is a system you can use to quickly enable and disable the debug output in your code at compile time:
Add this code near the top of your sketch:
#define DEBUG true //set to true for debug output, false for no debug output
#define DEBUG_SERIAL \
if (DEBUG) Serial
Then use code like this to initialize the serial communication:
DEBUG_SERIAL.begin(9600);
If you want your program to wait for Serial Monitor to be opened before running when using native USB boards (e.g., Leonardo), add this line:
#if DEBUG == true
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
#endif // DEBUG == true
and code like this for debug output:
DEBUG_SERIAL.println("Some debug output");
When the DEBUG
macro is set to false, the compiler will optimize the calls using DEBUG_SERIAL
out of the code because it knows they will never run. This means the debug output code won't use up any memory and won't slow down the execution of the program.
In the rare case where your debug system needs to read serial input, you would use similar code:
#if DEBUG == true
if (Serial.available()) {
x = Serial.read();
}
#endif // DEBUG == true
This system can easily be extended to allow multiple levels of debug output, still with no overhead when it's disabled:
#define DEBUG_ERROR true
#define DEBUG_ERROR_SERIAL \
if (DEBUG_ERROR) Serial
#define DEBUG_WARNING true
#define DEBUG_WARNING_SERIAL \
if (DEBUG_WARNING) Serial
#define DEBUG_INFORMATION true
#define DEBUG_INFORMATION_SERIAL \
if (DEBUG_INFORMATION) Serial
void setup() {
Serial.begin(9600);
while (!Serial) {
; // wait for serial port to connect. Needed for native USB port only
}
DEBUG_ERROR_SERIAL.println("This is an error message");
DEBUG_WARNING_SERIAL.println("This is a warning message");
DEBUG_INFORMATION_SERIAL.print("The state of pin 5 is ");
DEBUG_INFORMATION_SERIAL.println(digitalRead(5) ? "HIGH" : "LOW");
Serial.println("This is standard program output");
}
void loop() {}
You can use the Boolean debug macros to switch on and off other parts of your code too.
Nice, thanks! I will use that.
cleaner too, because you aren't doing #if and #endif for every serial print line.
You are welcome. It is indeed a big improvement over adding conditional code to every HardwareSerial::println
call.
It's unfortunate it is still necessary in some cases like the while (!Serial)
construct but I didn't find an alternative in that case. Fortunately the extra preprocessor mess those rare occurrences add to your code is fairly minimal since the HardwareSerial::println
calls make up the bulk of the debug-related code.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.