Hyperterm works, minicom doesn't
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 am not aware of any translation that hyperterm does but minicom does not. Have you verified that you have the same port settings between hyperterm and minicom?
Another alternative is cutecom which has the option to display raw data in addition to regular ASCII characters. |
cutecom is a no-go. running on a headless server.
|
How do you access the server?
|
ssh
|
Whatever the serial resource as it shows up on Linux, /dev/ttySx or /dev/ttyUSBx. From a shell prompt you can view the settings and change them:
Code:
stty -F/dev/ttyUSB0 115200 You can also cat the output of that port if it happens to be always talking. For instance I work with embedded sensor boards which arrive via serial USB, so I would do Code:
cat /dev/ttyUSB0 |
Hyperterminal, minicom, more information...
2 Attachment(s)
Ok,
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? Code:
~$ sudo python readserial.py > readserial.py.out Code:
~$ cat readserial.py |
Quote:
|
I wish...
3 Attachment(s)
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. |
Your right... The difference between 7e1 and 8n1 is negligible and would appear like dropped bits like the output of your python script. The gibberish output from minicom is puzzling.
|
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). Code:
#include <termios.h> Code:
int set_port_parity(char *port, tcflag_t parity, int debug) |
...making some progress
1 Attachment(s)
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. Code:
#!/usr/bin/python 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. --- rod. |
Solved !
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:
Code:
#!/usr/bin/perl |
All times are GMT -5. The time now is 12:31 AM. |