Contents. Minicom Introduction Minicom is a text-based serial port communications program. It is used to talk to external RS-232 devices such as mobile phones, routers, and serial console ports. Installation Install the program with: sudo apt-get install minicom Alternatively, you can get Minicom via the Synaptic Package Manager.
Background The main reason why you need any program like minicom to communicate over a serial port is that the port needs to be set up prior to initiating a connection. If it weren't set up appropriately, the cat and echo commands would not do for you what you might have expected. Notice that once you run a program like minicom, the port is left with the settings that minicom used. You can query the communication settings using the stty program like this: stty. Picocom also will let you connect to a serial port without reconfiguring it ( -noinit) and will let you exit without restoring the serial port configuration ( -noreset or use Ctrl-A/ Ctrl-Q to quit picocom).
I've found picocom to be much easier to use than minicom. For reasons I haven't figured out, minicom will sometime simply not send or receive data on a port that worked moments before or that picocom has no trouble with. It's probably some arcane configuration option, but whatever it is I can't figure it out (and this behavior has happened on more than one machine). – Oct 24 '13 at 21:11. I found a way using a shell script that put cat as a background process and a while loop that read the user input and echo it out to the port. I modified it to be more general and it fitted my purpose perfectly.
#!/bin/sh # connect.sh # Usage: # $ connect.sh # Example: connect.sh /dev/ttyS0 9600 # Set up device stty -F $1 $2 # Let cat read the device $1 in the background cat $1 & # Capture PID of background process so it is possible to terminate it when done bgPid=$! # Read commands from user, send them to device $1 while read cmd do echo '$cmd' done $1 # Terminate background read process kill $bgPid. Howerver, the real gotcha in your script is that the background process is only killed if you press Ctrl+D to end your script, because that ends the while loop cleanly. If you kill it with Ctrl+C or with the kill command, then the cat process stays alive. To fix that you would need to use the trap command to execute kill $bgPid when the shell exits, like.
Honestly, I wouldn't even mind if you just added my whole script to your post. I tried to do that, but the edit was rejected. – Sep 26 '16 at 11:08. This script is based on, but sends everything over the serial port (except Ctrl+Q), not just single commands followed by Enter.
This enables you to use Ctrl+C or Ctrl+Z on the remote host, and to use interactive 'GUI' programs like aptitude or alsamixer. It can be quit by pressing Ctrl+Q. #!/bin/bash if $# -lt 1 ; then echo 'Usage:' echo ' femtocom. It depends on what you want to do. Do you want to run a shell or applicaiton interactively from the terminal, connect out to another computer over the serial line, automate communication with a device over a serial port? If you want bidirectional communication then I presume you want something interactive with a human on the terminal. You can configure the system to allow logins from a terminal over a serial port by seting up a session on the serial port - getty is the tool for setting up a terminal and allowing logins onto it.
Put an entry in your file to run it on the appropriate serial port on a respawn basis. If you want to connect to a device and initiate automated two way conversations then you could see if will get you what you want. Use to configure the port to the right parity, baud rate and other relevant settings. If you want to communicate interactively with another computer over the serial port then you will need terminal emulation software. This does quite a lot - it sets up the port, interprets ANSI or other terminal command sequences (ANSI was far from being the only standard supported by serial terminals). Many terminal emulators also support file transfer protocols such as kermit or zmodem.
The ins and outs of serial communications and terminal I/O are fairly complex; you can read more than you ever wanted to know on the subject in the. Putty works well on Linux and offers some convenience, especially for serial communications. It has one drawback I haven't been able to directly solve: no copy-paste from the Putty window itself. The windows version has a lovely auto-copy to clipboard on highlight, right-click to paste behaviour (and there are excellent plugins for both chrome and firefox to enable the same behavior), but on Linux, no copy love AFAIK.
If the lack of copy is a problem (it is for me) then turn on logging in putty and open a standard terminal window and # tail -f putty.log and bidirectional text is available for standard copypasta action. I find that Putty under Linux doesn't paste 'the clipboard' (what you copy with control-C), but it will insert 'the primary selection' (what you have currently selected in some program) with middle-mouse. Likewise you can select characters in Putty's screen to define the primary selection. But if I want text from a Putty screen to transfer to some VM, I need it to be the clipboard, so I have to use an intermediary program to receive the text from the main selection and then copy it to the clipboard. – Feb 28 '17 at 19:58.
You need to be sure to have the correct read write permits on the device, you could see it with: $ls -l /dev/serial device I rely on the script you found and made some modifications. For the development systems I've used by now, they used to need:. None parity and. One stop bit Those values are the default ones in the script.
So in order to connect, you can use it as simple as follows:./connect.sh /dev/serial device baud speed Example: $./connect.sh /dev/ttyUSB0 19200 Script: #!/bin/bash # connect.sh #Taken from example modified by: ihatetoregister # On stack exchange, thread: # # Modified by Rafael Karosuo # - parity enabling and amount of stop bits # - no execution without minimum params # - exit code for stty # - bgPid fix, used $! Instead of $?
To take the PID of cat proc in background. (1) #!/bin/sh is ignored if it isn’t the first line of the file. You’re using 1 to specify even parity and 2 to specify odd? (3) It’s conventional to have a “usage” or “help” message that documents all the parameters, not just the mandatory ones.
(4) You should always quote your shell variable references (e.g., '$1', '$2', '$3', '$4', '$stopb', '$par', '$bgPid', and even '$?' ) unless you have a good reason not to, and you’re sure you know what you’re doing. – Jul 9 '16 at 7:15.