Serial

Since release 6.0.251 the driver supports RS232 devices.

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.

Serial ports are normally added using the UPDD Console but can also be added using the Command Line Interface as per the Windows example shown 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: The fully qualified device path is defined in the rs232.port setting, e.g. /dev/cu.USA19H64P1.1
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: