Contents
Software Challenge: users data over any connection
- To present the data in a uniform manner to the computing device, that is simple to use, easy to configure,is secure and reliable.
- To present the data as if it has a connection that is as robust as a point to point cable, no matter what the underlying physical connection – whether the connection is transient, local or remote, shared or dedicated, wired or wireless.
- Connection Agnostic Interface, software must work the same no matter what the underlying connection
- So hardware vendors must deliver on these market demands
Device Driver Development
- Serial device manufacturers like Brainboxes base their Device Drivers upon code and recommendations in the Microsoft Device Driver Kit-the DDK.
- How complete an implementation a device Driver is and how compatibly it works varies from one manufacturer to another.
- With over 20 years experience of designing, manufacturing and supplying serial port products Brainboxes have developed an extensive set of test cases which we continuously run on device driver code as it being written, so ensuring we have the highest quality code possible.
- Brainboxes always submit our driver code to Microsoft WHQL – the Windows Hardware Quality Labs and obtain the coveted Windows Logo Approval. Brainboxes have done so since the earliest days of the HCL – Hardware Compatibly List-instigated with Windows NT in the late 1990s.
Layers Between Application and Physical Serial Port
Device Driver Compatibility
- Depending on the physical serial port interface and the actual serial hardware the amount of work needed to implement a device driver varies.
- For ISA serial ports based upon standard 16550 UART chips all that is required is to pass two parameters to Microsoft’s own serial port device driver code. This gives the highest level of compatibility since there is no non Microsoft code involved.
- With PCI and PCI Express products a similar process will work.
- However UARTs have had many features added to them to help the CPU cope with the increasing burden of a PC running a pre emptive multi tasking Windows OS. The icrosoft DDK code does not support these features and so serial port manufacturers like Brainboxes must provide their own Device Driver code to implement the now necessary serial port UART features like Automatic handshaking and deeper than 16 byte FIFOs.
- How well these Device Drivers are written is a clear differentiator for Serial port companies.
- There is a clear one to one correspondence on Windows API calls when using ISA or PCI Express interfaces even when using highly advanced UARTs. When implementing a Device Driver for Serial Ports that are attached on the other side of a transport link like USB or Ethernet involves dealing with many issues. Achieving compatibility on the Windows PC is a non trivial task since it not only demands an in-depth understanding of the Windows DDK structure but also involves judgement calls in what course of action to follow when status or data is not immediately available and has of necessity to come across a link some distance away in time and space.
- This brings up two main areas of incompatibility that causes applications to fail or work inconsistently:
- Wrong return values passed back to Windows and the application due to misunderstanding the serial API
- Hidden assumptions in the code regarding response times etc
- Hidden assumptions prove hardest to debug
Much of the programming model of original ISA interface has been unconsciously carried forward into later written Windows application code.
- Assumption 1: That the serial device is the exclusive use of the Program on the Host PC.
- True: PCI, USB
- False: Ethernet
- Assumption 2: Latency The serial interface is immediately able to provide back to the PC application status information regarding eg the CTS/DCD/DSR/RI handshake inputs of the serial port
- True: PCI
- False: USB, Ethernet
- Assumption 3: Latency Data transmitted and handshake output line status can effected instantaneously
- True: PCI
- False: USB, Ethernet
- Assumption 4: Latency Instructions to change the Baud rate etc or to flush tx/rx data buffers are effected instantaneously
- True: PCI
- False: USB, Ethernet
- Assumption 5+ Programs tweaked to work with particular devices in typical setups will work even with PC platform changes, versions of Windows, different serial device revisions and external end user equipment.
- It depends ??!!
Installation and Configuration
- In the past how a port was installed and configured was highly dependant on the interface bus used and the preferences of the device manufacturer.
- As the Windows UI has matured it is increasingly likely that a common unified method based upon underlying Microsoft APIs will be used.
- So today installation is often provoked by a plug and play discovery event based on the familiar USB style device discovery.
- So the COM ports added into the PC system and accessed in a standard way.
- Configuration via the Control Panel or increasingly by a web interface.
Traditional COM Port Interface
- Our software gives your applications a true COM port interface and handles all the issues about transport layers, latency and connection protocols.
- Allows you to keep making a return on your proven existing software investment.
- Upgrade to a new connection topology without any fuss.
Latency
- Each layer has its own standardised way of communicating configuration information, serial port data and status information.
- As the data passes up and down the layers from the Application to the physical serial port these processes can add delays:
- Packetising of data to improve throughput
- Data decoded from one standard and re-encoded in the next standard.
- The actual transfer of data across an interface
- The serialising of the data as it is transmitted or received
- This total delay is called the latency.
- Typically the larger the packet of data being transferred the less import the latency becomes when expressed as a % of the total transfer time.
This is part 3 of a 3 part series:
Part 1: Brief History of Serial Communications
Part 2: Latency and Response Times
Download the complete presentation below:
