1. Windows_20CE.zip Driver
2. elo115Ce60.txt File Contents

elo115Ce60.txt Driver File Contents (Windows_20CE.zip)

Elo touchscreen software version 1.15 for WinCE6.0.
Copyright 2007 Tyco Electronics / Elo TouchSystems
2007-07-30 David McCracken

CONTENTS
This is revision 1.15 of the Elo touchscreen OS components for Windows CE6.0. 
It contains two DLL drivers and two EXE support applications plus project 
files to enable the components to be built into a system. Each component has an 
independent version number as well as being a part of the package revision 
(1.15).

eloUsb.dll (1.25) is the USB driver. 
eloSer.dll (1.22) is the serial driver. 
eloVa.exe (2.40) is the touchscreen video alignment program.
eloTalk.exe (1.10) is a touchscreen configuration and diagnostic application.

For each component, the install package includes CPU-agnostic bib, pbpxml, 
pbcxml, and reg files and CPU-specific dll or exe, pdb, and rel (if dll) files. 
This release supports X86, ARMv4i, MipsII, and MipsIV.

PREVIOUS USERS
EloUsb.dll replaces EloHid.dll. EloSer.dll replaces EloTch.dll and EloStub.dll. 
If you have been using the USB driver, you must remove eloHid from your 
platform design and replace it with eloUsb. If you have been using the serial 
driver, you must remove eloTch and eloStub from your platform design and 
replace them with eloSer. 

EloUsb.reg is derived from the old eloHid.reg. EloSer.reg is derived from the 
old eloTch.reg merged with eloStub.reg. New Registry keys have been defined to 
support new capabilities, including eloVa timeouts, right-click-on-hold, and 
controller-based (NvRam) calibration store. EloUsb.reg identifies the USB 
driver, eloUsb.dll, as both a USB and a HID device. Previously, it was only a 
HID device.

INSTALL
Get installation files by invoking Elo115Ce60.exe. This is a self-extracting 
ZIP file. It copies all files to \wince600\EloTouch unless you select an 
alternate destination.

ADD COMPONENTS
To add Elo components to your target image, insert them as existing projects, 
directly referencing their project (pbpxml) files. This is done for each 
component individually in Visual Studio by Project > Insert >Add Existing 
Subproject and pointing to the appropriate pbpxml file under \wince600 
\eloTouch, for example wince600\eloTouch\eloUsb.pbpxml. All necessary output 
files will already exist under eloTouch and simply remaking the run time image 
adds the components to nk.bin. Similarly, a component can be removed by 
deleting it from the Workspace and remaking the run time image.

REG FILES
The drivers require their reg files (eloUsb.reg and eloSer.reg) to be merged 
into the OS image. In CE6.0 the files under EloTouch are automatically merged. 
You can edit these files directly and remake the run-time image to change 
touchscreen operating parameters initialized by Registry entries. 

FEATURES OF RELEASE 1.15
1. EloVa timeouts controlled by Registry keys.
2. Calibration data storage and automatic retrieval to/from the controller's NvRam.
3. Right-click-on-hold. 
4. EloTalk touchscreen configuration tool.
5. Two-part serial driver eloStub.dll and eloTch.dll replaced by a single driver, eloSer.dll. 
6. The USB driver, eloHid, is replaced by eloUsb.
7. SmartSet communication.

ELOVA TIMEOUTS
The video/touchscreen alignment and calibration application, eloVa.exe, 
presents a sequence of touch targets. After the user touches each of these, the 
program presents two buttons for the user to accept or reject the results. The 
program waits for user input at three distinct phases. When it is first 
invoked, it displays the first target and waits for the user's touch. After 
each touch, the program displays the next target and waits for another touch. 
The initial touch wait and subsequent touch waits represents two distinct 
phases with potentially very different requirements. Often eloVa is invoked 
automatically at startup, and the delay before the first touch may be quite 
long. However, once the user has begun responding to eloVa, the delay should be 
rather short. The third timing phase occurs while waiting for the user to press 
one of the accept/reject buttons. If the process has gone well, the user should 
respond quickly. If alignment is very bad, for example due to random touches, 
the user may not be able to activate one of these buttons at all. 
   
Previously, eloVa used fixed delays for each of the three phases. Now, the 
delay for each phase can be determined by Registry settings. One set of 
parameters is shared by all touchscreens in the system. The keys are 
"VaTime1", "VaTime2", and "VaTime3", setting, respectively, the first touch, 
intra-touch, and accept/reject delays. These are stored in the Registry under
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
Each value is a hexadecimal dword in seconds. A value greater than 0xFFFF is 
interpreted as infinite, which should only be used, if at all, for the initial 
touch delay. The default values are 0x14, 0x10, and 0x14, for an initial delay 
of 20 (decimal) seconds, intra-touch delay of 10 seconds, and accept/reject 
delay of 20 seconds.
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
;--- ELOVA TIMEOUTS ---------------------------------------------------------
; For all EloVa timeouts, values > FFFFh mean infinite.
  "VaTime1" = dword: 14 ; Initial timeout. Default 20d (14h) seconds. 
  "VaTime2" = dword:0A ; Timeout between target touches. Default 10d (0Ah) seconds.
  "VaTime3" = dword:14 ; Timeout to accept or reject. Default 20d (14h) seconds.

CALIBRATION DATA STORE
The touchscreen drivers convert raw touch events into system pointer device 
messages using calibration information stored in either the Registry or the 
touchscreen controller. This information can be pre-stored in the production 
process and/or as a result of executing an alignment program, such as eloVa. 
   
One advantage of storing calibration data in the controller is that the data 
remains with the device. Thus, a touch monitor can be calibrated in one system 
and moved to another simply by attaching the touch monitor to the other system. 
More significantly, using the controller's non-volatile memory to store the 
data enables persistent recalibration in a system that doesn't have a 
persistent Registry, as is often the case in CE-based systems. The Registry 
image in ROM/flash is copied into RAM and any changes in the RAM-based Registry 
are lost when the system is turned off. If the touch monitor doesn't require 
field recalibration then static calibration data in the Registry image is 
sufficient. Otherwise, the monitor must be recalibrated whenever the system is 
turned on, or the Registry must be persistent, or the data can be stored in the 
controller.
   
Not all controllers support calibration data storage. The controllers that do 
provide this are 2216, 2500, 2700, 2701, 4000, 4500, 4501, and 5000. 
Controllers that afford both serial and USB interfaces support this identically 
on either interface but some, such as 4500, require different calibration data 
for serial vs. USB. These must be calibrated through the same interface through 
which they are used (the system need not be the same, however).
   
The calibration data store is independently defined for each touch monitor in 
the system by its Registry key "CalStore", which is a bit-mapped dword. Only 
the lowest byte is used. The low nibble determines the source that the driver 
reads when a touch device is attached (or at system startup). The high nibble 
determines the destination that eloVa writes when the user accepts a 
calibration. In both cases, bit 0 indicates controller and bit 1 indicates 
Registry. Thus, the value 1 indicates controller, 2 indicates Registry, and 3 
indicates both. For example 0x31, tells the driver to load calibration data 
from the controller's NvRam and EloVa.exe to write it to both the controller 
and Registry. Writing to the Registry affords a convenient means of remotely 
viewing the parameters (with Remote Registry Editor on the host computer). If 
the target's Registry uses flash memory for persistence, it would be best to 
turn off this feature to reduce wearout by setting CalStore equal to 0x11. If 
the source nibble is 3, calibration data from the controller will be used. If 
CalStore is not defined, the Registry is used for both source and destination.
In eloUsb.reg:
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB]
  "CalStore" = dword:31    ; low nibble = src, high = dest. 1 = controller, 2 = Registry, 3 = both.

In eloSer.reg:
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
  "CalStore" = dword:31    ; low nibble = src, high = dest. 1 = controller, 2 = Registry, 3 = both.

RIGHT CLICK ON HOLD
The drivers can simulate a right mouse button click by the user pressing in one 
place for a specified length of time. This time and other parameters 
controlling this feature are established by Registry keys individually for each 
touch monitor in the system. These are located under:
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB]
for eloUsb and under:
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
for eloSer.

The timing for right-click on hold, cable disconnect untouch, and other 
functions related to touch is provided by one timer (per touch monitor) whose 
period is defined (in milliseconds) by the Registry key "TouchTick". If this 
key is not defined, all touch timer functions are disabled, regardless of 
whether related keys are defined. The value of TouchTick is normally 0x64, 
providing 100 msec resolution. Higher resolution (smaller period) may be 
defined but will consume more CPU bandwidth. Bandwidth consumption can be 
reduced at the expense of resolution by defining a larger period. 

The Registry key "HoldEventTick" defines the number of TouchTick counts to 
trigger a right-click. For example, if this is 8 and TouchTick is 0x64, the 
resulting hold time requirement is 800 msec. If HoldEventTick is 0, the 
function is disabled.

The Registry key "HoldShowTick" defines the number of TouchTick counts to 
trigger visual feedback reminding the user that continued holding will result 
in a right click. If HoldShowTick is 0, feedback begins immediately upon touch. 
Any value larger than HoldEventTick disables visual feedback and the user will 
have no indication that a right click is imminent.

If visual feedback is enabled, the driver displays a reverse video square 
around the touch point. At each count of TouchTick, this expands by the number 
of pixels specified by "HoldShowStep".

If the user moves the touch point before the HoldEventTick timeout, right-click 
on hold is disabled until an untouch occurs, allowing drag operations to 
proceed without interference. A small amount of touch position change is not 
interpreted as deliberate movement. The amount of movement required to indicate 
a real drag is defined by the key "Hold Jiggle". This is in normalized (to 
remove technology differences) touch screen position units, which are of higher 
resolution than most video screens. A typical value of 0x400 provides a jiggle 
area of about 10 by 10 pixels on most screens. 

Typical Registry keys for right-click on hold are:
;... Hold touch timer. Used for cable disconnect and right-click-on-hold
  "TouchTick" = dword:64  ; Tick resolution. e.g. 0x64 = 100msec per tick.
;... Right-Click-On-Hold ..............................
  "HoldEventTick" = dword:8  ; Tick count til event. 0 disables.
  "HoldShowTick" = dword:1   ; 0 = immediate feedback. >= HoldEventTick = no feedback.
  "HoldShowStep" = dword:6   ; Feedback step size in pixels.
  "HoldJiggle" = dword:400   ; Hold perimeter in absolute touch units. Movement inside is still hold.

Right click on hold by the driver is not compatible with the similar, but more 
primitive, facility provided by Aygshell. Since this feature of Aygshell cannot 
be turned off, to use the driver facility, the target operating system must not 
include Aygshell. 

FORCED UNTOUCH
If communication with the touch monitor fails, for example due to cable 
disconnect, while in the touched state, the system may never receive an 
untouch. To prevent such a hung touch, the driver can force an untouch at a 
specified TouchTick count without untouch or steam events. This facility 
existed in release 1.14 but has been merged with right click on hold, changing 
its Registry keys. It now depends on "TouchTick" for timing and the trigger 
count is defined by "UntouchTickCount". 

Not defining UntouchTickCount or defining it as 0 disables forced untouch. In 
most cases, the forced untouch timeout can be quite short because the facility 
does not simply count the time from the initial touch but is reset at every 
stream touch message. Thus, even a setting that detects cable disconnect within 
milliseconds allows unlimited touch time. This is especially useful for the 
2500U and 3000U controllers, which occasionally lose an untouch message when 
the system is very busy. For these controllers, an untouch timeout of 300 msec 
prevents missing untouches without causing false untouches. The 2216 controller 
will cause false untouches with such a short timeout. Other controllers can 
operate with this timeout but they only need cable disconnect detection, which 
could be considerably longer. The circumstances of the application dictate the 
ideal range of timeouts but good starting points are 300 msec for the 2500 and 
3000 controllers and one second for all others.

As with all Registry keys related to TouchTick, UntouchTickCount is under
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH\USB]
for eloUsb and under:
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
for eloSer.
For example:
;... Lost untouch and cable disconnect .......
  "UntouchTickCount" = dword:0A ; 0 disables

ELOTALK
The EloTalk application program comprises a number of touch monitor 
configuration and test facilities. Related facilities are grouped into tabbed 
dialogs. The SmartSet dialog provides direct communication with any touchscreen 
controller. Among other things, this allows the serial number and calibration 
data to be read and written. The "Touch Hold" dialog provides a means to set 
any of the right click on hold and forced untouch parameters in order to 
determine the best settings for a particular application. The settings will be 
stored in the Registry as well as immediately in the driver but, unless the 
Registry is persistent, the static OS image settings will be restored if the 
system is rebooted. The ideal settings should be copied into the appropriate 
reg file (eloUsb.reg or eloSer.reg) and the OS image rebuilt for permanence.