Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serial monitor EOL and send_on_enter filter not working properly #3787

Closed
schleb opened this issue Dec 18, 2020 · 10 comments
Closed

Serial monitor EOL and send_on_enter filter not working properly #3787

schleb opened this issue Dec 18, 2020 · 10 comments
Assignees
Milestone

Comments

@schleb
Copy link

schleb commented Dec 18, 2020

Issue:

  • Serial monitor sends no EOL bytes with send_on_enter filter enabled (CR and/or LF bytes are missing at line end)
  • Send-on_enter does not work at all with EOL set to CR or EOL set to LF. It only sends the line if EOL is set to CRLF

Complete description:
I have a simple setup in which an ESP32 microcontroller replies the bytes sent to it via serial port. It replys the bytes in decimal representation so that I can read them easily:

Code:

void loop()
{
   int byte;

   if (Serial.available())
   {
    byte = Serial.read();

    Serial.print("received:");
    Serial.println(byte, DEC);
  }
}

Monitor snap (of typing [a] [Enter] [b] [Enter] [c] [Enter])

a
received:97
b
received:98
c
received:99

The issue is as you can see easily: there is no CR or LF or CRLF sent by the monitor. If I use another Terminal it works. E.g. with Arduino IDE I receive LF (dec 10). The Arduino IDE has no echo of the sent bytes, so sending the same bytes (a, b, c) it looks like this:

received:97
received:10
received:98
received:10
received:99
received:10

The EOL parameter of the monitor is set to CRLF (default). If I change the EOL parameter of the monitor to CR or LF, the send_on_enter filter does not work. Nothing is beeing sent. If I then change the parameter back to CRLF odd things happen - it sends out all the old stuff with CR(13) or LF(10):

a
received:97
b
received:98
c
received:99
--- EOL: CR ---
a
b
c
--- EOL: LF ---
a
b
c
--- EOL: CRLF ---
a
received:97
received:13
received:98
received:13
received:99
received:13
received:97
received:10
received:98
received:10
received:99
received:10
received:97
b
received:98
c
received:99

Platformio.ini:
monitor_speed = 115200
monitor_flags=
--echo
monitor_filters=
send_on_enter

System:
PIO Core 5.0.3 Home 3.3.1
VS Code 1.52.0
Windows 10

The issue seems to be happened also to this guy: https://community.platformio.org/t/monitor-send-on-enter-filter-not-work-with-eol-lf/17356

@ivankravets ivankravets transferred this issue from platformio/platformio-vscode-ide Jan 4, 2021
@ivankravets ivankravets added this to the 5.0.5 milestone Jan 22, 2021
@ivankravets ivankravets self-assigned this Jan 22, 2021
@ivankravets
Copy link
Member

Thanks for the report!

Please re-test with pio upgrade --dev.

@niclasku
Copy link

This fix does not work for me. platformio/commands/device/filters/send_on_enter.py seems to remove the EOL from the buffer after it gets appended a few lines above. Changing the method to this works for me:

def tx(self, text):
  self._buffer += text
  if self._buffer.endswith(self._eol):
    return self._buffer
  return ""

Not sure if this hack has any side effects.

@ivankravets ivankravets reopened this Feb 10, 2021
@ivankravets ivankravets modified the milestones: 5.1.0, 5.1.1 Feb 10, 2021
@ivankravets
Copy link
Member

This is the correct behavior. We send text ON ENTER and we don't send "enter". If you need EOL chars - then do not use this filter.

@schleb Am I correct?

@niclasku
Copy link

I wonder how I could send something like command parameter\r\n then. With defaults it would send c\r\n, o\r\n, m\r\n and so on. I would expect that if send_on_enter is enabled it sends command parameter with no --eol specified, command parameter\r with -eol=CR and command paramter\r\n with --eol=CRLF.

Same problem is mentioned here: Forum

@ivankravets ivankravets reopened this Feb 10, 2021
@ivankravets ivankravets modified the milestones: 5.1.0, 5.1.1 Feb 10, 2021
@ivankravets
Copy link
Member

Thanks for the report! Please re-test with pio upgrade --dev.

@niclasku
Copy link

Thank you very much for the fast response! This works pretty well for me, but I am not sure if there exists a use case where you want to use send_on_enter with no EOL chars at all. If you don't use the --eol flag it currently defaults to CRLF and there seems to be no option to disable sending of EOL chars if send_on_enter is enabled. Supporting for example --eol=None could help people in this situation.

@ivankravets
Copy link
Member

@schleb
Copy link
Author

schleb commented Feb 11, 2021

@ivankravets

This is the correct behavior. We send text ON ENTER and we don't send "enter". If you need EOL chars - then do not use this filter.

@schleb Am I correct?

Mh, I also expected the EOL characters to be sent while send_on_enter is enabled. So the fix also did not work for me as I expected.

@niclasku

Thank you very much for the fast response! This works pretty well for me, but I am not sure if there exists a use case where you want to use send_on_enter with no EOL chars at all. If you don't use the --eol flag it currently defaults to CRLF and there seems to be no option to disable sending of EOL chars if send_on_enter is enabled. Supporting for example --eol=None could help people in this situation.

That's an interesting question :-) I would have said no, but indeed I just had this use case one week ago as I had to communicate with a matchbox laser module (https://integratedoptics.com/) which has a weird communication protocol. In order to send a command you have to send all command-bytes in a very short timing without EOL. The laser accepts the command in the moment that no further bytes follow. That is not possible by typing the command by hand in a terminal because after each byte you type the laser thinks the command is complete - and says "error" because the command is not complete. So here you need the possibility to send a complete line without EOL.

I agree: It would be nice to have all options: sending CR, LF, CRLF and none

@MrtnCttn
Copy link

MrtnCttn commented Jan 10, 2022

Hello,

Has anyone found a way to send a configurable EOL character with the send_on_enter filter?

I have reproduced basically the same steps as schleb. Using an Arduino Nano board, VSCode 1.63.2, python 3.10.1, macOS 12.0.1. Same code for troubleshooting:

void loop()
{
   int byte;
   if (Serial.available())
   {
    byte = Serial.read();
    Serial.print("received:");
    Serial.println(byte, DEC);
  }
}

Platformio.ini (I also tried the similar option with monitor_filters instead):

monitor_flags =
    --echo
    --eol
    LF
    --filter
    send_on_enter

Under these conditions, I can type whatever, nothing is sent/received.

What I find really weird is that if I use pio device monitor in the terminal, the monitor works almost as I expect:

% pio device monitor -b 9600 --echo --eol LF --filter send_on_enter
--- Available filters and text transformations: colorize, debug, default, direct, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Miniterm on /dev/cu.usbserial-AB0LRFSL 9600,8,N,1 ---
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---

received:10

received:10
a
received:97
received:10
b
received:98
received:10
c
received:99
received:10

--- exit ---

I say almost because I do have to type Enter twice the first time, which is weird but not a big deal.

Any suggestion on how to ensure in platformio.ini (or some other configuration file) that the serial monitor sends the requested EOL character when using send_on_enter?

@omicronns
Copy link

I have same issue. It seems like if --eol is one of LF or CR and combined with --filter send_on_enter it sends nothing, never. It works ok only when --eol is CRLF.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants