Serial


Since release 6.0.251 the driver supports RS232 devices and has been tested in Windows, MacOS and Linux but in theory should work in all supported OS.

At this point it is worth noting that for a serial device to be supported serial data must be seen when touching the screen prior to utilising UPDD. For example, a customer reported difficulty with a PCI-E serial adapter under Linux so used a USB / serial adapter and all was OK.

RS232 support is really only needed for old legacy systems and hence we have only added support that should suffice for the majority of serial devices. To this end we only support devices with a single fixed length packet definition.

If the UPDD software package contains support for an RS232 device it has to be manually added and the port defined using the UPDD Command Line Interface as shown in this Windows example:

Since UPDD V6, release 6.0.377, we have added a simple settings program that can be used to add a serial device and define the port to use. This only adds a serial device based on the first serial device defined in the list of supported devices. This can be used if you only have one serial device type supported in the driver package or you want to add the first one supported (in the example below being the Zytronic device. If you wanted to add a serial device based on the 'Salt' device you would have to follow the manual instructions below).

  1. List the supported devices in the UPDD software and note the controller id of the device you wish to add - 9 devices listed
  2. Enter the add device command passing the controller id as required - add device 9 'Salt, PenMount 9000 Series, Serial
  3. List the devices configured in the driver - One USB automatically discovered and one manually added
  4. Note the UPDD device handle for the serial device -  In this case device handle '2' (shown as NOK because the default com port was COM1 that does not exist so could not be opened)
  5. Set the serial port as required - set device (handle) 2 to COM3 to reflect the com port listed in the Device Manager
  6. List the devices to confirm all is now OK
  7. At this point touch should be working and depending on the default calibration data may or may not be calibrated.

The port name can be predefined in the software package if required. Other RS232 settings will be set to the default for the device but can be changed as required using the upddutils set command.

Testing RS232 ports in various OS is described here.

Important notes:

  • Since UPDD 6.0.543, once a serial device is added the driver will try to connect to the serial port every 5 second until a successful connection is established. This was implement for USB to serial adaptors whereby the virtual port may not be created / ready at the time the driver loads and tries to establish a connection to the port.
  • This implementation assumes the serial port is always available once the device connection is opened. Once connection is established it is further assumed the port is not removed, say as in the case of a serial to USB adapter that creates a virtual RS232 port that could be unplugged.  Once a port is opened (OK) the software will not currently reflect the status change (NOK) of a lost device or automatically recover a lost connection.

Serial data filtering

Some old serial devices may produce a 'glitch' in the x and y co-ordinate range such the the touch may temporarily jump to an incorrect position and then jump back again.  If this occurs there are two settings available to filter out glitches; deglitch.packets and deglitch.raw_points. If either of these settings are 0, deglitch is disabled, if both are set deglitch is enabled.

With this feature on, a packet will not be accepted unless it is within deglitch.raw_points of the previously accepted packet or deglitch.packets have been received each within deglitch.raw_points of the previous (not accepted) packet.

Serial port names

The serial port names differ between operating systems.  Port names will be associated with physical UART ports or virtualised ports using a USB to serial adaptor, as listed below:

OS Physical  Virtualised 
 Windows ComN - as listed in the Device Manager
Physical serial port

The port name is defined in the rs232.port setting, e.g. com1
ComN - as listed in the Device Manager
In the case below created by a Keyspan USB to serial adaptor

The port name is defined in the rs232.port setting, e.g. com3
 MacOS Will be listed in the /dev folder as tty.[id].
Use the command ls /dev/{tty,cu}.* to list the serial ports.
The fully qualified device path is defined in the rs232.port setting, e.g. '/dev/tty.serial.

Port name dependent on virtualised hardware and software but typically starts with 'cu.'. Use the command ls /dev/{tty,cu}.* to list the serial ports
In this example the device is seen in the dev folder: 

and as listed in the keyspan utility:

A customer reported that using a serial to USB adaptor that used the FTDI FT232R chip created a device name of tty.usbserial-A104PFUI.

The fully qualified device path is defined in the rs232.port setting, e.g. '/dev/cu.KeySerial1

 Linux Will be listed in the /dev folder as ttysN.
The fully qualified device path is defined in the rs232.port setting, e.g. '/dev/ttys0 for port 1

Serial to USB adaptors should normally be registered within the dev folders as ttyUSBn.
The fully qualified device path is defined in the rs232.port setting, e.g. '/dev/ttyUSB0.

Macro language

For USB the initialisation protocol is determined by information extracted from the device's HID Report Descriptor.

For serial devices, that need an initialisation sequence, we utilise a macro language.  
This is a subset of the Macro language utilised in UPDD V5 and should be sufficient to initialise most serial devices that need initialising. Additional initialisation features can be added as and when required.

The device setting rs232.macro is used to hold the macro.

A macro is executed immediately after the port is opened. The following options are supported:

Notation Meaning 
 // Denotes comment line
// this is a comment
[RTS 1] // this is also
           // so is this
 [HEX] Denotes that the characters that follow are pairs of hex characters separated by spaces. This is the default mode. The mode remains in effect until the end of the string, or until [ASCII] macro command is encountered. E.g. [HEX]01 02 03
 [ASCII] Denotes that the characters that follow are ASCII characters.  The mode remains in effect until the end of the string, or until [HEX] macro command is encountered. E.g. [ASCII]ABC
 [DTR n] where n = 0 or 1. E.g.[DTR 1] sets the DTR line active (high). [DTR 0] sets the DTR line inactive (low).
 [RTS n] where n = 0 or 1. E.g.[RTS 1] sets the RTS line active (high). [RTS 0] sets the RTS line inactive (low).
  Note: CTS and DSR are input lines and thus cannot be set in a macro
 [Wait nnnn] Pause for the specified number of milliseconds.
 [Break n] sets the UART break line to the value of n (0 or 1).
Search