Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I have a 1990 model cnc controller that imports/exports programs via a RS232 interface (9600,7,E,1). When I connect using a usb-serial converter, hyperterm and winxp I am able to download the text of a program from the cnc controller to my laptop with no problems.
When I connect to my linux box with the same usb-serial converter i get jibberish (foreign characters) in both minicom and from a small pySerial program that i snipped from the web.
Can anyone suggest what character translations hyperterm is automatically doing that minicom is not?
I suspect that I can mask a single bit of each character and clean it all. I also suspect that there is a setting for minicom and pySerial that will do the trick.
I think my machine is outputting binary data, perhaps some terminal protocol. Hyperterminal decodes and displays what I want to see from linux (minicom/python) (see the attached screen grab of hyperterminal). I have also posted a screen grab of the output from minicom when receiving the same RS232 stream. Addtionally, I have posted the output from my readserial.py python capture script program after piping it through xxd. Does anyone recognize this encoding scheme? If so, how do I setup something on my linux machine to perform the same translation that hyperterminal is doing automatically?
When I first start hyperterm the status line that you pointed out says 'Auto detect' after reading the data it changes to '9600 8-N-1'.
I don't find the status line of hyperterm very trustworthy. I can disconnect, change port settings, and reconnect and I still get good data from hyperterm.
Attached below are screen grabs of hyperterm showing both 9600-7N1 and 9600-7E1 and the same clean text output. I have also attached a screen grab of the port setup from device manager. The device manager port settings have been 9600-7E1 all along. I have a configuration parameter on the machine that I am trying to interface to that indicates that it is output 9600-7E1 data.
By the way, I have tried all of these settings (9600-8-N-1, 9600-7-N-1, 9600-7-E-1) in minicom and readserial.py.
The original problem was to download a program to this computer via serial.
The two steps I'd do here if I could not get a specification on how to send the data would be:
1.) Write a program to run on Linux which would listen to the serial port and print out exactly what Hyperterm is sending when it sends a file the correct way in which it works. This way you'll be able to see exactly what Hyperterm is sending.
2.) Write a program which takes your program file and sends it over the serial port to your target in the same manner which Hyperterm is sending it to you.
Also you can configure the port between 7E1 and 8N1 to see which variation makes the data look correctly when you read it as Hyperterm sends it to your Linux program. 8N1 is the most common, but I have one case of 8-bit, Odd parity in my system.
Use open(2) and read(2) to accomplish this. Here also are some examples for configuring port rates and parity via a Linux C program.
Example to configure the rate, my set port rate function uses 115,200, 230,400, or defaults to 38,400, but you can use whichever rates are appropriate for you. Note also that my log mechanism is not common, is a macro, and uses that debug argument, nothing you need to worry about. I also have many includes because it's a utilities file, so I've checked a bit and shown the includes mainly required for the library calls from termios(3).
rtmistler, thanks for the time you spent replying. However, I am not sending from hyperterm. I am receiving.
I have made progress in determining that the problem seems to be with the parity bit on the linux side. In the attached screen grab you can see a hex dump of the stream I am trying to read. The back window is bray's terminal running on windows. The front window is the output of the following pyserial program running on linux.
import os, serial, time, sys
s = serial.Serial('/dev/ttyUSB0', baudrate=9600, bytesize=7, parity=serial.PARITY_EVEN, stopbits=1, timeout=None, xonxoff=0, rtscts=0)
x = s.read(1)
# print x.encode('hex')
NOTE: If I switch bray's terminal from hex mode to ascii mode it displays the correct output.
I have highlighted the differences between the output in the attached screen grab. Notice that all of the differences are for bytes which have odd parity in the lower seven bits. Next, I will mask off the MSB of each byte to see if it displays correctly. I suspect that this should not be necessary. Does anyone have any suggestions?
You're trying to use this through Linux versus Windows right?
There are other port settings besides character size, parity, and stop bits.
stty shows you that and allows you to set the port up for things like RAW mode; which is really a combination of attribute settings in a certain way. Many times when writing a serial port application in Linux I have to configure the port to be raw mode. That's why I'm referring to the termios(3) utilities: tcgetattr(), tcsetattr(), and so forth.
There either are or are not equivalents which you can use via python; however the termios utilities are based on Linux and therefore based on C, so the best recommendation I could make would be to experiment with a C program to better view and control the entire termios structure. You get that structure by tcgetattr() and then you can examine all settings, many of which will likely be meaningless, but there is one which will probably resolve this so that you can talk to this system via Linux versus Windows utilities.
You observe that the sender appears to be using ODD parity. The next thing to try, then, is to set ODD parity at the receiver, rather than masking the problem by masking the high bit.
If you need to use the serial port to do file transfers, may I suggest using one of the many serial file transfer protocols and/or applications that already exist for such purposes? Kermit or Z-modem would be good starting points.
To answer my original question, hyperterminal is apparently stripping off the high bit. Linux is not. I switched from python to perl because I know perl, was just cutting and pasting the python stuff. I still haven't gone back to see how to set 'istrip' using minicom. But the following perl script solves my problem. Here is my perl reader: