npat-efault / picocom Goto Github PK

Describe the proposed feature in detail.
----------------------------------------
Possibility of cross-compiling picocom for Android,
i.e. against the Bionic libc implementation.
Bionic does not provide tcdrain(); I'm attaching a simple patch
to replace tcdrain() with ioctl() when compiling for Bionic.
The attached patch hunk is taken from
https://github.com/marco-pratesi/android/tree/master/picocom

How and in what cases will the feature be useful?
-------------------------------------------------
This feature will add support for the Android platform.
I'm using it on Nexus 7 (with Cyanogenmod 10.1.2), with a USB On The Go cable
and a USB-Serial adapter, to access the Cisco IOS CLI through the console port
of a Cisco device (router/switch).

Who will benefit from the feature?
----------------------------------
Android users.

I found a few typos in this header file.
I did a patch, I hope it helps

What steps will reproduce the problem?
1.cross compile the picocom fist
CC=arm-linux-gcc
LD=arm-linux-ld

2.nfs boot or just copy picocom to target board (omap3 beagleboard rev C4)
under picocom folder, run 
./picocom 
or picocom
or /foldertopicocom/picocom

error ouput


# ./picocom
-/bin/sh: ./picocom: not found

I have tried kernel 2.6.32 and 2.6.35 

echo $PATH
# echo $PATH                                                                    
/sbin:/usr/sbin:/bin:/usr/bin 

tried put picocom copy into usr/bin and still not working. 


"ls -il"
1085562 -rwxr-xr-x    1 1000     1000        60514 Dec 31  2010 picocom  

and file picocom can run too. 


What is the expected output? What do you see instead?
i expect to see picocom to run or show cannot run. I see command not found. 

What version of the product are you using? On what operating system?
ver 1.6
I use kernel 2.6.32 and 2.6.35 with busybox also tried anstrong


Please provide any additional information below.

A small but very useful addition would be the possibility to keep a log of
the communication with the terminal device.

Hi,

I don't know why, but sending binary files with either your (repo) software  or 
minicom is never successful.

Do you plan to fix it or can provide name of references of a serial terminal 
program for linux which can work with both plain and binary files?

Regards,

My tablet (a Renesas-dual A9 w/ Android 2.3) has a ZTE-MF216 3G module onboard, 
perfectly functional for my data connections, but when I try to access the same 
on /dev/ttyUSB0 through picocom (cross-complied for ARM using Sourcery G++ 
Lite) it doesn't respond to commands, though the terminal connection looks 
correctly established:

------------------------
# dmesg
...
<6>option 1-1.1:1.0: GSM modem (1-port) converter detected
<6>usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB0
<6>option 1-1.1:1.1: GSM modem (1-port) converter detected
<6>usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB1
<6>option 1-1.1:1.2: GSM modem (1-port) converter detected
<6>usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB2
<6>option 1-1.1:1.3: GSM modem (1-port) converter detected
<6>usb 1-1.1: GSM modem (1-port) converter now attached to ttyUSB3
# 
# picocom --b 115200 /dev/ttyUSB0
picocom v1.6

port is        : /dev/ttyUSB0
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
------------------------

It stays there forever, with no feeback, no echo of the AT commands I try to 
type, neither I can exit with the escape commands... I need to switch off the 
3G module (from System Setting) to exit from the terminal.

Anything that I'm doing wrong? 

I'm pretty sure it's not a picocom issue... but I hope someone can help. Thanks.

The picocom man page says:

       --send-cmd | -s
          Specifies the external program (and any arguments to it)  that  
will
          be used for transmitting files.

          Default: "sz -vv"

However, the actual default in the source code uses ascii_xfr (which is 
provided by minicom).  It should use sz by default, as it claims it does, 
instead.

Downstream fedora bug at: https://bugzilla.redhat.com/show_bug.cgi?id=732360

Currently picocom locks /run/lock/ but it would be good if it used a subdir for 
itself or another locking setup. 

Thoughts?

What steps will reproduce the problem?
1. C-ar to receive a file
2. Enter a file name

What is the expected output? What do you see instead?
Expect the receive command to be executed with the filename specified.
Instead, the send command is executed with the filename specified.

What version of the product are you using? On what operating system?
1.6 Mac OS 10.6.4

Please provide any additional information below.

There appears to be a copy / paste error on line 815 of picocom.c :

{{{
run_cmd(tty_fd, opts.send_cmd, fname, NULL);
}}}

should be

{{{
run_cmd(tty_fd, opts.receive_cmd, fname, NULL);
}}}

*************** parse_args(int argc, char *argv[])
*** 1420,1425 ****
--- 1420,1427 ----
              switch (optarg[0]) {
              case 'X':
              case 'x':
+             case 'S':
+             case 's':
                  opts.flow = FC_XONXOFF;
                  break;
              case 'H':
*************** parse_args(int argc, char *argv[])
*** 1481,1493 ****
              }
              break;
          case 'p':
              switch (optarg[0]) {
              case '1':
-                 opts.stopbits = 1;
                  break;
              case '2':
                  opts.stopbits = 2;
                  break;
              default:
                  fprintf(stderr, "Invalid --stopbits: %c\n", optarg[0]);
                  r = -1;
--- 1483,1504 ----
              }
              break;
          case 'p':
+             opts.stopbits = 1;
              switch (optarg[0]) {
              case '1':
                  break;
              case '2':
                  opts.stopbits = 2;
                  break;
+             case 'e':
+                 opts.parity = P_EVEN;
+                 break;
+             case 'o':
+                 opts.parity = P_ODD;
+                 break;
+             case 'n':
+                 opts.parity = P_NONE;
+                 break;
              default:
                  fprintf(stderr, "Invalid --stopbits: %c\n", optarg[0]);
                  r = -1;

What steps will reproduce the problem?
1. Read Debian bug #734086, which deprecates libdevlock and advises to use 
flock(2) on Linux.
2. Look in the picocom source code to see if it uses flock(2).
3.

What is the expected output? What do you see instead?
I hope to see use of flock(). Instead, I see code to do UUCP locks.

What version of the product are you using? On what operating system?
picocom v1.7 on Ubuntu 14.10

Please provide any additional information below.

It is possible when calling picocom via another program rather than directly 
from the command line that it will be called without a controlling terminal 
being defined.  My circumstances were the expect program spawning picocom on a 
pseudo-tty in order to talk to an external serial device.

When this happens the first serial port opened will be adopted as picocom's 
controlling tty, and in the case of incorrect baudrate or junk data causes 
picocom to die with SIGHUP or similar.

Adding O_NOCTTY to the serial port open flags corrects this problem.  This will 
be a NOOP in the 99.9% of cases where the user already has a controlling tty.

Patch attached.

What steps will reproduce the problem?
1. build with musl libc instead of uclibc/glibc
2.
3.

What is the expected output? What do you see instead?
build vs no build


What version of the product are you using? On what operating system?
1.7, OpenWrt


Please provide any additional information below.
See https://github.com/openwrt/packages/issues/1383 for the output and a fix

Is this project abandoned?

Attempts to receive a file via X-modem and save it to a named location are 
failing.

Looks like a cut-n-paste failure in the code where the send_cmd routine is 
invoked rather than the receive_cmd.

Patch attached.

Describe the proposed feature in detail.
There is no 'make install' to install the binary and the man pages. That would 
be useful. It would be best to build with autotools, to add all the 
functionality that autotools provides (user-configurable installation 
directories, etc).

How and in what cases will the feature be useful?
Easier for users to install picocom and its man page.

Who will benefit from the feature?
Any users and distribution managers who are building from source, who are 
familiar with the autotools procedure:
./configure
make
sudo make install

# make
cc -Wall -g -DVERSION_STR=\"2.1a\" -DTTY_Q_SZ=32768 -DHIGH_BAUD -DUSE_FLOCK -DHISTFILE=\".picocom_history\"  -DLINENOISE -o linenoise-1.0/linenoise.o -c linenoise-1.0/linenoise.c
cc -Wall -g -DVERSION_STR=\"2.1a\" -DTTY_Q_SZ=32768 -DHIGH_BAUD -DUSE_FLOCK -DHISTFILE=\".picocom_history\"  -DLINENOISE -o picocom.o -c picocom.c
cc -Wall -g -DVERSION_STR=\"2.1a\" -DTTY_Q_SZ=32768 -DHIGH_BAUD -DUSE_FLOCK -DHISTFILE=\".picocom_history\"  -DLINENOISE -o term.o -c term.c
term.c:847:32: error: use of undeclared identifier 'CMSPAR'
                        tiop->c_cflag &= ~(PARODD | CMSPAR);
                                                    ^
term.c:851:22: error: use of undeclared identifier 'CMSPAR'
                        tiop->c_cflag &= ~CMSPAR;
                                          ^
term.c:855:39: error: use of undeclared identifier 'CMSPAR'
                        tiop->c_cflag |= PARENB | PARODD | CMSPAR;
                                                           ^
term.c:859:30: error: use of undeclared identifier 'CMSPAR'
                        tiop->c_cflag |= PARENB | CMSPAR;
                                                  ^
term.c:862:41: error: use of undeclared identifier 'CMSPAR'
                        tiop->c_cflag &= ~(PARENB | PARODD | CMSPAR);
                                                             ^
term.c:893:21: error: use of undeclared identifier 'CMSPAR'
                } else if ( flg & CMSPAR ) {
                                  ^
6 errors generated.
*** Error code 1

Stop.

I have made a patch so picocom compiles cleanly on OpenBSD (I'm working on a 
port).

It is essentially checking for the HIGH_BAUD rate defines and undefining 
HIGH_BAUD if they aren't defined. 

I made some embedded systems for some applications.
Because of the system clock, I need to use some other baud rates for serial 
port communication.

I have reference the linux source code: 
https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/termbits.
h which will be included by "termios.h".

There are more valid baud rate to use.  I also checked history of the file and 
found it was updated since Oct 05, 2012.

So, I checked out the repository and modified the codes and made the patch file 
as the attachment.

What steps will reproduce the problem?
1. copy&past a larger text into picocom

What is the expected output? What do you see instead?
All text shold be copied to picocom, but picocom stops after about 537 bytes of 
input

What version of the product are you using? On what operating system?
Version 1.7 on linux

Please provide any additional information below.
I'm configuring cisco-routers with picocom.
If I do a copy&paste with a bigger config, picocom stops
after about 537 bytes of input.

It is always possible for read(2) to return -1 with errno set to EAGAIN when
reading from a non-blocking file descriptor, even if select(2) previously told
us it was ready. Catch this condition and do not treat it as a fatal error.

In addition to coping with the above condition, this patch also fixes a problem
encountered when select(2) returns read notifications for both STI and the tty,
and the data read from the STI caused the baud rate to be changed. This would
cause a tcflush() on the tty (which would drop any input data) immediately
before attempting to read(2) from that tty.

Currently buffering is used only when *writting* to the serial port. No
buffering (whatsoever) is used when reading from user the terminal, when
reading from the port or when writing to the user terminal. In these cases
the respective file descriptors are read and written a single character at
a time. This is bad and ugly.

Buffering should be added when reading from the port and when writing to
the terminal. Reading from the terminal must remain unbuffered (we should
never delay processing user commands) but even so an attempt should be made
to make read(2) calls handle multiple chars at a time. 

Why is the existing code bad or ugly?
With both groff(1) and mandoc(1), the man page throws erorrs. The use of a full 
stop at the beginning of a line (i.e. lines 127 and 231) causes groff to think 
that it should be interpreted as a macro; not being a valid macro causes that 
line to be lost in the output.

Are specific features or classes of features hard to add?
A patch is included that will fix the problem.

What sort of restructuring you propose?
Please consider applying the patch to fix the errors.

Furthermore, if it's acceptable, I'd volunteer to rewrite the manpage in mdoc 
format. However, that will add additional complications later for older 
operating systems and those that ship without mdoc formatters (namely, Solaris).

select(2) executes in linear time (O(n)) to its first argument. Since we know
for sure that tty_fd is going to be the maximum fd we need to check, pass that
rather than FD_SETSIZE so we only need to scan over the first few file
descriptors rather than all 1024 (or however many FD_SETSIZE is defined to).

I use picocom often and it was missing a small feature for my use. It would be 
very handy to be able to have a log of the communications that go through the 
cable.

It will be useful for those who use many different systems and that the output 
of the terminal is the only way to gather data about that system.

This patch adds the -D / --divisor option, which allows a custom divisor to be 
specified to the serial driver using the semi-standard 
TIOCSSERIAL/serial_struct interface, which is currently specific to Linux.

With this, you can easily specify a custom divisor and achieve custom baud 
rates with drivers that support the interface.

A number of Linux drivers will pull in this custom_divisor option to allow a 
custom baud rate to be used.

For example, if you set the baud rate to 38400, then the ftdi_sio driver allows 
you to specify the custom divisor to achieve a custom baud rate.

This has been tested to work with the ftdi_sio driver.

This interface could potentially be used by *BSD eventually (when/if they 
support this interface), but I doubt it.  Until all the Unixes figure out a 
standard way to do this, this will only work on Linux.

/dev/serial/by-id/usb-Biothentic_II_smartcard_reader_with_fingerprint_sensor._CDCACM_USB_To_RS-232_Emulation_Device_B9E871A4-F213-4DD1-997C-403F073EF126-if00

What steps will reproduce the problem?
1.Hi All,
Please help me in the below issue.
I had built the picocom for beagle board rev-c3 running android.
I had copied the picocom exe to the board & tried to execute.

#CROSS-COMPILE=arm-eabi LDFLAGS=-static make
Above command had build the picocom successfully.

I had tried following commands on the board. 
All are giving same error- "./picocom :1:Syntax Error: "<" unexpected"
#./picocom
#./picocom /dev/ttyUSB0
#./picocom -b 4800 /dev/ttyUSB0

2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. Use picocom to connect to a serial device (/dev/ttyUSB1)
2.
3.

What is the expected output? What do you see instead?
Expected: picocom opens the serial port for reading/writing
Actual: "FATAL: cannot lock /dev/ttyUSB1: Permission denied"

What version of the product are you using? On what operating system?
picocom 1.7-1, Arch Linux 3.4.6-1

Please provide any additional information below.
/var/lock is now a symlink to /run/lock, which is root:root 0755. A regular 
user would not be able to create a lockfile in /run/lock, which it seems 
picocom is trying to do. Works fine with the --nolock option or if I manually 
change the permissions of /run/lock (but that does not persist after reboot).

What steps will reproduce the problem?
1. wait

What is the expected output? What do you see instead?
project webpage still exists.


What version of the product are you using? On what operating system?
n/a

Please provide any additional information below.

Need to move this somewhere, sometime :)

*** baud: 921600
*** flow: none
*** parity: none
*** databits: 8
*** stopbits: 1
*** dtr: down (up)
*** rts: down (up)
*** mctl: DTR:1 DSR:0 DCD:0 RTS:1 CTS:1 RI:0

On OS X the maximum baudrate defined on sys/termios.h is B230400.
Those patches add the ability to detect if the source is compiled on OS X and 
address correctly the maximum usable value for the baudrate.

Tested on Snow Leopard (10.6) and Lion (10.7).