Hot answers tagged

4

socat is a tool to connect (nearly) everything to (nearly) everything. In your usecase you could connect your serial port /dev/ttyS0 to a PTY /tmp/ttyV0, then point your application to the PTY, and have socat tee out Input and Output somewhere for you to observe. Googling "socat serial port pty tee debug" will point you to several examples, one being: $ ...


4

If you stick a serial loopback adapter in the specified serial port: Yes. If you want to debug an application talking through a serial port, you could use this command: socat /dev/ttyS0,raw,echo=0 SYSTEM:'tee input.txt | socat - "PTY,link=/tmp/ttyV0,raw,echo=0,waitslave" | tee output.txt' (From http://unix.stackexchange.com/a/225904/127903)


3

This is typically done using the tcsendbreak C library routine. You can get to this from the shell by using a Python or Perl one-liner: python -c 'import termios; termios.tcsendbreak(3, 0)' 3>/dev/yourdevicename perl -e 'use POSIX; tcsendbreak(3, 0)' 3>/dev/yourdevicename


3

Well after a lot of debugging (and head banging against the wall) in the init script that I was using to switch_root to the directory where debian is, I did not mount /dev, /proc and /sys... The correct tty was actually 1:2345:respawn:/sbin/getty ttyHSL0 115200


3

There might be simpler and more robust ways to transfer files, but this should work: base64 encode your file on the host system base64 file > file.64 Redirect the serial output to a file on the Pi: cat < /dev/ttyAMA0 > file.64 Use minicom's paste feature: Ctrl + A, Y, then select the file to be transferred. Press Ctrl + D on the Pi after the ...


3

RTS and DTR are output pins - which you can set. DCD and CTS are input pins and can only be read. The device is probably set for hardware handshaking by default. You can change this using tcsetattr (see CRTSCTS). Then you can use the TIOCMBIS ioctl to set RTS and DTR Good references are: Linux Serial HOWTO Linux Serial Programming HOWTO The above might ...


2

As mentioned before you can try picocom. The latest release (2.0) can also be used (safely) to set-up a "terminal server" since it no longer permits shell command injection. See: https://github.com/npat-efault/picocom/releases


2

Use dd or xxd (part of Vim), for example to read one byte (-l) at offset 100 (-s) from binary file try: xxd -p -l1 -s 100 file.bin to use hex offsets, in Bash you can use this syntax $((16#64)), e.g.: echo $((16#$(xxd -p -l1 -s $((16#FC)) file.bin))) which reads byte at offset FC and print it in decimal format. Alternatively use dd, like: dd ...


2

Each type of USB device sends data in its own way. It's up to the driver to decide what to do with the data. For data sent through a serial device, simply read from /dev/ttyUSBn. </dev/ttyUSB0 awk ' {data += $0} /record end/ {print $0 | "process-one-record #" NR} '


2

Argh and grumble. I should have paid better attention to the output of dmesg | grep ftdi. There was ftdi stuff in there, but I didn't recognize any of it. In particular one brltty was showing up. I should have googled it. At which point I would have discovered this is the "Braille Display" thing. So apparently, default out of the box sets up some braille ...


2

TFTP is a protocol that runs over UDP/IP, so you need an IP network. A serial port by itself does not provide an IP network. To provide IP over a serial port, you have to run a protocol such as PPP. how to tftp with telnet over wifi TFTP and telnet are two separate protocols that run over IP and have nothing to do with each other. I don't know what you ...


2

As you say, you cannot read end-of-file from a serial port. (Ctrl-Z is a microsoft thing). So usually, you read until you have the wanted number of characters, or until you find a delimiter like newline that signals the end of the data. For example, I have a usb serial port with output connected back to input, so any writes to the device simply come ...


2

You can use lspci -v to list PCI device information, along with their IRQs. Correlate the IRQ listed via lspci with the setserial info you already gathered, and that should tell you what tty matches which PCI card. Also, if the port is disabled, you can enable it using setpci. More info on how to determine that, and how to enable it, can be found here: ...


2

There is a flag called HUPCL: If this bit is set, a modem disconnect is generated when all processes that have the terminal device open have either closed the file or exited. A "modem disconnect" apparently involves toggling the RTS line, because once that flag is disabled, the behavior goes away regardless of the CRTSCTS flag setting. Here is ...


2

For efficiency, grep and many other commands use buffered I/O, that is, they read large blocks of data at once (rather than, say, one character at a time), and do not output data until a certain amount has been amassed (rather than, say, writing a line at a time or a character at a time) But, when a program's input is from a terminal (such as your serial ...


2

EDIT: This won't work if you have a recent udev version, because udev prevents you from starting long-lived background processes in RUN scripts. You may or may not be able to get around this by prefixing the getty command with setsid but in any case it's discouraged if not outright disallowed. If you have a system which uses systemd then there is another way ...


2

You could launch getty once you've booted to get a serial connection to your system. Note that this will not give you the default outputs typically seen with your console (Kernel Panics and other verbosities typically seen in console but not in normal terminals). But if you are just looking to get a login via serial after boot this should work. /sbin/agetty ...


2

Under linux your devices have not meta-names like com1 or so. Your usb-adapter is added to the /dev-directory with a driver specific name. The most usb-uart adapter use the name /dev/ttyUSB* where the * is a number beginning at 0. The best way to get this name is to view the changes of kernel messages via dmesg before and after plugin of the adapter. You ...


1

Unless I am misreading your question, the answer is yes; were it not possible to do, no device drivers could exist. You won't be able to read any USB device as plaintext or anything like that, though, and you will need direct access to the usb device node. Drivers may interfere with reading from them. But on a theoretical level, yes, one may read data from ...


1

Try the following: sudo apt-get install python-serial import serial port = serial.Serial("/dev/ttyUSB0", baudrate=115200, timeout=3.0) while True: port.write("\r\nSay something:") rcv = port.read(10) port.write("\r\nYou sent:" + repr(rcv))


1

You can use the stty command to set such parameters. This will show all settings on the first serial port (replace ttyS0 with ttyUSB0 if using an USB serial port): stty -F /dev/ttyS0 -a This will set the baud rate to 9600, 8 bits, 1 stop bit, no parity: stty -F /dev/ttyS0 9600 cs8 -cstopb -parenb One thing that generally confuses people is that most ...


1

You will have to write some C code, as described in the kernel doc. #include <linux/serial.h> struct serial_rs485 rs485conf = {0}; int fd = open ("/dev/ttyACM0", O_RDWR); if (fd < 0)... rs485conf.flags |= SER_RS485_ENABLED; if (ioctl (fd, TIOCSRS485, &rs485conf) < 0)...


1

sx doesn't talk to serial ports by itself; it communicates over stdout. You need to redirect the output for it to do anything useful. Personally, I find it easiest to use cu to set up the serial connection, run whatever is needed on the remote end to start receiving data with *MODEM, and then use cu's escape codes to run sx locally. You can do this with ...


1

Try: minicom -b 9600 -o -D /dev/ttyUSB0 Note: Use this command to list your usb devices if you are unsure of the device. ls -lah /dev/ttyUSB*


1

In a udev rule, you can only match against one device. You can choose which device to match against, but you can't mix conditions from multiple devices. As it says in the output of udevadm info: A rule to match, can be composed by the attributes of the device and the attributes from one single parent device. The one parent that has ...


1

By default minicom listens for serial data on /dev/modem, this is typically a symlink to the first serial TTY. Sometimes the first serial TTY is not the hardware DB9 port. So the first thing you need to know is which serial TTY your Utilite device is connected to. The easiest way to do that would be run: for $dev in $(ls /dev/ttyS*); do temp=$(mktemp) ...


1

How are received bytes stored? From the user space's point of view, they are not stored at all. How to read them? If you mean only to read them, simply cat /dev/ttyS... will do. Some more information as to how to deal with serial interfaces can be seen in multitude of answers and comments in this page and in the internet in general withing seconds of ...


1

serial ports don't support the telnet TCP protocol, telnet is falling back to linemode,you need to disable telnet linemode so that it will use character mode. type ctrl-]mode characterenter and then log in.


1

IIRC Jetson TK1's DB9 is connected to /dev/ttyS0 on Linux kernel. And the default Ubuntu distribution sets it up as kernel's console device (see cat /proc/consoles) and runs getty on it. You need to stop them for your application to use /dev/ttyS0 exclusively. To stop getty you could run stop ttyS0. I don't know how to detach /dev/ttyS0 from kernel ...


1

(By the way, I've never seen the spelling "GeTTY". I don't think it's correct.) The short answer is that you can disable getty by commenting it out in /etc/inittab and running init q to reread configuration. Unless you're using systemd or Upstart but since you didn't say so I'll assume you aren't. The longer answer is that your setup has an intrinsic ...



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