1
\$\begingroup\$

I was wondering if there was any Descriptor part in the data packets during RS 232 based Serial Communication. If not (apparently) then how does the computer decide regarding the type of device connected.?

\$\endgroup\$
  • \$\begingroup\$ Can you be more specific? What kind of serial are you talking about? RS232? USB? SATA? What are the devices you are thinking of? \$\endgroup\$ – Rocketmagnet Mar 4 '13 at 15:19
  • \$\begingroup\$ You must absolute provide more detail of your context. Is this about the host side of USB communication? Or about some RS232 line? \$\endgroup\$ – Wouter van Ooijen Mar 4 '13 at 15:20
  • \$\begingroup\$ Sorry..it is about RS 232 based serial communication. \$\endgroup\$ – Umer Huzaifa Mar 4 '13 at 15:21
  • \$\begingroup\$ Basic asynch serial is just a channel for transporting bytes (and a few handshake conventions). Nothing more. Of course you can build anything you want on top of that. The computer does not decide at all, it just waits for an application to open the serial channel and gulp up the bytes. So basically YOU decide, by starting an application and configuring it for a certain port (or the application will poll all ports - bad habit). \$\endgroup\$ – Wouter van Ooijen Mar 4 '13 at 15:52
4
\$\begingroup\$

There are no packets in traditional RS232 communication, let alone device descriptors. Neither the computer nor the device inherently know anything about each other.

Usually, the device has fixed characteristics; sometimes some of these characteristics can be modified by setting switches, moving links, choosing an appropriate cable, or judicious use of a soldering iron.

These characteristics have to be accurately matched at the computer end, when the device is installed, typically by the user reading the device manual, and modifying options, perhaps in a .ini file, or on the command line of the communications program.

Failure to communicate accurately results in an iterative process of trying different options, scratching one's head, and (often) rebooting the peripheral to clear out garbage (like thirty thousand characters misinterpreted as form feeds aka "new page" in its print buffer)

Some of the variable characteristics are:

1) baud rate. Failure to agree on this causes complete gibberish

2) Control flow. This can be :

  • none - transmit regardless of whether the other end is receiving or processing previous data
  • Software : listen for "stop" and "start" characters when transmitting. Note that failure to agree on baud rate renders this unsuccessful.
  • Hardware : Watch CTS and/or DTR signal lines for permission to transmit; assert RTS and/or DSR to signify readiness to receive. Note that the cable you grabbed only wires up CTS and RTS, so your equipment will be waiting for DTR for a very long time. Note also the Diablo daisywheel printer which wires one of these signals to Pin 11 unlike everything else in existence...

3) Variations in what a simple byte looks like : 7 or 8 bits, parity or not, odd or even parity (if present), 1, 1.5 or 2 stop bits afterwards.

4) Standard 25-pin D-type connectors with an apparently arbitrary mix of male and female connectors at each end of the cable, and an assortment of non-standard connectors like 9-pin D-types...

All this variability used to support an entire industry of RS232 testers and adapters...

And I haven't even mentioned the liberties sometimes taken with voltage levels.

Sometimes it feels like a miracle that anything RS232 ever worked at all...

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.