I have two usb to serial cables collected to a null modem and then the two usb connections connected two seperate usb ports on my linux machine
I want to write a program that allows them to communicate back and forth through a terminal, and wanted to test the two ports using screen
I type screen ttyUSB0 115200 but it just comes up with a blank terminal with no text, i realize i am supposed to use commands but I cant find a guide anywhere on how to use this to test to make sure the serial ports are sending/receiving data among other things, could someone point me in the right direction?
I have two usb to serial cables ...
Those are not just "cables", but rather adapters.
Besides the copper wire, there is an IC with a microprocessor, RAM, and ROM inside that dongle. Your PC will recognize each USB-to-serial adapter as a (USB-based) serial port.
IOW you have two serial ports.
Therefore you need two (not just one) instances of a terminal emulator program (e.g. screen), one for each serial port.
Unless you have both terminals perfectly configured, you may have confusing issues such as no echo (what you type shows up in the other terminal, but is not displayed in the terminal where you're typing), and the Enter key only responds as a new line with vertical movement of the cursor and no horizontal movement.
I want to write a program that allows them to communicate back and forth ...
That's possible so long as you open() both serial terminal devices.
Related
I have a system with two (or more for that matter) ubertooth sticks connected. I command them with
ubertooth-util -U devNumber ...
and
ubertooth-rxtx -U devNumber ...
with devNumber from {0, 1} respectively. I have them connected to a USB hub with per port power switching (supported by uhubctl) so that whenever one gets in a bad state I can switch them off, unbind them and switch them on again.
But which "devNumber" is connected to which port of the USB hub? For devices like USB WLAN cards this is simply done by observing their representation in the /sys-filesystem but the ubertooth sticks do not appear there since no dedicated driver touches them (at least that is what I understand).
I could switch the ports off one by one and check which device still takes a command to create the mapping.
Or I could issue "ubertooth-util -U devNumber -s" and "lsusb -v" and then map by serial number which seems even worse.
Is there a simpler way?
I'm trying to send files over a half-duplex interface (RS-485) between a box PC running debian (4.19) and a SBC with an im6xDL.
Thanks to this community I can successfully transfer simple data between the units using picocom or by echoing/reading.
The box PC supports half-duplex RS-485 natively and has automatic RTS functions so that you can read/send data without any issue. The SBC on the other hand needs to be toggled to change into RX or TX mode.
This turned out to be a problem when I tried to send files from the box PC to the SBC.
On the box PC:
picocom /dev/ttyUSB0 -b 9600 -fn
C-a,C-S
***file: /home/user/test.txt
Transfer incomplete
*** exit status: 128
On the SBC
picocom /dev/ttymxc2 -b 9600 -fn -et
C-a,C-r
Terminal ready
�000000
As you can see something is terribly wrong, it is like it cannot interpret the bits when a file is being transferred.
My questions:
Is it possible to send files from the command line in half-duplex systems? (The SBC needs to be in RX mode the entire time).
Is there another way to achieve this that is more intuitive?
As always, thanks for the help and support :)
/W
See here:
Pymodbus - Read input register of Energy meter over rs485 on uart of raspberry pi3
The solution I presented there using pylibmodbus should work for any hardware with UART and one or two GPIO lines accessible from user space in Linux.
If, on the other hand, what you want to do is use something like picocom or minicom then you can take a look at the hardware-only solution using a 555 timer.
Of course, if prototyping circuits is not for you, you can always buy a USB to RS485 with half-duplex support. You have many available but those based on the MAX13487 IC seem to work very well.
EDIT: The solution using the 555 timer is not in the post I linked above but here together with some more background material on half-duplex RS485 links: RS485: Inappropriate ioctl for device
I am developing an embedded solution using C and I am working with two USB sensors. If I connect each sensor alone they take this names:
Device 1 (I do not know why it takes 6 names...)
/dev/ttyACM0
/dev/ttyACM1
/dev/ttyACM2
/dev/ttyACM3
/dev/ttyACM4
/dev/ttyACM5
/dev/ttyACM6
Device 2
/dev/ttyACM0
So when I start as an embedded system and both sensors are connected, the fastest one takes /dev/ACM0 but it not always the same. So, when I try to read device 2 I could be reading device 1...
I think that It would be great to change the default names of the sensors. I guess that it is going to be possible but I do not find anything.
You should try using the names in /dev/serial/by-id instead, since those names include the name of the device and should not depend on the order of connection.
By the way, it is also possible to write udev rules that make symbolic links for the serial ports depending on what device they belong to. I am not sure how that would work for a composite device with 6 serial ports, but there probably is a way to make it work.
I have a 40x7 VFD that functions as a serial terminal. It has a dedicated keypad that provides hex-entry, however, I would like to use a keyboard for the standard input. Basically, I want to be able to use the VFD as a display for a Linux bash prompt, but use the keyboard connected to the computer as the means of input. Instead of connecting a monitor, the serial terminal will be the monitor. I can get the login prompt displayed on the VFD with agetty, but since it only has hex-entry, how can I change where the system is looking for standard input?
Thanks,
Core_Module
I think the best method would be to create a pseudo terminal. In doing so you create a fake terminal device with a /dev/pts/[n] name that acts like a real input/output device. A program could connect the console (keyboard) as input and the VFD as output and send and receive that data over the pseudo device. You can then point agetty at the /dev/pts/[0] device instead of a /dev/ttyS[n] device. Some ideas on doing this can be found in many tutorials online. From the link:
A pseudo-terminal is a pair of character mode devices also called pty. One is master and the other is slave and they are connected with a bidirectional channel. Any data written on the slave side is forwarded to the output of the master side. Conversely, any data written on the master side is forwarded to the output of the slave.
I found another StackOverflow question that may also be of assistance. See this link. It could be adapted to suit your needs.
I have a Linux USB HID device (a Hama MCE), and I can read its events manually by reading cat /dev/input/event7 and cat /dev/input/event8. Whenever I press a key on the device, a few bytes become available for reading with one of the cat commands above. I have a default installation of Ubuntu Jaunty 64-bit desktop on the machine.
I think I can write a parser to interpret the bytes emitted by the device, or I'll use libhid if it's more convenient.
My questions are:
How do I prevent the text-mode virtual consoles from receiving some of the key presses on the device as normal keypresses? As of now, some device keys result an Enter, a BackSpace, a PageUp or numeric keypad numbers.
Similarly, how do I prevent the X server from receiving keyboard and mouse events from this device? I have several USB keyboards and mice connected to the computer. I want the X server receive events from all of them, except for this device.
How do I set up that whenever the device gets connected to the computer, the command /usr/local/bin/keydumper /dev/input/event7 /dev/input/event8 (or one command for each /dev/ path) would get run, with the proper /dev/ paths substituted in the command line?
Answering my own question based on answers from the Linux USB HID driver developers:
Question 1. and 2.: Do
ioctl(open("/dev/input/event7", O_RDONLY), EVIOCGRAB, 1);
As long as this filehandle is open, the events generated would go only
to this filehandle (not to other open()s of the same device or to the
system keyboard or mouse event pool). At most one process can hold a
successful EVIOCGRAB at a HID device at a time. Lirc can be configured
to do an EVIOCGRAB.
Question 3.: Configure udev to start the program once the device is connected.
I do not have enough points to comment sadly.
If you are looking for the definition of EVIOCGRAB try
#include <linux/input.h>
I think solution for all questions can be writing own filter device driver, or custom driver for your device. I know such a thing (filter device driver) is available on windows so something similar can be on Linux. In that filter device driver you could block all unwanted events from the target device that you wish to block, I don't really get 3 question so I don't know how to answer for that.