Tag Info

Hot answers tagged

32

These /dev nodes appear because the standard PC serial port driver is compiled into the kernel you're using, and it is finding UARTs. That causes /sys/devices/platform/serial8250 (or something compatible) to appear, so udev creates the corresponding /dev nodes. These UARTs are most likely one of the many features of your motherboard's chipset. Serial UARTs ...


5

Wow, that has to be the first time this century that I've heard rx referred to as a "great little utility"! :-) Yet we can still dust the cobwebs off those old commands. XMODEM: rx for receiving, sx for sending. YMODEM: rb for receiving, sb for sending. ZMODEM: rz for reveiving, sz for sending.


5

USB has a standardized method to learn device information including PID and VID. This information is available by the enumeration phase and takes place of the control endpoint. This is possible because there is an additional protocol on top of the raw data signals. The RS232 serial port is much simpler and does not have similar functionality defined. Data ...


5

If your program is logging without recreating the file (by opening it) you shoujld be able to do it by creating the file as a pipe: mkfifo potato.log You can send message to the pipe as if you were writing to the file: $ # This is the logging process: $ echo "Warning!" > potato.log And read them: $ # This is the listener process: $ cat potato.log ...


4

The rule syntax above may work on some distributions, but did not work on mine (Raspbian). Since I never found a single document that explains all the ins and outs, I wrote my own, to be found here. This is what it boils down to. 1. find out what's on ttyUSB: dmesg | grep ttyUSB 2. list all attributes of the device and pick out a unique identifier set, ...


4

Unix version 7 (1979): # ls -l /dev/console /dev/tty?* crw--w--w- 1 root 0, 0 Sep 22 06:46 /dev/console crw-rw-r-- 1 root 0, 1 Sep 22 05:47 /dev/tty1 crw-rw-r-- 1 root 0, 2 Sep 22 05:47 /dev/tty2 (no pty there yet) Linux 3.2.0 (debian wheezy). Note: you can also find these by searching /dev for owned by group tty and dialout. That's a Debian ...


3

I'm not quite certain what you're asking. You mention 'port' several times, but then in your example, you say the answer is /dev/ttyUSB0, which is a device dev path, not a port. So this answer is about finding the dev path for each device. Below is a quick and dirty script which walks through devices in /sys looking for USB devices with a ID_SERIAL ...


3

A Solution: The problem is that this serial port is non-PlugNPlay, and a system do not know which device was plugged in. Anyway, after reading a HowTo I get the working idea. An *nix-OS already have in /dev/ a files like ttySn where a n ending is a number. Most of this files is dumb i.e. doesn't correspond to an existing devices. But some of those is going ...


2

Imagine running Linux under virtualization, many of the emulator still rely on outputting console to serial port. It's a convenient standard. Also, headless server still use serial port for communication.


2

This solved the problem: $ socat -d -d pty,link=/dev/CUSTOMNAME,raw,echo=0,waitslave tcp:192.168.x.x:yyyy;


2

You don't need to modify the kernel, and you can automate it. Add the following single line to /etc/udev/rules.d/99-ftdi.rules ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", RUN+="/sbin/modprobe ftdi_sio" RUN+="/bin/sh -c 'echo 0403 6001 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'" Either reboot or run 'sudo udevadm control ...


1

You state that you have only 2 physical serial port which you detect to ttyS1 and ttyS2. ttyS3 and ttyS4 don't exist; they are exposed, but you have to ignore them. This is simply the way the driver works; it probes what may be a serial port and expose it to you, but you have to verify it is a real serial port because the driver can't be 100% sure. This ...


1

Most termios settings such as baud rate are retained even when a serial port is closed. However, closing a serial port does have some effects which you might not want, such as de-asserting DTR. However, you should be able to hold the serial port open in your application and avoid any unwated effects, including avoiding loss of any changes to settings that ...


1

I'd run lsof as root and then check to see which processes have /dev/tty* files open. Then trace down the process to determine what they are doing.


1

The main use of minicom during its heyday was for talking to modems which understood the Hayes command set (AT commands). AT commands are terminated by carriage return. It was convenient to be able to type ATDT5550123 Enter and have the correct command terminator sent to the modem.


1

I guess you're using KDE. You need to use the kdesu command instead of the sudo for programs that are using X.


1

You can use a programming language to open a socket and roll-your-own library, using the modbus spec. Otherwise you can use an existing library, I have no experience with any of them, but this looked promising: http://libmodbus.org/documentation/


1

I’m not sure I understand the big picture of what you’re asking for, but I have a couple of approaches that you might want to consider: Use dd to read your input file exec 3 < input_file while true do dd bs=1 count=1 <&3 > this_byte if ! [ -s this_byte ] # If size is zero, we’re done. then break fi code using ...


1

On a linux 3.8.2 source tree: $ cscope -dL1 '.*MAJOR' | grep -e TTY -e PTS -e PTY drivers/s390/char/sclp_vt220.c .*MAJOR 31 #define SCLP_VT220_MAJOR TTY_MAJOR drivers/staging/net/pc300_tty.c .*MAJOR 62 #define CPC_TTY_MAJOR CYCLADES_MAJOR drivers/staging/sb105x/sb_pci_mp.h .*MAJOR 42 #define SB_TTY_MP_MAJOR 54 drivers/tty/rocket_int.h .*MAJOR 1168 #define ...


1

You might want to take a look at http://serialconsole.sourceforge.net Pro: doesn't have obvious security problems like minicom or picocom (if you don't have a problem giving the users shell access, no problem, but you most likely do have one if you want to set up a terminal server...)


1

The steps bellow worked for me: Firstly you have to pair the devices. Pairing is relatively easy. I will call client (who starts talking) and server (who replies) You have to setup the server before: Server side (as root): sdptool add --channel=3 SP mknod -m 666 /dev/rfcomm0 c 216 0 rfcomm watch /dev/rfcomm0 3 /sbin/agetty rfcomm0 115200 linux Client ...


1

I wouldn't go through cups: CUPS is very problematic about RAW devices. It's much easier to do it like so: #!/bin/bash cu -E `` /dev/ttyAMA0 < $1 (I can't remember for sure if you are requiring back-ticks (``) or single-quotes (''). cu calls up the modem. [-E ``] sets the escape sequence to null. < redirects $1 to the modem over the serial line. ...


1

Try socat - /dev/ttyUSB2,crnl This tells socat to send a carriage return as well as a line feed. Clarification - this goes back to the dark days of electric typewriters, where you would have to tell it to roll the carriage back to position 0 on the page - ergo, a carriage return - as well as telling it to move the paper up one line.



Only top voted, non community-wiki answers of a minimum length are eligible