platformio
PIO device monitor adds \r before echoed \n automatically
Hello!
Thank you all for your hard work on this project!
I was curious about whether a certain behavior was intended with regards to the serial monitor on PlatformIO. I have a STM32 attached via a USB-UART adapter to my Linux (Ubuntu 24.04) machine. When I run:
pio device monitor --port /dev/ttyUSB0 --baud 115200 --eol LF --raw
I'm expecting that only \n gets sent to the remote device when I press Enter, which I can confirm when I step through our code for the UART that receives and echoes back the same characters. However, in the terminal, it appears to print a \r automatically when an \n is transmitted from the STM32. I am quite sure that the STM32 does not transmit anything other than what it receives, so there's probably some issue with how I'm invoking the device monitor, or maybe there's a bug.
I have also tried:
pio device monitor --port /dev/ttyUSB0 --baud 115200 --eol LF --filter direct
pio device monitor --port /dev/ttyUSB0 --baud 115200 --eol LF --filter default
pio device monitor --port /dev/ttyUSB0 --baud 115200 --eol LF --filter nocontrol
pio device monitor --port /dev/ttyUSB0 --baud 115200 --eol LF --filter printable
And even just:
pio device monitor --port /dev/ttyUSB0 --baud 115200 --eol LF
But none of them prevent a \r being added. To clarify, the behavior I'm looking for when I hit Enter to send an LF is as follows:
Typing this long string...
^ <--- pressed Enter here
| <--- cursor appears here
But what happens is this:
Typing this long string...
^ <--- pressed Enter here
| <--- cursor appears here
How can I filter out the \r from being added before \n using the device monitor options? Will I have to specify a custom filter as seems to be described here? Or is this a possible bug?
With no inside information, but just trying to help out, I would for some kind of "monitor.py" in your platformio installation (look in both ~/.platformio and $project/.platofrmio, but it's PROBABLY the first) for some kind of Python code handling this and beat it with a stick until it stops.
Just so I'm clear on the direction of everything, you're running this on a Linux system and you press the key with your right pinky labeled "return" (which sends a newline) and this results in something going to your board and you're sure your board is adding, subtracing nothing, but what is being display is a carriage return plus a newline, right?
Can you confirm your board is not receiving it? If it IS receiving it, then my guess is that ONLCR and OPOST are set on /dev/ttyUSB0, which is changingn it in the output processing. If your board is NOT receiving a CR, but your display is acting like there was a CR (which is normally desired and sane behaviour) then my guess is that ICANON and INLCR are set and it's receiving a NEWLINE from /dev/ttyUSB0 and expanding that on the way back up.
It's possible that these flags are being set in your controlling tty (which you can find by running the cleverly named 'tty' command) but I'm skeptical because they would make typing "keyboard stuff" to your device crazy annoying, doing things like waiting for you to press enter before sending the keystrokes. So I would HOPE this tty is in raw mode (-OPOST, -ICANON, with a low VMIN and VTIME combination) and the problem is on the serial tty.
You can verify this by firing it all up and running 'stty -a < /dev/ttyUSB00' (or whatever your serial tty is). From the hip, I would expect ECHOE, ICANON, and OPOST to all be off. you can experiment with the onlcr and inlcr options by toggling them on (stty onlcr < /dev/ttyUSB0) or off (stty -onlcr < /dev/ttyUSB00) If you find that combinatino that gives you the perfect "aha" moment, find the Python code and beat it with those flags until they submit to your bidding. If you're not concerned about breakign anything else, then you don't have to worry about patch submission; just run with this flag forever.
However, and I won't feel bad since your request has been ignored for > two months, I recommend interacting with Platformio for such things as little as posible. tio is a wonderful utility, but some people like minicom. cu is pretty well burned into my finger memory over the decades. The advantage of tio is that it uses modern defaults (hello, 115k. No, thank you, let's please NOT wait for the DCD pin to go high because exactly none of us have seen a modem in 30 years, etc.) and it's hightly scriptable. So if you have a script thta loads your board, but hte tty disappears and might come back as a different one, you can 'tio -a new' which waits for a new tty to appear and then pounces on it. Or 'tio -a latest' for that board you just plugged in. You can define groupings if you have one batch of boards that run at 115K and one batch at 57K that requres 7 bits or something weird. You can turn on timestamps to see WHEN yuor device issued that panic last night. You can script it with Lua. If you need custom key mapping, there's a faciliity for that (there's one device in my life that I have to either add or remove newlines from) and so on. It's a lovely substitute. And it's cross platform and open source so you can use it the same on all coworker/customer systems - plus you can fix it if you have to. (I have. Look for me in te credits. :-) )
Until I discovered tio, I tended to collect tiny script files ending in
VOODOO to figure out which random USB port name was going to be used.
set -e pio run --target upload -e $E (stty 115200 ; cat -u) < $PLATFORMIO_UPLOAD_PORT
Anyway, I know what you really wanted was a fish and not a fishing lesson, but I live in a country where the government is closing the Fish & Wildlife Service, so that's all I can offer...
