My program begins like this:
#!/usr/bin/env python
import sys
from serial import Serial, EIGHTBITS, PARITY_NONE, STOPBITS_ONE
SERIAL_DEVICE = '/dev/ttyUSB0'
ser = Serial(SERIAL_DEVICE, timeout=2, baudrate=9600, bytesize=EIGHTBITS,
parity=PARITY_NONE, stopbits=STOPBITS_ONE)
The next part of the program sends something to the device and then expects a response. When I run it after reboot, it doesn't find the response it is expecting and terminates with an error (this is correct behavior apart from the fact that it doesn't see the response it expects).
However, if I run minicom and talk to the device through minicom, it works fine. If then I close minicom and run the program, it runs fine. The minicom configuration has an empty initialization string and I always exit without reset.
Needless to say, minicom has the same settings AFAICS. It also has hardware control on, but I did try rtscts=True as an argument to Serial() and saw no difference (and even if I had an error in the arguments, this doesn't explain why after executing minicom the program works properly).
The symptom you have is an indication that your program is not initializing the serial terminal to the proper mode that it requires.
minicom has the same settings AFAICS
Seems like you choose to guess rather than gather actual data.
Use stty -a -F /dev/ttyUSB0 before and after using minicom.
The major difference is that the termios mode is probably canonical by default (after the reboot), and minicom leaves it in non-canonical mode.
Try using stty raw -F /dev/ttyUSB0 before starting your program.
Related
I am attempting to programmatically read the output written by an application running in a specific tmux pane, so that I can determine when to send-keys to it from a controlling process.
In particular, I would like to automatically enter a password, but I do not want to enter it until I am sure the password prompt has appeared.
My current attempt has been to use tty to find the controlling tty, and then pass it to pyserial to try to read, since it appears to be able to read tty's. Note that in the real application, I have other ways of finding out the tty.
Unfortunately, as soon as I run the following code, the target tmux pane immediately closes.
import serial
ser = serial.Serial('/dev/ttys013', timeout=1)
Is it possible to read from a pty this way?
I am running on OSX, but would appreciate a solution that works on both Linux and OSX.
Typically, with python you would use pexpect to start the program and interact with it via a pty, but if you already have a program running in tmux you could simply use tmux's pipe-pane command to save a copy in a file of what is written to the screen. For example, for a pane number 1 you can give the shell command:
tmux pipe-pane -t 1 'cat >/tmp/capture'
and then tail the file /tmp/capture. (Use tmux pipe-pane -t 1 to stop).
To avoid polling, you can use a fifo instead.
I am connected on my embedded device with the serial port and would like to start my custom binaries on boot and be able to see the output generated.
My /etc/inittab file contains:
console::respawn:/sbin/getty -L 115200 ttyAPP3 vt100
console::respawn:/usr/bin/mybinary
With this configuration, I can see the output of mybinary in the serial console but It is difficult/impossible to connect (insert login and password) to getty because of the interference of the output generated.
I tried to switch the output in inittab to another not used tty (tty10) like this:
console::respawn:/sbin/getty -L 115200 ttyAPP3 vt100
tty10::respawn:/usr/bin/mybinary
And now I can connect but how can I see the output generated to /dev/tty10 ?
I tried cat /dev/tty10 but nothing is shown.
I know the question is old, but it has no answers at all for crying out loud.
Remember that a TTY is both an output device and also an input device -- by cat'ing from it you're reading input from the terminal which means the keyboard, NOT the screen.
I don't know if there's a parallel in other *nixes, but Linux systems have /dev/vcsX and /dev/vcsaX character devices (nodes c,7,0+X and c,7,128+X respectively) for each /dev/ttyX device - these are mirrors of the data currently on the output of the TTY device (ie. the screen part of the TTY, not the keyboard part). These will give you what you're looking for. The vcsaX devices will give you a displaybyte+attributebyte pair (i.e. the foreground/background text colour -- see other references for more information on text attribute bytes) for each character on the screen, while the vcsX devices give only the displaybyte for each character. Of course it's a raw stream/dump so if the row and/or column count of your terminal doesn't match that of the the TTY you're dumping then you'll need to parse the data and reformat it to match.
tl;dr: use "cat /dev/vcs10"
Hope that helps.
I'm trying to write to a serial port and read results via bash scrpts (echo, printf, and read). I've setup stty correctly as far as I can workout, but I can't read any characters back.
If I place port in loopback, I can use minicom to send and receive characters ok. yay :)
but when I quit minicom, and echo some chars to the device, the seial port flashes rx led once, and reading doesn't not show any characters. Further echo commands do NOT cause the rx led to flash, so it seems I can only send once.
Any ideas what could be going on and how I can get things working.
Thanks, Brendan.
I have problem sending AT commands to my USB modem.
At first I tried php-serial class, but when i was reading data, I got endless loop with strange data. Then I tried to debug problem and opened putty terminal, made command
cat /dev/ttyUSB0
and then sent command echo "AT" > /dev/ttyUSB0 after that I always got never ending loop from cat /dev/ttyUSB0 like this:
AT
AT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^JAT^
and this loop never ends. On windows all works just fine. I can connect to USB modem via virtual COM port and send command / get answer.
Question is why cant I just receive "OK" message from console, but instead of this I got this data loop ?
Tried different huawei USB modems, and different stty settings and also default settings for huawei modems:
Baud rate: 9600 / 115200
Parity: none
Data bits = 8
Stop bits = 1
Flow control = none
I have a bluetooth remote that is paired with my linux box, when active, this remote is visible at /dev/input/event13.
I have a small C program that open this device and read directly from it, which works fine.
Now, my problem is that this remote goes to sleep after a few minutes of inactivity and /dev/input/event13 disappears. It reappears as soon as I press a key on my remote.
I put the output of udevadm here: https://gist.github.com/9fff2f0d7edef1050060.
I use the following code (small ruby ext I wrote), to read from the device: https://gist.github.com/b403d538eb6a8627e2bd.
I thought of writing an udev rule that would start my program when my remote is added and stop it when it is removed. I read the udev documentation, but I couldn't figure it out how to do it. I'm open for suggestion.
After some digging and a lot of frustration I did the following:
I put into /etc/udev/rules.d/99-rmote.rules
KERNEL=="event*", SUBSYSTEM=="input", ACTION=="add|remove", ATTRS{name}=="TiVo Keyboard Remote", RUN+="/home/kuon/handleConnect.rb"
And in handleConnect.rb I check the ACTION environment variable and I start/stop my daemon accordingly. Quite simple in the end and it works well.