I need to use USB serial cable with baud rate of 115200.
I tried to set the rate with stty command from MACbook terminal application as follows;
$stty -f /dev/tty.usbserial-A103BTIB 115200
and confirmed the settings as follows;
$stty -f /dev/tty.usbserial-A103BTIB -a
&speed 9600 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
-echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
-nokerninfo -extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8
-ignbrk -brkint -inpck -ignpar -parmrk
oflags: -opost -onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
It looks baud rate is till 9600. Could somebody show me how to change this step by step ?
It seems like this is a common problem of stty command in OSX and not solved.
https://discussions.apple.com/thread/3798003?tstart=0
I was able to set the baudrate temporarily by running screen session
$ screen /dev/cu.usbserial-FTHHQD0C 115200
and opening another terminal to run my script.
Other option to set a rigid baud value is to:
Launch a connection with the usbserial port, redirecting the output by cat in separate terminal window (to keep the port open):
cat -v /dev/tty.usbserial-A103BTIB
Set the baud:
stty -f /dev/tty.usbserial-A103BTIB 115200
The baud value stays set.
Related
Trying to connect to a Tevo Tornado 3D printer connected to my MacBook Air via a USB cable.
In terminal I identify the USB devcice and try to connect to it using:
> js$ ls /dev/tty* | grep usb
/dev/tty.usbserial-1410
> js$ screen /dev/tty.usbserial-1410
but that yields an unresponsive screen with random looking characters:
If I connect the printer to a Raspberry Pi running OctoPrint software I can look at the terminal output on the Pi's OctoPrint webpage and see the following exchange:
Connecting to: /dev/ttyUSB0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0xabb411d0, open=True>(port='/dev/ttyUSB0'
,baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0
,xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0M110 N0*125
Send: N0 M110 N0*125
Recv: start
Recv: echo:Marlin TORNADO
Send: N0 M110 N0*125
Recv:
...
This lists the baud rate and other connection parameters that allow that software to successfully connect to the printer. Back in terminal, with the printer re-connected directly to the Mac's USB port, I tried to connect by feeding the above information into the screen command like so:
screen /dev/tty.usbserial-14210 250000,cs8,-parenb,-cstopb,-ixoff
I also tried other variations, but they all yield the unresponsive terminal screen above.
Does anyone have any ideas on what I'm doing wrong and how I can connect to this USB device using Terminal on my Mac?
Update, Ran stty on the octopi connected to the printer and got these results:
pi#octopi:~ $ stty < /dev/ttyUSB0 -a
speed 0 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
discard = ^O; min = 0; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany
-imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl
-echoke -flusho -extproc
Update2:
After looking at source code on the OctoPi there is a file called comm.py. It details a process of opening and closing the port while switching parity settings. Apparently this is some kind of common bug/feature??? This is necessary to do for the Python serial library to connect, which I can now do BTW. Here is the code from comm.py which is part of OctoPrint Source:
use_parity_workaround = settings().get(["serial", "useParityWorkaround"])
needs_parity_workaround = get_os() == "linux" and os.path.exists("/etc/debian_version") # See #673
if use_parity_workaround == "always" or (needs_parity_workaround and use_parity_workaround == "detect"):
serial_obj.parity = serial.PARITY_ODD
serial_obj.open()
serial_obj.close()
serial_obj.parity = serial.PARITY_NONE
serial_obj.open()
I still don't know how to get screen to do this disconnect-change parity-connect process though. So maybe screen is not a possibility???
I don't understand why return doesn't have it's own key when working with the readline of bash.
Using control+m is the same as using return.
How to create two separate keybindings, one for control+m and another function for return?
The same applies to arrow-up/-down etc. . Printing them quoted shows that they are not a seperate key, but a key sequence, so I can not use that sequence for another function.
If you changed that, you would find it cumbersome to use any terminal application, because all of the POSIX-like systems use "newline" for ending lines. An ASCII carriage return ^M is normally translated into a newline (which happens to be encoded as ASCII line-feed ^J). If you run stty -a on your terminal you may notice something like this:
~ (4) stty -a
speed 38400 baud; 40 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff -ixany -imaxbel -iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
The icrnl says that carriage-return is mapped to newline. So... if you break your return key, you could type control/M or control/J every time you want a newline. Most people prefer just pressing one key for that purpose.
I got into a strange behaviour of my terminal. Both iTerm and basic terminal on my OS X don't work. I can only type 'A' instead of 'a', but not the 'a' letter. If I try bash --noediting then I can type 'a' but it's very uncomfortable to use. I checked my ~/.bashrc, ~/.bash_profile and did't find anything that seemed strange for me. Could anyone help me?
Any feedback appreciated.
Most likely you've somehow introduced a readline binding for a.
As a first step, try this: (The grep argument is $"a", but you can't type that :) )
bind -p | grep $'"\x61"'
It should print this:
"a": self-insert
If it does, then my guess is wrong, and you'll need to look elsewhere. If it doesn't, then you need to fix it, which you can do like this:
bind $'"\x61"':self-insert
Now you need to find where in your bash start-up files the incorrect bind command is. I'd start by grepping for bind. It may well be in a file sourced from one of those files. Good luck.
You should also check the file ~/.inputrc which is used by the readline library to initialize it's bindings.
If the letter a has been mapped to one of the control characters, you can get some funny effects. Try stty -a, except that you'll probably need to type:
s, t, t, y, , -, Control-V, a
to get the -a to the command. This should show you something like:
speed 9600 baud; 65 rows; 135 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^X; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
except that if my suspicion is correct, one of the cchars values is a.
I have a preblem with my Mac Terminal.
It is no longer able to detect the ctrl key, so I can't use anymore shortcuts like ^C to stop a running task, because when I press ctrl+C the terminal echoes only the "c" character.
I tried with stty -a and the intr seems to be ok:
speed 9600 baud; 22 rows; 80 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr -ixon -ixoff ixany imaxbel iutf8
-ignbrk brkint -inpck -ignpar -parmrk
oflags: opost onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
Any idea on how to solve it?
I have a usb to serial FTDI adaptor connected to my mac. I am able to use the command:
screen /dev/tty.usbserial-A601L9OC
This opens a serial terminal for the port and everything works fine. But when I try to send characters to the serial port via the command:
root# echo 'a' > /dev/tty.usbserial-A601L9OC
the command hangs and nothing is ever sent. A similar thing happens when I try to connect to it in a c program. The program hangs trying to open the serial port:
int fd = open("/dev/tty.usbserial-A601L9OC", O_RDWR | O_NOCTTY | O_SYNC);
When I run stty on the port it prints:
root# stty -f /dev/tty.usbserial-A601L9OC
speed 9600 baud;
lflags: -icanon -isig -iexten -echo
iflags: -icrnl -ixon -ixany -imaxbel -brkint
oflags: -opost -onlcr -oxtabs
cflags: cs8 -parenb
which looks correct. Does anybody have an ideas as to why these commands hang and never send when connecting to the serial port yet screen works just fine? Any help will be appreciated.
Update: The results of getting info from stty
bash-3.2# stty -a -f /dev/tty.usbserial-A601L9OC
speed 9600 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
-echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
-nokerninfo -extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8
-ignbrk -brkint -inpck -ignpar -parmrk
oflags: -opost -onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
stop = ^S; susp = ^Z; time = 0; werase = ^W;
Use the device /dev/cu.usbserial-A601L9OC instead, and set the speed to 9600 baud also. Here's an example from Magnus' macrumor post:
strcpy(bsdPath, "/dev/cu.usbserial-A601L9OC");
fileDescriptor = open(bsdPath, O_RDWR);
if (-1 == fileDescriptor)
{
return EX_IOERR;
}
struct termios theTermios;
memset(&theTermios, 0, sizeof(struct termios));
cfmakeraw(&theTermios);
cfsetspeed(&theTermios, 9600);
theTermios.c_cflag = CREAD | CLOCAL; // turn on READ and ignore modem control lines
theTermios.c_cflag |= CS8;
theTermios.c_cc[VMIN] = 0;
theTermios.c_cc[VTIME] = 10; // 1 sec timeout
int ret = ioctl(fileDescriptor, TIOCSETA, &theTermios);
ret = read(fileDescriptor, &c, 1);
Use O_NONBLOCK otherwise the open waits for Carrier Detect.