enhancement to support adjustable TX delay

[m-fonseca]

On a number of embedded devices I use, the UART interfaces do not have flow control lines hooked up. This means various longer cut &paste commands pasted into picocom often get garbled. It would be great if picocom had a way to insert some adjustable delay between bytes to easy usage on limited hardware.

BTW, love picocom :)

[npat-efault]

Interesting feature... I will certainly think about it!

[npat-efault]

A couple of question to help me better understand the requested feature:

1. Why don't you simply lower the baudrate, instead of introducing delays between characters? This would be the most efficient way to achieve what you want. Almost all UARTS support baudrates as low as 1200 bps and most go even lower at 300 bps. At 1200 bps you have 120 chars per sec, that is 8.3ms between chars. At 300 bsp it's 30 chars per sec and 33.3ms between chars. So why not do this instead? (maybe it's inconvenient to change the device's baudrate? I don't know...)

2. If this was implemented, what would be a reasonable range of delays? Would something, like, from 500us to 50ms be acceptable?

[m-fonseca]

I thought the same thing, and I've tried the lower baud rate (9600) before but it doesn't seem to help. Couple of things to note:

• I'm cutting and pasting into the bootloader (u-boot) which doesn't allow me to use a baud rate under 9600.
• I'm not sure it play a part in this, but I'm using a usb<->rs232 cable in the middle.
• The settings in the ascii-xfr program does exactly what I'm looking for, except it only works on files, which is not convenient at all.
• I'm not 100% convinced my problem is just flow control; maybe there is additional link quality problems

Heres some examples of what I'm seeing btw:
Sample text:

echo abcdefghijklmnopqrstuvwxyz
echo ABCDEFGHIJKLMNOPQRSTUVWXYZ
echo --------------------------
echo 1234567890123456890123456890
echo abcdefghijklmnopqrstuvwxyz
echo ABCDEFGHIJKLMNOPQRSTUVWXYZ
echo --------------------------
echo 1234567890123456890123456890
echo abcdefghijklmnopqrstuvwxyz
echo ABCDEFGHIJKLMNOPQRSTUVWXYZ
echo --------------------------

Cut & paste (@9600):

uboot # echo 1234567890123456890123456890
1234567890123456890123456890
uboot # echo abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
uboot # echo ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
uboot # echo --------------------------
--------------------------
uboot # 680246913580eh bdfhjlnprtvwy        <--- falling apart
Unknown command '680246913580eh' - try 'help'
uboot # coA----------
Unknown command 'coA----------' - try 'help'
uboot # co135791358023580eh bHJLNPRTVXZeh -------------
Unknown command 'co135791358023580eh' - try 'help'
uboot # 

using ascii-xfr with -l 10 -c 10:

ASCII upload of "test.txt"
Line delay: 10 ms, character delay 10 ms

echo 1234567890123456890123456890
1234567890123456890123456890
uboot # 
1234567890123456890123456890
uboot # echo abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
uboot # 
abcdefghijklmnopqrstuvwxyz
uboot # echo ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
uboot # 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
uboot # echo --------------------------
--------------------------
uboot # 
--------------------------
uboot # echo 1234567890123456890123456890
1234567890123456890123456890
uboot # 
1234567890123456890123456890
uboot # echo abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
uboot # 
abcdefghijklmnopqrstuvwxyz
uboot # echo ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
uboot # 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
uboot # echo --------------------------
--------------------------
uboot # 
--------------------------
uboot # echo 1234567890123456890123456890
1234567890123456890123456890
uboot # 
1234567890123456890123456890
uboot # echo abcdefghijklmnopqrstuvwxyz
abcdefghijklmnopqrstuvwxyz
uboot # 
abcdefghijklmnopqrstuvwxyz
uboot # echo ABCDEFGHIJKLMNOPQRSTUVWXYZ
ABCDEFGHIJKLMNOPQRSTUVWXYZ
uboot # 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
uboot # echo --------------------------
-------------------------

[npat-efault]

So I guess there are cases where a "delay between chars" would be useful, and lowering the baudrate cannot be a substitute. At 9600 bps, that you mentioned, a delay between chars is approx. 1ms which could (conceivably) be not enough, depending on what the program does at the time, how it handles interrupts, how it does buffering, and so on. Not very likely... but not inconceivable.

So, when I find some free time, I will add such a feature. I will limit the range to something reasonable, like: from 500us to 50000us (= 50ms), which, I think, will make the implementation a bit easier...

Anyway, we 'll see!

Tanks for the info!

[m-fonseca]

Great, thanks for the consideration!

[octetta]

I've added an option "--cdelay milliseconds" to achieve this by conditionally inserting a usleep() between character writes to the tty.

Is there any interest in this patch? It was the result of a very cursory understanding of the codebase, however works when tested on macOS and Raspbian.

For background, I need to paste large sections of text to an embedded device where I can't lower the baud rate and the target device has no flow control, a tiny FIFO (guessing it's < 8 bytes from empirical evidence), and apparently the UART driver is polled rather than being interrupt driven.

[yankee14]

@octetta Did you submit a pull request for this? This is a feature I need, for the exact situation you described... Thanks!

[5frank]

related PR: #131

[wsakernel]

I have now a refactored version in a branch in my repo. PR is here: wsakernel#3 I'd appreciate testing and/or comments.

[xypron]

Many IoT devices have neither flow control nor do they allow to alter the baud rate but they have size limited console buffers. This is why this change is needed to be able to paste to the serial console of such devices.

[wsakernel]

Merged the above PR into my repo now. Thanks to xypron for testing!