serial port problem

[WWWW]

Hello,

I need to hook up a couple devices that communicate via serial port. For this I use real serial port and usb to serial port adapter for which module is loaded properly.

The module loads right but I am unable to communicate with the devices.

These devices did work properly with windows and testings done with m$$$ hyperterminal also confirmed success.

When trying with linux the serial ports appear to look fine with stty even able to change settings succesfully.

I've used stty with both on-board serial port and a usb adapter.

[Roman_Gruber]

you may change your topic title to something else.

it seems you want to know, suggestion for title: how do i use minicom in linux??

second: you may check what lsusb says.
than you may install the required drivers and than you may

choose a terminal with serial capabilities.

please note

kernel + userspace (you may call it drivers, but i wont recommend it), + settings and it may works

what i remember on those rs-232 buggers only a few really works other claim to work. just try another dongle

and you need to set the right protocol on both ends.


and i think the mighty monster called wireshark should be able to watch your serial communications. as wireshark can do so many things(wild guess)

you may check waht you have with lsusb and than google for the related configs... rs-232 was kinda used a lot for microcontrollers in the past and therefore how to use a terminal should be covered when you found what chip you use. e.g. fddi XXXX, ... ...


personal expierence with infineon cr167-lm regarding your baud. higher baud gives more stress to your micronctroller. i would go as low as possible when you have a not important task to handle. 9600 baud, 8 data bits, no parity, was kinda standard in the old days. higher baud rates can cause troubles and break things. i got the best results with 9600 baud.

if you do not have any requiremend for speed, go for 2400 baud, that was the lowest which usually worked. windows 2000 on pentium 3 liked the most 9600 baud. yes it is not technical and yes it is just a statement without much proof but that is / was my expierence.

you can check for anything which monitors your serial communications, which should be able if you configure your hardware properly.

yuo may check out putty

* net-misc/putty
Available versions: 0.63_p20141002 **9999 {doc +gtk ipv6 kerberos}
Homepage: http://www.chiark.greenend.org.uk/~sgtatham/putty/
Description: A Free Telnet/SSH Client


it used to handle rs-232c too afaik, on any os

[szatox]

You can also spawn stty and have a terminal attached to that serial port. Just go to /etc/inittab and uncomment this line:
#s0:12345:respawn:/sbin/agetty -L 115200 ttyS0 vt100
or perhaps this, if you have multiple serial ports.
#s1:12345:respawn:/sbin/agetty -L 115200 ttyS1 vt100

This would let you control your computer with a serial console. Roughly the opposite to what minicom is for

[NeddySeagoon]

WWWW,

A few serial comms basics

There are lots of wires in a serial port. To start with you only need three. Thats Tx Data Rx Data and ground. Tx= Transmit Rx= Receive.
From memory, thats pins 2,3 and 7 in a 9 pin real serial port.

As a test, you can connect pins 2 and 3 together and perform a loopback test. Keep reading - handshake matters.

With three wires, you have a choice of no handshaking or software handshaking.
No handshaking means you close your eyes and send data anyway. If the receiving end isn't ready, the data is lost.
On a PC, this works up to about 9600 baud with an unbuffered UART. I'll avoid going into why.

You won't find unbuffered UARTs in PCs after the XT but you can turn the buffer off if you are not careful.
To go faster than 9600 baud requires a buffer and handshaking.

Software handshaking reserves two characters, X-On and X-Off for the handshake. This means that you cannot use softmare handshaking if you have a binary data stream as whatever is defined as X-On and X-Off cannot appear in the data. The idea is that you can use any data rate the two ends have in common and when the buffer is part full the receiver sends X-Off, which stops the transmitter and avoids dropped caracters.
When the receiver has processed some or all of the buffer, it sends X-On and the transmitter sends data again.

Thats as good as it gets with only three wires on the interface.

If you add more wires you can do hardware handshaking. The idea is the same as software handshaking but because there are no reserved symbols you can trasmit binary data.
For loopback testing, you can't type fast enough to get dropped chracters, so no handshake or software handshake will always work. With hardware handshaking, you must have the handshake pins wired so that data transmission is permitted. By default, hardware handshaking defaults to sending is not permitted.

Ensure that hardware handshaking is off and play with loopback. In this state, every character that is tranmitted is received.
If you have local echo on, each typed character will appear twice. The local echo and the looped back transmit/receive.

Until loopback works, nothing else matters.

Baud rates, start bits, data bits stop bits and parity.
Due to the brain dead design of the PC you cannot set these parameters differently for transmit and receive. That's glossing over a few points but it does mean you don't care about these settings for loopback testing as they are always the same for transmit and receive.

The baud rate is the data rate on the serial link. There is no useful default.
Start bits are transmitted on the link before your data and are used to synchronise both ends of the link.
Your data bits follow,
Then there is a paritfy bit (or not)
At the end of the byte are the stop bits.
It doesn't matter much to data transmission reliability what values you use as long as both ends are set to the same thing.

It the PC world, 8 data bits, No parity and 1 stop bit is common. That's written 8n1, at any baud rate you like, with some form of handshake over 9600 baud.

Using you favourite terminal emulator, make loopback work and lets take it from there.

One word of warning, RS232 has been around a long time, the various versions will not interoperate without some form of voltage translation.
Indeed the older higher voltage standards will cause the newer lower voltage stanads to self destruct.
Real PC serial ports use +/-12v
USB to serial usually uses +/-5v.
Embedded devices, like ARM SoC often use +/-3.3v
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[WWWW]

Thanks for the reply.

The explanation about the flow control was really helpful.

My problem here is two pronged:

1- serial not working
2- minicom to troubleshoot


More mysteries. I performed the loopback test by doing the following:

Bridge pins 2 and 3

Terminal A

[NeddySeagoon]

WWWW,

Did you test as root or an unprivilidged user?
It matters as unprivilidged users dont get serial port access.