[SOLVED] REPL problem: 1 character lag

[rsmith]

Last week I received my pyboard. I've been playing with the REPL to familiarize myself with the system before I start ordering sensors and stuff.

There is one annoying problem with the REPL. It seems to have a one-character lag. The first character I type on a line is not directly shown but creates a new line. Only after I type the second character the first character becomes visible. As you can imagine, this is pretty annoying when typing.

I've tried connecting with both screen and picocom. They both exhibit the same problem.

Software and board versions are:
MicroPython v1.9.2 on 2017-08-23; PYBv1.1 with STM32F405RG

Computer OS is FreeBSD 11.1-STABLE amd64.

The serial port used is ttyU0. stty setting for this port are:
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

I would guess there is something wrong here, but I can't figure it out. I have to admit it that I haven't run serial equipment since using a modem in the 90s.

[dhylands]

I've not seem that particular behaviour, and I just tried with the latest master and everything seems to be working as expected.

Code: Select all

MicroPython v1.9.2-123-gbdc6e86 on 2017-09-26; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>> 

Make sure that there is only one program with the serial port open. Some linux systems have a program called modemmanager installed which opens up anything that looks like a modem, and the pyboard's serial fits this category.

[laurentD]

I'm using linux (Kubuntu) and I have installed a UDEV rule that avoids having this kind of strange behavior.

First, create file "/etc/udev/rules.d/49-micropython.rules" and edit this file with following text :

# f055:9800 - MicroPython board
ATTRS{idVendor}=="f055", ATTRS{idProduct}=="9800", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="f055", ATTRS{idProduct}=="9800", ENV{MTP_NO_PROBE}="1"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="f055", ATTRS{idProduct}=="9800", MODE:="0666"
KERNEL=="ttyACM*", ATTRS{idVendor}=="f055", ATTRS{idProduct}=="9800", MODE:="0666"

Then, you must restart the UDEV rules with this command :
$ sudo udevadm control --reload-rules

I don't know if it will work for you?

[rsmith]

dhylands, laurentD,

Thanks for your replies.

I'm not running modemmanager. AFAICT that program is Linux-only, and I'm running FreeBSD.
Nor am I using libmtp. To the best of my knowledge, no other process than screen has the serial port open.
getty is disabled for this serial port.

I still suspect it is a problem with the serial port setting ("line discipline").

When connected, the serial port reports the following settings (using stty):

# stty -f /dev/ttyU0
speed 115200 baud;
lflags: -icanon -isig -echo echoe echok echoke echoctl
iflags: -icrnl -ixany -imaxbel ignpar
oflags: -opost -onlcr tab0
cflags: cs8 -parenb -hupcl clocal
erase2 min time
^@ 100 2

laurentD, could you perhaps post the stty settings for your serial port under Linux? I'd like to compare them.
I would prefer not to have to manually toggle all the stty settings one by one to see if there is one that makes a difference.

Also, I have been poking around in the micropython source code on github to see if I could find out which settings the serial port on the pyboard expects, but I haven't found them yet.

[dhylands]

My stty settings under linux are:

Code: Select all

2125 >stty -F /dev/ttyACM0 
speed 115200 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost -onlcr
-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

The baud rate is irrelevant when using a pyboard since it's talking directly over USB and there is no physical usb-to-serial device.

Make sure that all forms of flow control are disabled.

When I connect, it's normal to have to hit return to get the >>> prompt.

I wrote a serial terminal program in python (uses udev which may not be available under FreeBSD)
https://github.com/dhylands/usb-ser-mon ... ser-mon.py

You can see how it opens the serial port here:
https://github.com/dhylands/usb-ser-mon ... #L117-L136

I normally use what's referred to as raw mode.
The ENTER key should send a CR (carriage return - \r)

Here's a picocom session:

Code: Select all

2130 >picocom --baud=115200 /dev/ttyACM0 
picocom v1.7

port is        : /dev/ttyACM0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Terminal ready

>>> 
>>> 
PYB: sync filesystems
PYB: soft reboot
MicroPython v1.9.2-123-gbdc6e86-dirty on 2017-09-26; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>> 
Thanks for using picocom

[rsmith]

Thanks Dave,

I've tried picocom as well:

Code: Select all

> picocom --baud=115200 /dev/cuaU0
picocom v2.2

port is        : /dev/cuaU0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        : 
omap is        : 
emap is        : crcrlf,delbs,

Type [C-a] [C-h] to see available commands

Terminal ready

>>> 
>>> help(

This is what I see after typing "help()", but before pressing return.

As you can see I tried the dialout device cuaU0 instead of ttyU0. No difference.

I've tried every a whole bunch of stty settings. They make no difference.
Just in case it was a problem with my xterm window, I tried running picocom from the console. That also doesn't make a difference.

So summing it up, the following things do not influence the problem:

• serial device
• stty settings
• terminal program (picocom/screen)
• picocom mappings
• different USB port

I only have one micro-usb cable, so I cannot try another one. but I don't think that is the problem.

What I will do is pester some FreeBSD greybeards on the FreeBSD-questions mailing list, see if they can shed some light on the problem.

[mwm]

FreeBSD and Linux treat bogus tty ioctl values differently. Linux explicitly mask them off, so if you pass a value to the wrong ioctl, all that happens is your setting doesn't happen. FreeBSD doesn't do that, which can cause some really strange behavior. stm32flash had such a bug in it until last year that kept it from working on FreeBSD.

It's a long shot, but check that the settings you get from stty match the code. In particular, don't trust your com programs report unless you've verified it's getting them and not using it's own internal values.

[dhylands]

The only thing I can suggest is that you boot your machine from a bootable linux CD and install picocom and give it a try in that environment. You'll need to use sudo to run piccom in order to access the serial port.

I wouldn't suspect a usb cable either - it shouldn't manifest the way that you're describing. It sounds more like a USB driver issue under FreeBSD.

[rsmith]

Finally I have found a solution for my problem.

Today I installed pyserial, and I saw that it came with a simple terminal program called "miniterm". Thinking that it might not hurt to try, I hooked up my pyboard and called "miniterm.py-3.6 /dev/cuaU0 115200".

And it just worked. The lag is gone and the REPL is usable.

Looking at the stty settings for /dev/cuaU0 with both miniterm and picocom, I noticed some differences. Miniterm uses

Code: Select all

-echoke -echoctl -ignbrk brkint -onlcr

while picocom used the opposite. All other stty settings are the same. Not sure which one(s) do the trick but I'm happy it works!

I've got a BMP280 temperature/pressure sensor wired up to the pyboard using I²C now, logging data over the USB connection to my workstation. Based on the datasheet for the sensor and the adafruit circuitpython code, I wrote a module to read this sensor from my pyboard. I'll put the code up on my github page (rsmith-nl) after I've done a proper test.

In the meantime I've also updated the pyboard's firmware to v1.9.3-521, but I'm pretty sure that this did not play a role in the resolution of the problem. After the update, picocom still had the same issue.

Thanks to all who have responded. I'm planning to make my pyboard into the heart of a portable device to measure the e.g. levels of VOC's and dust in the air. Now I can move forward with this.