Note: JavaComm itself obtains the default list of available serial port identifiers from its platform-specific driver. The list is not really configurable via JavaComm. The method CommPortIdentifier.addPortName() is misleading, since driver classes are platform specific and their implementations are not part of the public API. Depending on the driver, the list of ports might be configurable / expendable in the driver. So if a particular port is not found in JavaComm, sometimes some fiddling with the driver can help. |
To do:
|
os.print()
or is.readLine()
in the previous example) do not return, and the application comes to a halt. More precisely, the thread from which the read or write is done gets blocked. If that thread is the main application thread, the application freezes until the blocking condition is resolved (data becomes available for reading or device accepts data again).InputStream
, OutputStream
), but with a twist, as shown later.Activity | Architecture |
---|---|
reading | use event notification and/or separate thread |
writing | always use separate thread, optionally use event notification |
SerialPort
to be kept informed about important events happening on that port. The two most interesting event types for reading and writing data arejavax.comm.SerialPortEvent.DATA_AVAILABLE
andjavax.comm.SerialPortEvent.OUTPUT_BUFFER_EMPTY
.SerialPort
can be registered. This forces the programmer to write 'monster' listeners, discriminating according to the event type.OUTPUT_BUFFER_EMPTY
is an optional event type. Well hidden in the documentation Sun states that not all JavaComm implementations support generating events of this type.To do: |
byte[]
should do. Further, there needs to be a way for the main application to determine if it can write to the data buffer, or if the data buffer is currently full. In case the data buffer is full it could indicate that the serial port is not ready, and output data has queued up. The main application will have to poll the availability of new space in the shared data buffer. However, between the polling the main application can do other things, for example updating a GUI, providing a command prompt with the ability to abort the sending, etc.PipedInputStream/PipedOutputStream
pair seems like a good idea for this kind of communication. But Sun wouldn't be Sun if the a piped stream would actually be useful. PipedInputStream
blocks if the corresponding PipedOutputStream
is not cleared fast enough. So the application thread would block. Exactly what one wants to avoid by using the separate thread. A java.nio.Pipe
suffers from the same problem. Its blocking behavior is platform dependent. And adapting the classic I/O used by JavaComm to NIO is anyhow not a nice task.OUTPUT_BUFFER_EMPTY
event. The event is not supported by all JavaComm implementations, therefore the code might never be called. However, in case the event is available it is one building block for ensuring best data throughput, because the serial interface is not left idle for too long.outputBufferEmpty()
, which could be implemented as it follows.java.comm
package, but in the gnu.io
package. However, the two currently available RxTx versions are packaged differently:gnu.io
package was added.gnu.io
package replacement for java.comm
. This version is supposed to have its roots in RxTx 1.5, where gnu.io
support started.java.comm
implementations. Only the part implemented in Java is used, while the Unix native libraries are just ignored.gnu.io
replacement package, then java.comm
in the application source code with references to gnu.io
. If the original JavaComm application was properly written there is nothing more to do.contrib/ChangePackage.sh
to perform the global replacement on a source tree under Unix. On other platforms such a global replacement is easy to do with IDEs supporting a decent set of refactoring features./dev
and do ls -a | grep ttyS
I get:/dev/ttyS0
? How would I go about figuring this out if this is a upnp device?setserial -g
to try identifying my upnp USB serial port but nothing is returned. Also tried installing and using minicom which defaults to /dev/ttyS8
but not sure if that is because it detected something or that is the default port it tries to read on.dmesg | grep tty
I get this:/dev/ttyUSB0
or would I need to connect to on of the /dev/ttyS*
ports and identify the port? If that is the case I have 32 of those so would be nice to find out which one to use./dev/ttyUSB0
.