Examples do not work when using Serial Monitor in Arduino IDE.

[donfbecker]

All examples work fine when I use screen to attach to serial, but when using the Arduino Serial Monitor input is just echoed back and nothing is processed. To fix I have to use this loop

void loop() {
  if (Serial.available()) {
    char line[128];
    size_t lineLength = Serial.readBytesUntil('\n', line, 127);
    line[lineLength] = '\0';

    shell.execute(line);
  }
}

[philj404]

The following just worked for me today (just now):

• Windows 11 PC
• Arduino IDE 2.3.0 (also worked before I upgraded from Arduino IDE 2.2.1)
• board: Arduino Nano
• port: COM5
• example code: EchoCommand.ino
• Serial Monitor set to 115200 baud -- note both Serial Monitor and Serial.begin() must agree on the same baud rate
• Serial Monitor line ending set to "Both NL and CR"

I am not familiar with "screen".

Your example code in loop() seems to replace what shell.executeIfInput(); is trying to do.

I am not sure what your setup is. Does the EchoCommand.ino example do something when you type "help" and press Enter?

[donfbecker]

The line ending setting was the problem. Serial Monitor on my system defaults to "New Line", which may be a Linux thing, since line endings are generally only NL on Linux. I see your comments in the source say to ignore "\n" since "raw" terminals don't send it. It's alway seemed pretty standard for terminal programs to send a NL when you hit enter, on some systems it is preceded by a CR. Old school MacOS only used CR for line endings, but that changed with MacOS X, when it changed to a BSD base, and they switched to NL for them.

[philj404]

Ok. I hope that works better now.

If I remember correctly (and for those who might want to know):

• a keyboard's "Enter" key actually sends ^M, known as carriage return or '\r' in C/C++.
• line feed/newline is ^J (control-J), or '\n' in C/C++.

Back when I was a kid, Teletype printers would need both ^M and ^J characters to 1. move the print head back to the first column (return) and 2. scroll the paper to start the next line (line feed).

It was even useful to keep both operations separate -- you might as well use the extra delay from the line feed to stall long enough for the carriage to finish returning to the first column. 110 bits per second (about 10 characters/second)!

"raw" keyboard output just forwards each keypress on with no extra processing.

Sometimes it's better to do a little extra processing before forwarding the characters on -- for example it might be nice to process a backspace rather than make everything downstream deal with a typo. Particularly if you don't want to retype a long line.

That can be done with "cooked" mode.

• "Cooked" mode usually processes input one line at a time. Nothing will happen until the entire line is typo-free and ready (and the user presses "Enter")
• It can support backspace to fix typos, undo entire lines, etc.
• On Unix/Linux machines I think cooked mode usually converts the '\r' "Enter" key into a '\n'.

[philj404]

SimpleSerialShell needs "raw" serial communication to see and process each character as it comes in (for example to support backspace).

This may not be the default for some terminal programs