Coder Social home page Coder Social logo

picocom's Introduction

picocom

Minimal dumb-terminal emulator

by Nick Patavalis ([email protected])

The latest release can be downloaded from:

https://github.com/npat-efault/picocom/releases

As its name suggests, picocom is a minimal dumb-terminal emulation program. It is, in principle, very much like minicom, only it's "pico" instead of "mini"!

It was designed to serve as a simple, manual, modem configuration, testing, and debugging tool. It has also served (quite well) as a low-tech serial communications program to allow access to all types of devices that provide serial consoles. It could also prove useful in many other similar tasks. It can be used in embedded systems, since its memory footprint is rather small (approximately 40K, when stripped and minimally configured).

Picocom runs and is primarily tested on Linux. With no, or with minor, modifications it will run (and most of its features will work) on any Unix-like system with a reasonably POSIX-compatible termios(3) interface. Patches to support idiosyncrasies of specific Unix-like operating systems are very welcome.

For a description of picocom's operation, its command line options, and usage examples, see the manual page included in the source distribution as "picocom.1", and also html-ized as "picocom.1.html".

People who have contributed to picocom, by offering feature implementations, bug-fixes, corrections, and suggestions are listed in the "CONTRIBUTORS" file.

Please feel free to send comments, requests for new features (no promises, though!), bug-fixes and rants, to the author's email address shown at the top of this file.

Compilation / Installation

Change into picocom's source directory and say:

make

This will be enough to compile picocom for most modern Unix-like systems. If you want, you can then strip the resulting binary like this:

strip picocom

Striping the binary is not required, it just reduces its size by a few kilobytes. Then you can copy the picocom binary, as well as the man-page, to wherever you put your binaries and man-pages. For example:

cp picocom ~/bin
cp picocom.1 ~/man/man1

Again, this is not strictly necessary. You can run picocom and read its man-page directly from the source directory.

If something goes wrong and picocom can't compile cleanly, or if it's lacking a feature you need, take a look at the included Makefile. It's very simple and easy to understand. It allows you to select compile-time options and enable or disable some compile-time features by commenting in or out the respective lines. Once you edit the Makefile, to recompile say:

make clean
make

If your system's default make(1) command is not GNU Make (or compatible enough), find out how you can run GNU Make on your system. For example:

gmake clean
gmake

Alternatively, you might have to make some trivial edits to the Makefile for it to work with your system's make(1) command.

Using picocom

If your computer is a PC and has the standard on-board RS-233 ports (usually accessible as two male DB9 connectors at the back) then under Linux these are accessed through device nodes most likely named: /dev/ttyS0 and /dev/ttyS1. If your computer has no on-board serial ports, then you will need a USB-to-Serial adapter (or something similar). Once inserted to a USB port and recognized by Linux, a device node is created for each serial port accessed through the adapter(s). These nodes are most likely named /dev/ttyUSB0, /dev/ttyUSB1, and so on. For other systems and other Unix-like OSes you will have to consult their documentation as to how the serial port device nodes are named. Lets assume your serial port is accessed through a device node named /dev/ttyS0.

You can start picocom with its default option values (default serial port settings) like this:

picocom /dev/ttyS0

If you have not installed the picocom binary to a suitable place, then you can run it directly from the source distribution directory like this:

./picocom /dev/ttyS0

If this fails with a message like:

FATAL: cannot open /dev/ttyS0: Permission denied

This means that you do not have permissions to access the serial port's device node. To overcome this you can run picocom as root:

sudo picocom /dev/ttyS0

Alternatively, and preferably, you can add yourself to the user-group that your system has for allowing access to serial ports. For most Unix-like systems this group is called "dialout". Consult you system's documentation to find out how you can do this (as it differs form system to system). On most Linux systems you can do it like this:

sudo usermod -a -G dialout username

You will need to log-out and then log-in back again for this change to take effect.

You can explicitly set one or more of the serial port settings to the desired values using picocom's command line options. For example, to set the baud-rate to 115200bps (the default is 9600bps), and enable hardware flow-control (RTS/CTS handshake) you can say:

picocom -b 115200 -f h /dev/ttyS0

or:

picocom --baud 115200 --flow h /dev/ttyS0

To see all available options run picocom like this:

picocom --help

Once picocom starts, it initializes the serial port and prints the message:

Terminal is ready

From now on, every character you type is sent to the serial port, and every character received from the serial port is sent ro your terminal. Including control and special characters. Assuming that there is nothing connected to the other end of your serial port, to respond to the characters you send to it (e.g. echo them back to you), then nothing that you type in picocom will appear on your terminal. This is normal.

To exit picocom you have to type:

C-a, C-x

Which means you have to type [Control-A] followed by [Control-X]. You can do this by pressing and holding down the [Control] key, then pressing (and releasing) the [A] key and then pressing (and releasing) the [X] key (while you still keep [Control] held down).

This C-a is called the "escape character". It is used to inform picocom that the next character typed is to be interpreted as a command to picocom itself (in this case the exit command) and not to be sent-down to the serial port. There are several other commands (other than C-a, C-x), all prefixed by C-a.

Next you should take a look at the very detailed picocom manual page. It can be accessed like this (assuming you are inside the picocom distribution source directory):

man ./picocom.1

or (assuming you have installed the manual page to a suitable place):

man picocom

Thanks for using picocom

Custom Bash completion

Starting with release 3.2, picocom includes support for custom Bash-shell completion. With this you can press the [TAB] key, and the bash shell will complete command-line option names and values and propose valid selections for both. This makes the experience of using picocom more pleasant.

Custom completion works only with recent versions of the Bash shell (>= 4.3). It is in no way mandatory in order to use picocom. Here's how you can enable it, if you wish.

To manually enable custom completion support you need to source the file (custom completion script):

<picocom source dir>/bash_completion/picocom

Assuming you are inside the picocom source directory, you can do it like this:

. ./bash_completion/picocom

This will enable custom completion support for the current shell session only. Use it for a while and see if you like it.

To enable support automatically for all Bash-shell sessions, you have the following options:

  1. If you are running a relatively modern Debian or Ubuntu or other Debian-based distribution, and you have package bash-completion installed, you can simply copy the custom completion script to the directory:

    /etc/bash_completion.d/
    

    Obviously, you need to be root to do this. Assuming you are inside the picocom source directory, something like this will do it:

    sudo cp ./bash_completion/picocom /etc/bash_completion.d/
    

    This will enable custom completion support for picocom, globaly (for all Bash-shell users).

    NOTICE: If you have another version of picocom already installed, there may already be a picocom completion script in /etc/bash_completion.d. The command above will obviously overwrite it with the new one. So be careful if this is not what you want.

    For other distributions and operating systems you have to check their documentation to see if they provide a similar mechanism for automatically sourcing custom completion scripts.

  2. If you want to automatically enable support only for the current user, you must arange for your user's .bashrc to source the custom completion script. There are, obviously, many ways to do this, so the following is only a suggestion:

    Create a directory to keep the custom completion scripts

    mkdir ~/.bash_completion.d
    

    Copy the picocom completion script to the directory you created. Assuming you are inside the picocom source directory:

    cp ./bash_completion/picocom ~/.bash_completion.d
    

    Add the following (or similar) to the end of your .bashrc

    # Source custom bash completions
    if [ -d "$HOME"/.bash_completion.d ]; then
        for c in "$HOME"/.bash_completion.d/*; do
            [ -r "$c" ] && . "$c"
        done
    fi
    

    From now on every new shell session you start will load (source) all the custom completion scripts you have put in ~/.bash_completion.d

A low-tech terminal server

You can use picocom to patch-together a very simple, very low-tech, terminal server.

The situation is like this: You have, in your lab, a box with several serial ports on it, where you connect the console ports of embedded devices, development boards, etc. Let's call it "termbox". You want to access these console ports remotely.

If you provide shell-access to termbox for your users, then it's as simple as having the users say (from their remote workstations):

$ ssh -t user@termbox picocom -b 115200 /dev/ttyS0

Or make a convenient script/alias for this. Remember the -t switch which instructs ssh to create a pseudo-tty, otherwise picocom won't work.

What if you don't want to give users shell-access to termbox? Then you can use picocom in a setup like the one described below. Just remember, there are countless variations to this theme, the one below is just one of them. Also, keep in mind that some of the commands shown may have small differences from system to system; more so if you go from Linux to other Unix-like systems.

Login to termbox and create a user called termbox:

$ sudo useradd -r -m termbox

The -r means "system account", and the -m means do make the home-directory. Mostly we need this account's home-directory as a convenient place to keep stuff; so it doesn't need a login shell or a password.

Switch to the termbox account and create a bin directory in its home-dir.

$ sudo su termbox
$ cd ~
$ mkdir bin

Copy the picocom binary in ~termbox/bin (if you don't have it globally installed):

$ cp /path/to/picocom ./bin

For every serial port you want to provide access to, create a file named after the port and put it in ~termbox/bin. It should look like this:

$ cat ./bin/ttyS0
#!/bin/sh
exec /home/termbox/bin/picocom \
  --send-cmd '' \
  --receive-cmd '' \
  -b 115200 \
  /dev/ttyS0

And make it executable:

$ chmod +x ./bin/ttyS0

Repeat accordingly for every other port. Now the contents of ~termbox/bin should look like this:

$ ls -l ./bin
-rwxrwxr-x 1 termbox termbox 102128 Aug 29 13:56 picocom*
-rwxrwxr-x 1 termbox termbox    108 Aug 29 14:07 ttyS0*
-rwxrwxr-x 1 termbox termbox    108 Aug 29 14:07 ttyS1*
... and so on ...

Exit the termbox account:

$ exit

Now, for every serial port, create a user account named after the port, like this:

$ sudo useradd -r -g dialout -d ~termbox -M -s ~termbox/bin/ttyS0 ttyS0

Observe that we make dialout the default group for this account, so the account has access to the serial ports. Also observe that we make the script we just wrote (~termbox/bin/ttyS0) the login-shell for the account. The -d option instructs useradd to use /home/termbox as the user's home directory, and the -M switch instructs it not to create the home-directory. We don't really need a home directory for the ttyS0 account, since picocom will not read or write any files; but we provide one, regardless, because some systems need a valid home-directory to cd-into on login (else they choke). We could as well have used / as the home directory, or we could have let useradd create the usual /home/ttyS0.

Then set a password for the newly created account:

$ sudo passwd ttyS0
Enter new UNIX password: ******
Retype new UNIX password: ******

Repeat (create user account, set password) for every port you want to give access to.

You 're set. All a user has to do to remotely access the console connected to termbox's /dev/ttyS0 port, is:

ssh ttyS0@termbox

Some interesting points:

  • If the default port settings you specified as command-line arguments to picocom in ~termbox/bin/ttySx do not match the settings of the device connected to the port, the user can easily change them from within picocom, using picocom commands.

  • If a second user tries to remotely access the same port, at the same time, picocom won't let him (picocom will find the port locked and exit).

  • In the example ~termbox/bin/ttySx scripts we have completely disabled the send- and receive-file picocom commands. This guarantees that picocom won't execute any external commands. If you want, you can enable the commands by providing specific file-upload and file-download programs as the arguments to the --send-cmd and --receive-cmd picocom command-line options (provided, of-course, that you trust these programs). Picocom (starting with release 2.0) does not use /bin/sh to execute the file-upload and file-download programs and will not let the user inject shell-commands when supplying additional arguments to them.

  • If you allow send- and receive-file operations as described above, you will, most likely, also need a way for your users to put files on termbox, and get files back from it. There are many ways to arrange for this, but they are beyond the scope of this simple example.

Again, this is only one possible setup. There are countless other variations and elaborations you can try. Be creative!

Some notes on custom baudrate support

Custom baudrate support gives you the ability to set arbitrary baudrate values (like 1234, or 42000, etc) to a serial port, provided that the underlying driver can handle this. Since release 2.0, picocom can be compiled with custom baudrate support for some systems. Since release 3.1 picocom is compiled with support enabled by default on some systems (like Linux, kernels > 2.6, on x86 and x86_64, modern Intel Macs, and some BSDs). In any case, you can explicitly ask for support to be enabled by compiling picocom like this:

CPPFLAGS=-DUSE_CUSTOM_BAUD make clean
CPPFLAGS=-DUSE_CUSTOM_BAUD make

If custom baudrate support is not available for your system, the compilation will fail. Similarly, you can ask for support to be disabled by compiling like:

CPPFLAGS=-DNO_CUSTOM_BAUD make clean
CPPFLAGS=-DNO_CUSTOM_BAUD make

(or you can comment in or out the respective lines in the Makefile)

When picocom is compiled with custom baudrate support on Linux, it uses a new set of ioctl's (TCGETS2, TCSETSF2 vs TCGETS, TCSETSF, etc) to access the serial ports. It is not impossible that some systems or some serial devices may not accept these new ioctl's (though they should). In order to be able to use picocom even in this case, and without recompiling it, you can disable the custom baudrate support at runtime, and force picocom to use the "old" ioctls. To do this (starting with release 3.2) just define the environment variable NO_CUSTOM_BAUD before running picocom. Something like this:

NO_CUSTOM_BAUD=1 picocom ...

This only applies to Linux, and to picocom binaries that have been compiled with custom baudrate support.

To see if your binary has been compiled with custom baudrate support, and / or if it has detected the NO_CUSTOM_BAUD variable, run it with the --help option, and take a look at the first few lines of output.

picocom's People

Contributors

baruchsiach avatar bryant1410 avatar dleonard0 avatar enkiusz avatar germuth avatar girtsf avatar jpoppe avatar mrjohannchang avatar npat-efault avatar planteen avatar the-dem avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

picocom's Issues

port name is limited to 127 chars

When a longer port name is specified, it's truncated to 127 chars.

Of course, this is really rare case, but I'd run into this issue when using /dev/serial/ serial symlinks in Linux (Kubuntu).

I have to work with a device having a quite long device name, which finally evaluates to something like:

/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

My current ugly workaround:

  • wrote a bash script around the picocom call
  • following the symlink to e.g. /dev/ttyACM0
  • then passing /dev/ttyACM0 to picocom

I could provide a PR for this issue (replacing strncpy() by strdup() like doing for the log filename).

Add 'make install' target and build with autotools

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

Original issue reported on code.google.com by [email protected] on 2 Nov 2012 at 5:52

Prevent serial port becoming controlling terminal

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.

Original issue reported on code.google.com by [email protected] on 7 Oct 2011 at 7:55

Attachments:

Picocom for higher valid baud rates

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.

Original issue reported on code.google.com by [email protected] on 14 Feb 2014 at 3:45

Attachments:

Custom baud rate in OSX won't work

I'd recently added custom baud rate support for OSX, but after some more testing, I found out that it not work as expected. I'd tested with:

  • OSX El Capitan 10.11.6
  • Ftdi and Prolific adapters

In most cases, the desired custom baud rate will just be substituted by on of the standard baud rates.

I'll investigate it deeper now and hopefully provide a fix soon.

Make input buffer dynamically grow-able

Picocom uses a fixed-size serial port output buffer, the size of which is defined as TTY_Q_SZ in the makefile (32KB default for 2.1). This buffer should be made dynamically grow-able. malloc it at a reaonable initial size (say, 4KB) and double it (realloc) every time it fills-up. The TTY_Q_SZ macro (possibly renamed to TTY_Q_MAXSZ) should then be the maximum size the input buffer is allowed to grow (perhaps with 0 meaning unlimited).

[C-g] Toggle RTS needs to invoked double initially after program start

After starting picocom, the physical state of RTS is up on most systems (tested on Linux, OSX and FreeBsd).
When now pressing [C-g] = Toggle RTS, I got the message *** RTS: up *** and the physical state of the RTS handshake line won't change.
When now pressing [C-g] again, then I see *** RTS: down *** and the physical state of the RTS handshake goes down as expected.

When starting picocom with --lower-rts command line option, then the behavior is correct. Pressing [C-g] first time shows *** RTS: up *** and the physical state of the RTS toggles from down to up.

Same behavior is also with DTR.

Note, that when I press [C-v] after starting picocom, I got something like:

*** 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

(I think, I could provide a PR to fix this issue.)

Throttle reads from standard input if output queue is full

Currently picocom never stops / delays reading from the standard input (terminal) if data are available. If the output queue is full, data read are discarded. Maybe it would be better if we could delay reading from stdin until the output queue partially drains. This could be useful particularly when the standard input is not a terminal and, possibly, it should be done only in this case...

Man page update

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).


Original issue reported on code.google.com by [email protected] on 15 Sep 2013 at 11:27

Attachments:

How to write automated scripts for picocom

Hello, @npat-efault
I'd like to execute a list of commands after entering into picocom terminal.
This list is stored as an usual script on my host computer.
Is it possible to write an automated script which will do the following:

  1. enter to picocom terminal (that's easy one)
  2. execute a list of commands there
    Ideally, step 2 should be able to be repeated any number of times.

Why I need that?
I want to write files to my esp8266 using micropython. So when I connect to my esp using picocom, i can open a file in python command line and write my file line-by-line there. But I have to paste every command (every line) by hand. I want to do that automatically.

Hope you have grasped my idea. Is it possible?

Standard input must be a terminal

Why does picocom enforce that stdin must be a terminal? As far as I can tell, picocom's interaction with stdin (a simple select/read loop) shouldn't care what it is, and feeding picocom with a file or pipe would allow it to act as a general-purpose relay to and from a serial device. This would be incredibly useful for test scripts and other automation.

HUPCL handling

If, when picocom starts, the port's HUPCL is not set, then there is no way for picocom to HUP (drop DTR) when exiting...

small buffer size?

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.

Original issue reported on code.google.com by [email protected] on 5 Sep 2012 at 6:31

Cope with EAGAIN from read(2)

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.

Original issue reported on code.google.com by [email protected] on 12 Oct 2011 at 9:55

Attachments:

No fresh picocom in Ubuntu

Ubuntu repositories lacks a fresh picocom. Why?

$ sudo apt-get dist-upgrade
...

$ picocom --help
picocom v1.7

Open picocom inside cygwin from NTemacs term

I'm running 64bit cygwin and compiled/installed picocom. Picocom works from bash flawlessly. Now I'm trying to use a term inside a native 64bit NTEmacs. When I do I get "FATAL: failed to add I/O device: Filedes is not a tty". Any idea what is happening there? I know it's more like an emacs problem but I'm hoping you might be able to point me in the right direction based on the error message. The term access to any interactive source is notoriously problematic under Windows but I hope to get it running anyway. Currently I'm falling back to plink.

s/ecsape/escape/

Line 221 or so in picocom.1 has a misspelling for the escape option:

.B \f[B]--esacpe\f[] | \f[B]-e\f[]

Straying non-opt command line parameter were silently ignored

E.g. when typing:
$ picocom /dev/ttyUSB0 TRALALA BANANA
picocom starts up same as just
$ picocom /dev/ttyUSB0

So when I just forgot the -b switch like this:
$ picocom /dev/ttyUSB0 115200
picocom starts with standard baudrate of 9600 without a command line parameter warning.

Unable to create lock file

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).

Original issue reported on code.google.com by [email protected] on 25 Jul 2012 at 9:54

Whitespace

Whitespace in code is a bit of a mess (though not formatting, formatting is fine). At some places spaces are used, and TABs are used elsewhere. Also trailing whitespace is present at several lines.

It should be fixed.

  • Make all files use only spaces
  • Remove trailing spaces
  • Edit .editorconfig to make indent_style = space

Changes should not affect code formatting.

init with AT commands

Is there a way to send some AT commands to initialize? Can't find anything in the manual or examples.

patch for OpenBSD

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. 

Original issue reported on code.google.com by [email protected] on 1 Oct 2011 at 7:40

Attachments:

Android: possibility of building against bionic

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.

Original issue reported on code.google.com by [email protected] on 26 Aug 2013 at 2:50

Attachments:

Binary files

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,


Original issue reported on code.google.com by [email protected] on 13 Jul 2010 at 8:14

fails to build with musl libc

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

Original issue reported on code.google.com by [email protected] on 16 Jun 2015 at 1:01

Add "to hex" character mappings

Consider adding the following character mappings:

  • spchex: Map all "special" characters (< 0x20 || 0x7f) to their hexadecimal values, something like this: [17]. Exclude CR, LF and TAB (leave them as is)
  • tabhex: Map TAB to its hex value ('[09]')
  • crhex: Map CR to its hex value ([0d])
  • lfhex: Map LF to its hex value ([0a])
  • 8bithex: Map all bytes with the 8th bit set to their hex value
  • nrmhex: Map "normal" characters (0x20 <= c < 0x7f ) to their hexadecimal values.

(If more than one mappings apply for a char, then use a predefined mappings precedence order to decide which to apply. Eg: crlf, crhex or crhex, crlf will both map CR -> LF)

Doesn't compile on FreeBSD

After introduction of CMSPAR in term.c picocom fails to compile on FreeBSD

# 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.

Receive file with filename uses the send file command

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);
}}}






Original issue reported on code.google.com by [email protected] on 24 Jun 2010 at 4:48

[arm cross-compile] binary not found by bash

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.

Original issue reported on code.google.com by [email protected] on 31 Dec 2010 at 9:36

Attachments:

Restructure buffer scheme

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. 



Original issue reported on code.google.com by [email protected] on 2 Jun 2010 at 6:09

argument for command

Add one argument which will accept the command to execute and then exit the program

Divisor Patch

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.

Original issue reported on code.google.com by [email protected] on 29 Jan 2012 at 4:06

Attachments:

Problem in executing Picocom

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.

Original issue reported on code.google.com by [email protected] on 20 May 2011 at 11:48

Adding logging to file feature

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.

Original issue reported on code.google.com by [email protected] on 15 Jan 2014 at 8:08

Attachments:

Read multiple bytes from stdin with a single read(2) system call

Has not, practically, been a problem, but it would improve performanc if a single read(2) system call could be used to read multiple bytes (chars) from the standard input (terminal). Currently we do read multiple bytes from the serial port, as well as write multiple bytes to the standard output. Even a small read-buffer (say 16, 32 or 64 bytes) would be adequate.

--flow help/usage text is wrong

The help text prints --<f>low s (=soft) | h (=hard) | n (=none) but in fact x is the correct value to use for xon/xoff flow control. Took me a while to figure this out.

Use flock to lock serial port on Linux

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.

Original issue reported on code.google.com by [email protected] on 6 May 2015 at 11:38

Optimise call to select(2)

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).

Original issue reported on code.google.com by [email protected] on 12 Oct 2011 at 9:56

Attachments:

ZTE 3G module not responding to picocom

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.

Original issue reported on code.google.com by [email protected] on 2 Mar 2012 at 5:17

google code is shutting down

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 :)

Original issue reported on code.google.com by [email protected] on 16 Jun 2015 at 1:00

Backwards Compatibility

G'day Picocom People.

I have quite a few scripts that expect certain command line arguments for Picocom. Most of those were written quite some time ago, or are port of embedded systems. I am sure others have the same issue.

While it is possible to simply fix the scripts, it is trivial to allow picocom accept the same options from older versions.

These options are:
Allow "p" for parity (changed in commit c24a3bc) to still function. When using "p" for parity, simply set the stopbits to "1" (in line with the old behaviour)
(Why didn't stopbits use "o"!?)

Allow "s" for flow control (changed in 18ae438 and as I can see, it was simply to break backwards compatibility)

I was thinking of something like:

*************** 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;

-- Ben

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.