Sponsored Links
Java gets serial support with the new javax.comm package
Sun's JavaSoft division provides support for RS-232 and parallel devices with standard extensions
- Feedback
- Discuss
Developing good software usually means having some clearly defined interfaces. The high-level diagram of the API interface layers are shown in this figure.
In this article we will show you how to use javax.comm to communicate with a serial device based on RS-232. We'll also discuss what the javax.comm API provides and what it doesn't provide. We'll present a small example program that shows you how to communicate to the serial port using this API. At the end of the article we'll briefly detail how this javax.comm API will work with other device drivers, and we'll go over the requirements for performing a native port of this API to a specific OS.
Unlike classical drivers, which come with their own models of communication of asynchronous events, the javax.comm API provides an event-style interface based on the Java event model (java.awt.event package). Let's say we want to know if there is any new data sitting on the input buffer. We can find that out in two ways -- by polling or listening. With polling, the processor checks the buffer periodically to see if there is any new data in the buffer. With listening, the processor waits for an event to occur in the form of new data in the input buffer. As soon as new data arrives in the buffer, it sends a notification or event to the processor.
Among the various serial interfaces available, two of the most popular are the RS-232C and RS-422 standards, which define the electrical signal levels and the meaning of various signal lines. Low-speed serial interfaces typically clock data out as a square wave, with clock coordination provided by start and stop bits.
RS-232 stands for Recommend Standard 232; the C simply refers to the latest revision of the standard. The serial ports on most computers use a subset of the RS-232C standard. The full RS-232C standard specifies a 25-pin "D" connector, of which 22 pins are used. Most of these pins are not needed for normal PC communications, and indeed, most new PCs are equipped with male D-type connectors having only 9 pins. For more on RS-232, see the Resources section.
Note: For an understanding of what other drivers have done in the past, take a look at the Unix termio manual page or OpenBSD Unix, a variation of the BSD Unix driver source. This is available free on the Internet. Please see
the Resources section for more information.
The javax.comm API: What is provided
The javax.comm API provides the following functionality to developers:
- A complete API specification for serial and parallel communication ports. (In this article we consider serial ports only.)
Without a common API in your development efforts, workload will increase because you'll have to provide support to serial
devices.
- Full control of all serial framing parameters (baud stop bits, parity, bits/frame) as well as manual or automatic control
of the flow control lines. Normally, in RS-232, there are two signal lines and the rest are intended for control lines. Depending
on the type of communication (synchronous or asynchronous), the number of control lines selected may vary. This API provides
access to the underlying control signals.
A brief diversion here may help you understand something about parity and start and stop bits. Parity was added to RS-232 because communication lines can be noisy. Let's say we send ASCII 0, which in hex equals 0x30 (or 00110000 in binary), but along the way someone passes by holding a magnet, causing one of the bits to change. As a result, instead of sending 8 bits as intended, an additional bit is added to the first string of bits sent, making the sum total of bits sent even or odd. voilà! You've got parity.
Start and stop bits were added to the serial communication protocol to allow the receivers to synchronize on the characters being sent. One-bit parity does not allow error correction -- only detection. Solutions to this problem come from protocols that are layered on top of the serial APIs. Most serial communication these days uses block protocols with checksums (a mathematical function that can be generated on the receiver and compared to the transmitted checksum) that allow errors to be detected on larger groups of bits. When you are communicating with your ISP over PPP, packets may be 128 bytes per packet with a checksum. If they match, you are 99.999% sure the data is okay.
There are cases wherein this scheme doesn't work. For example, when sending critical commands to devices that are very far out in the solar system, forward correcting protocols can be used. Forward correcting protocols are needed because there may be no time for a retransmission, and space has a lot of electromagnetic noise.
Okay, back to the list of functionalities provided by the javax.comm API!
- The basic I/O via a subclass of Java IO streams. For input and output, the javax.comm API uses streams; the concept of streams
should be familiar to all Java programmers. It is important to reuse Java concepts when building new functionality or the
APIs will become unwieldy.
- Streams that can be extended to provide client flow control and threshold controls. For example, you may want an alert when
there are 10 characters in the buffer or when there are only 10 locations left for characters. Flow control is important when
the two devices connected via an interface cannot keep up with each other. Without flow control, you can have overruns or underruns. In the overrun condition, you received data before it was processed so it was lost; in the underrun, you were ready for
data but it was not available. Usually these conditions occur at the USART (Universal Synchronous Asynchronous Receiver Transmitter),
which is hardware that converts bytes to a serial wave form with timing to match the baud rate.
The javax.comm API uses the Java event model to provide notification of various signal line changes as well as buffer status. State changes refer to well-defined signals specified in the RS-232 standard. For example, carrier detect is used by a modem to signal that it has made a connection with another modem, or it has detected a carrier tone. Making the connection or detecting a carrier tone is an event. Event detection and notification of changes is implemented in this API.
What is not provided
The javax.comm API does not provide:
- Line discipline type processing, dialer management, or modem management. Line discipline refers to additional processing of input or output characters. For example, one common post-processing option is the conversion
of CR to CR LF. These terms have their origins in the early days of teletypes. CR (carriage return) means to simple-return
the carriage to the left margin; in the Arabic world, this would be the right margin. LF (line feed) advances the printing
area up by one. When bitmap screens and laser printers came along, these terms became less important.
Dialer management and modem management are additional applications that can be written using the javax.comm API. Dialer management typically provides an interface to the modem management's AT command interface. Almost all modems have an AT command interface. This interface is documented in modem manuals.
- Feedback
Resources- The javax.comm API reference at JavaSoft Developer Connection
http://java.sun.com/products/javacomm/ - Excellent discussion on flow control http://www.embedded.com/98/toc9801.htm
- You can access the RS-232 Serial Communications Tutorial published in PC Communications at http://www.ridgewater.mnscu.edu/classes/dc/io/
- The book Understanding Data Communications, by Gilbert Held and George E. Friend, provides details on data communications http://www.clbooks.com/sqlnut/SP/search/gtsumt?source=javaworld&isbn=0672309343
- Serial line analyzers http://www.bb-elec.com/catalog/software/serialte.html
- Information and Source of OpenBSD Unix. This may be useful to look at how serial, parallel, and other device drivers are written. http://www.OpenBSD.org/
- The smart card series in JavaWorld magazine began with the "Java smart card primer" http://www.javaworld.com/javaworld/jw-12-1997/jw-12-javadev.html
- The January issue of JavaWorld ran the second article in the smart card series"Smart cards and the OpenCard Framework" http://www.javaworld.com/javaworld/jw-01-1998/jw-01-javadev.html
- In JavaWorld's February issue, you can read "Get a jumpstart on the Java Card" http://www.javaworld.com/javaworld/jw-02-1998/jw-02-javadev.html
- Also in the February issue is "Giving currency to the Java Card API" http://www.javaworld.com/javaworld/jw-02-1998/jw-02-javacard.html
- For more on Java Card 2.0, see "Understanding Java Card 2.0" in the March issue of JavaWorld http://www.javaworld.com/javaworld/jw-03-1998/jw-03-javadev.html
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2008 Network World, Inc. All rights reserved.
communicating with com portBy Ghost4u on October 2, 2009, 4:53 amhi all i am facing problem to read input from com port i am using javax.com package on a windows machine the program is: import java.io.*; import javax.comm.*; import...
Reply | Read entire comment
readind data from com portBy Ghost4u on October 2, 2009, 4:35 amhi all i am facing problem to read input from com port i am using javax.com package on a windows machine the program is: import java.io.*; import javax.comm.*; import...
Reply | Read entire comment
i have to send data or some characters from pc to pc through serial portBy Anonymous on December 20, 2008, 7:41 ami have to send data or some characters from pc to pc through serial port
Reply | Read entire comment
View all comments