By using SerialPort the developer is provided with maximum flexibility since the Comm API or the SerialPort API can be used.The SerialPort API was shipping commercially for about 18 months before Sun introduced javax.comm.SerialPort.
As diagrammed below, the Serialio.com implementation of javax.comm.SerialPort was built completely using the SerialPort API and is based on the Comm API 2.0 (the first release in spite of the version number). Java Serial Port Library Code Your SolutionIf you use CommConnection, you may have to recode your solution to run on a non-MIDP environment. If you code your solution with the SerialPort API, use the same code on both MIDP and non-MIDP environments. Developers using the SerialPort API can use the same powerful API for all their target devices, from Super Computer class to MIDP class devices. The javax.comm API design is insufficient for such flexibility; therefore the CommConnection interface was developed to replace javax.comm on MIDP. The CommConnection API is even more restrictive than the javax.comm.SerialPort API, and requires the developer to learn another API only to be limited by its design. This means that threads that transmit data using javax.comm.SerialPort, can potentially lockup. This can occur for example, when hardware flow control is selected, but no hardware is present, or the client has flow control disabled indefinitely. Many of the issues reported were apparently ignored by Sun, as those issues still remain with the Comm API in the initial release (long after the issues were reported). There should be some way to determine if some setis, and notifyOn API methods are supported. The SerialPort product does this with the isSupported methods. Since the Comm API does not provide this feature, it should at least define some of the methods to throw unsupportedCommOperationException. ![]() Likewise, notifyOnCD, and notifyOnRingIndicator make no sense on the Mac. When using our javax.comm.SerialPort implementation on a platform that does not support one of these features (e.g. DTR on UnixWareIA32) a message similar to the one shown below will appear on the console: The correct thing to do is to throw an UnsupportedCommOperationException; however, Suns API does not define this. For source code compatibility with Suns API, we can not do it the correct way. You should contact Sun and encourage them to fix their API. We suggested they do this in early 1998). It also seems odd that methods like setDTR, setRTS, and sendBreak are not declared to throw an IOExcepion. Java Serial Port Library Serial Hardware LevelFrom the serial hardware level, these signals are write-only, so these methods can be misleading. Additionally, these methods make no sense on some platforms. For many applications this is not a problem, however, for some high-performance applications, the overhead of event creationpropagation can be limiting. Note also that some platforms may not provide a mechanism to generate interrupts for all of the events defined in the Comm API. This means that a thread must be dedicated to polling at the Java level to generate the required events. Java Serial Port Library Driver Must ReconfigureIn the Comm API when the methods setSerialPortParams and setFlowControlMode are called, the driver must reconfigure an open port. Performing port configuration changes without resetting the port can be risky since some OSs do not support the concept, or can have subtle bugs associated with it. This is one of the reasons the Solutions Consulting SerialPort API uses the SerialConfig object). In fact, our implementation of the Comm API is done with SerialPort reflecting SerialPorts robust design.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |