Re: console_getline vs 0ms char delay in UART comms


Lawrence King
 

Hi Piotr

 

There are may be pieces of equipment along  the path between cutecom and the serial input on your micro-controller. Usually there is a USB to Serial chip. The programs inside screen and cutecom set parameters in the USB2Serial chip. Specifically I would be worried about the number of databits and stop bits, also parity. The ‘normal’ setting is 8N1 which means send a start bit, 8 data bits, no parity bits, and a single stop bit. However if cutecom selected 7N1, or screen selected 8N1 and the serial port on your Zephyr board was set to 8N2 you would see these types of problems.

 

Curiously you are consistently loosing the characters with Even parity. Is your Zephyr board set up to expect 7O1?

 

You need to look at the data being send from the USB2Serial adapter and ensure that it is valid. I have never had a problem with Zephyr dropping characters, but it really depends on your board, and kernel options.

 

Lawrence King

Principal Developer

+1(416)627-7302

 

From: users@... <users@...> On Behalf Of Piotr Barszczewski
Sent: Monday, March 15, 2021 12:31 PM
To: users@...
Subject: [Zephyr-users] console_getline vs 0ms char delay in UART comms

 

Hello,

 

I’ve been reviewing code from a colleague, which (code, not the colleague) is heavily based on the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html I’ve been experiencing some unexpected behaviour when using CuteCom vs screen to communicate with the console. I’ve dug deeper and deeper and eventually it seemed like the value returned by console_getline function was indeed already corrupted. In screen everything worked fine.

 

My assumption was that when I’m using screen each character is passed 1-by-1 to a buffer and everything is golden. On the other hand CuteCom buffers the input until I press enter and fires away at the serial port - pretty much like M2M communications would work over UART.

Eventually I opened up the https://docs.zephyrproject.org/latest/samples/subsys/console/getline/README.html project and the behaviour was the same. It corrupted the buffer when used in Cutecom and worked ok with screen. 

 

This is an example of the output of FW when sending “1234” over Cutecom with 0ms delay (which is what I have been using +/- forever):

[17:07:53:997] 13␍␊
[17:07:54:012] line: 13
␍␊
[17:07:54:012] last char was: 0x33
␍␊
[17:07:54:842] 13
␍␊
[17:07:54:859] line: 13
␍␊
[17:07:54:859] last char was: 0x33
␍␊
[17:07:55:794] 13
␍␊
[17:07:55:810] line: 13
␍␊
[17:07:55:810] last char was: 0x33
␍␊
[17:07:57:074] 1S@

In the end I’ve changed CuteComs char delay to 1ms and everything works well:

[17:07:50:368] 1234␍␊
[17:07:50:368] line: 1234
␍␊
[17:07:50:384] last char was: 0x34
␍␊

 

Is there some simple CONFIG_ argument to change this? I’ve looked in menuconfig but without luck. 

It’s not much of a problem to instruct every user of the FW to change it to 1ms but I’m a bit concerned about using various scripts to communicate with the firmware which will use the console. Depending on the implementation of serial driver it might require additional work to accound for the buffer not handling bursts of data.

 

Best regards

 

 

 

 

 

Join users@lists.zephyrproject.org to automatically receive all group messages.