Serial Lines Explained


 
Thread Tools Search this Thread
Top Forums UNIX for Dummies Questions & Answers Serial Lines Explained
# 1  
Old 08-04-2014
Quote:
Originally Posted by Corona688
Serial ports in UNIX are a complicated topic. Sure, if you want.
Thanks a lot first of all Corona688 for being extremely patient with all my queries and answer them as simply as possible. Now I am thinking of starting a new thread about Serial ports, but before that I am asking for some reading material on serial ports and terminal devices. So that when I come back to ask my doubts here they don't need to be quite so noobish and obvious questions.

Any links to some study materials for beginners for this topic would really help. Also if anyone can suggest a good book which contains material on this topic will also be nice.

I am asking here because googling on the topic didn't give me any concrete starting point.

Serial ports maybe complex but I am already interested in how they work Smilie. First time coming across a design where a terminal communicates to the kernel through a COM port.

Moderator's Comments:
Mod Comment edit by bakunin: You should indeed start a new thread with this. We try to confine each question/theme to a separate thread so that the knowledge base we are building is easier and better to search for information. I will cut this part out and open a new thread with it.


Moderator's Comments:
Mod Comment edit by bakunin: The rest of the post snipped here because it belongs to the other thread.

Last edited by bakunin; 08-04-2014 at 12:17 PM..
# 2  
Old 08-04-2014
Let us start with some hardware first: you want to transmit signals (zeroes and ones) in both directions between two nodes. What do you need? Basically, you need 3 wires: one ground, to even out all potentials, one "transmit" line and one "receive" line. The "transmit" line is connected to the "receive" line on the other side and vice versa:

Code:
GND   -----  GND
XMIT  -----  RECV
RECV  -----  XMIT

This is the most basic pinout of a serial line. In a RS232 connection usually D-Sub 9 or D-Sub 25 connectors are used where only pin 2, 3 and 7 are connected. Find out more about RS-232 (or, as it is also called, "V.24") here.

What could affect the transmission of data in such lines? First, of course, the speed of light. Although it is pretty high it is not unlimited and the longer the line the more the time it takes the signal to travel influences the transmission. The second problem is worse: the serial cable is three thin wires running from sender to receiver. As the cables are not insulated at all they are prone to be influenced by electric fields from outside. In basic RS-232 the voltage is measured to determine if a pin is "high" ("1") or "low" ("0"). Fields from the outside can (and do) influence this voltage therefore the longer the line gets the more unreliable as a means of transport it is. There is an upper length limit for RS-232 connections therefore.

There is another technique to overcome this limitation: the "current loop" (also called "20mA interface"). It works like RS-232, but instead of measuring the voltage of one pin you measure the difference in potential between the two pins. Because the two lines go in parallel and what affects one will most probably affect the other equally it is more robust to outside electric influence.

So much for the technique. What can one do with it? Serial lines are used in all sorts of communications: modems are basically a converter from a serial line to telephone line (which works similar to a serial line itself) and back. Another usage was the transmission of data between computers before the advent of switched packet networks. The pinout above is also called "Nullmodem", because you can connect two computers via it pretending to have a modem line in between where the modem is simply missing.

Another prominent usage was to connect terminals (and other sorts of hardware) to computers. A "terminal" is: a keyboard and a screen, connected via a serial line to a computer. One would plug the serial cable into a serial connector and whatever gets typed is sent via the cable to the computer, which processes it and sends something back which goes to the screen.

The most fundamental tenet of a UNIX system is "everything is a file". YOu probably have already heard that. How does it apply here? Each terminal (its line connector, respectively) is represented by a "device file" (a file representing a piece of hardware). Write into this file and - in case of our terminal - something would appear on the screen of it. Read from this file and you get what is typed into the keyboard of it.

Basically, this is it. The kernel will recognize a newly connected terminal and create a device file for it ("/dev/ttyXX", where "XX" is some number). There is a specialized process in a UNIX system, called "getty", which scans all the terminals and, if necessary, initiates a login process. This process is what you see when you connect to a system and are presented the "login:" dialog. Once you authenticate with a user name and password and the login process ha verified you are allowed to log on your user session is started on the terminal. You enter commands, etc. (see above - the shell reads from / writes to the tty-device file) until you end your session, i.e. by issuing "logout".

Now the "getty" process kicks in again, finds an otherwise empty terminal, initiates a "login"-process there, which will wait for a username and password, and so on. If you disconnect the terminal (pull out the serial connector) the device file representing it is deleted and the "login"-process terminated for this terminal.

I hope this helps.

bakunin

Last edited by bakunin; 08-04-2014 at 01:29 PM..
This User Gave Thanks to bakunin For This Post:
# 3  
Old 08-04-2014
IMHO, the best book ever written on the subject is: C Programmer's Guide to Serial Communications
This User Gave Thanks to Perderabo For This Post:
# 4  
Old 08-06-2014
Since most serial communications is via a UART this might help with the data transfer part:
Universal asynchronous receiver/transmitter - Wikipedia, the free encyclopedia

The UART voltage swings are between 0 and 5 volts. This signal is inverted and expanded to higher voltages by line drivers for transmission and inverted again and reduced to 0/5 swings by line receivers on the receiving end.

The transmitted signal starts degrading immediately and at higher transmission speeds it can be expected to be useless beyond 50 feet due to RC effects. (with a scope you would see rounding of what started as sharp shapes of voltage transitions)
# 5  
Old 08-06-2014
That's only half the story though. Serial ports in UNIX aren't just telecommunications, they're session control, job control, raw interaction.

I believe this all stems from the way terminals used to be used... You would login through a terminal, and that terminal would belong to you. Any processes you created would know what your terminal was(it would be your "controlling termina"). The kernel would know which processes were allowed to control it(foreground processes) or not allowed (background processes). Hitting ctrl-C would send SIGINT to processes belonging to your terminal. When you logged out, the group of processes belonging to that terminal would be killed.

Logging in through a remote teletype was almost the same, since it was an extension of the serial port. Modems had a few more signals, UNIX would know when a modem hung up for instance.

Having a "controlling terminal" does several things. For one thing, it means that all programs you run will be able to find out what your terminal is(they inherit their controlling terminal from you), and get direct access to it if they want it (by opening /dev/tty). This means that, even when you bury ssh in a 9-deep pipe chain, it can still go directly to the source and ask for your password. Or if /dev/tty can't be opened, they know there's no human there to ask for a password and just give up. If you ever see an error like "No tty present and no askpass program specified", that's what it means.

Last edited by Corona688; 08-06-2014 at 01:08 PM..
# 6  
Old 01-04-2015
Okay from what I have read in this thread I can understand that in the older days you would have a monitor and a keyboard with a serial port connecting to the central CPU. You would communicate with the CPU using signals sent via the serial port. I know this is an over simplification but is it correct ?

Can someone explain how serial ports can be used for session control in a little more detail ?

What baffles me is that is why still use serial ports ? Why not remove them ? On a normal desktop or laptop serial ports are not used the way they were used back in the olden days, so keep them ?

For example as Corona688 mentioned in a earlier thread
stty still gives the baud rate. This is not required so why still keep it.

Why adopt an old standard forcefully when it is not required is my point
# 7  
Old 01-04-2015
Quote:
Originally Posted by sreyan32
Okay from what I have read in this thread I can understand that in the older days you would have a monitor and a keyboard with a serial port connecting to the central CPU. You would communicate with the CPU using signals sent via the serial port. I know this is an over simplification but is it correct ?
Yes, if the "CPU" you refer to is meant in a broader sense, like on the IBM-mainframes of the /360 architecture and its successors (/370, /390 and z/OS). In the narrower sense, where "CPU" refers to the processor itself, you don't communicate with it, but with the OS, which in turn manages every resource, including the processor (but also RAM, disks, ...).

Can someone explain how serial ports can be used for session control in a little more detail ?

Quote:
Originally Posted by sreyan32
What baffles me is that is why still use serial ports ? Why not remove them ? On a normal desktop or laptop serial ports are not used the way they were used back in the olden days, so keep them ?
Because it is a powerful concept. When we talk about "serial lines" we basically say so because of the historic origins where these connections were indeed realised in physical RS232-connections. But in fact we talk about a "bidirectional connection" which was once realised using RS232 connections but also network connections (virtual channels using TCP as transport medium, like in telnet, rlogin and so on, up to modern SSL-socket connections), USB, IRDA, BlueTooth, ...

Counterquestion: what would you like to use instead? If it some sort of bidirectional connection again, you could as well stick with the old TTY-mechanism because you will not be able to enhance that very much. If you want some connection capable of transmitting graphics primitives: this is already there, it is called the X protocol (port 7000) and used to remotely display X-clients over the network on remote X-servers.

One big drawback of this way of connecting terminals with the main system is that management of the terminals is centralised in interrupt-service-routines in the OS. You move the cursor on a remote terminal and basically the main processor receives an interrupt, handles the cursor movement and only then resumes its main work. Connect a real big number of terminals to a UNIX system (say, several thousands) and you can bring it to its knees without the connected users even doing anything worthwile.

If you now envision a way of connecting terminals with some local intelligence so that the main system isn't bothered with load: congrats, this already exists: its the Frontend-Processors and Cluster-Controllers of the SNA network of an IBM mainframe. This is why a z/OS host can serve several thousand user sessions in parallel without problems: the de-centralised 37x5-units and the 3174 cluster controllers make short batch-like jobs from the user input, which the system works off and immediately "forgets" about the session until the next "batch-job" comes along. On the downside, this makes interactive use a bit cumbersome. To scroll down a page in a text you would enter the command for "one page down", then press the "send"-key, now the cluster controller picks your session and the command up, creates the mentioned batch job, the main units sends the result (the next page), the cluster controller creates you new screen content and now you can resume your session and enter whatever on the screen until you hit "send" again, ...

So, coming back to midrange systems: without using decentralised session management like on the mainframe systems, which solves several problems but creates others, we have a system that is as well defined and feasible as it gets. Comparing it to an OS where this well-defined system is not in place (like Windows) we see there is no defined "terminal" device but a directly managed "screen", "keyboard", etc.. You won't notice the difference as long as you have a single PC running the OS, but once you try to work locally and remotely at the same time on the same system simultanuously you will notice that in UNIX/Linux you just create another TTY (maybe over a network session using telnet/rlogin/ssh/whatever, while in Windows?? A remote session in UNIX means some bytes over the network, a Windows remote desktop is simply not possible without a high-speed connection. I can easily connect from home over a secured SSL-connection to a UNIX-system at the office even if the internet connection is bad (like in using my GSM-mobile as access point). Given the bandwidth of such a connection a remote desktop is not even thinkable.

Quote:
Originally Posted by sreyan32
For example as Corona688 mentioned in a earlier thread
stty still gives the baud rate. This is not required so why still keep it.
Counterquestion: why not? The way the TTYs in UNIX work everything, from real serial lines to virtual network connections of all sorts is covered. Why remove the support for real serial lines? What would be the gain when stty wouldn't display the Baud rate any more?

Quote:
Originally Posted by sreyan32
Why adopt an old standard forcefully when it is not required is my point
What do you mean by "forcefully"? Nobody forces you to use it. Write your own driver for your own sort of terminal (or whatever you want to reaplace the commandline interface with) and if it is of any use perhaps people will start to use it. In the long run feasibility rules and whatever is useful is used.

I hope this helps.

bakunin
 
Login or Register to Ask a Question

Previous Thread | Next Thread

1 More Discussions You Might Find Interesting

1. Ubuntu

Ubuntu 9.04 Serial application to telnet to serial device

Hello! I am working on an application which reads environmental instruments which have serial ports. The application requires a serial port to be present to talk to the device (i.e. /dev/ttyS0 ). In some instances the environmental devices will be 100's of yards away from the computer, so a... (5 Replies)
Discussion started by: mvona
5 Replies
Login or Register to Ask a Question