Win CE Integrators Guide
Win CE Integrators Guide
These notes refer to the UPDD CE driver 4.1.10 first released April 2011. For customers using the earlier 4.0.6 release please refer to the instructions here.
or Windows Embedded Compact are embedded operating systems. For OEMs requiring a touch screen, or other pointer interface on Windows CE devices, the Touch-Base Universal Pointer Device Driver suite of software includes a 5.x, 6.x and 7.x CE driver.
With this release UPDD supports an interface with the standard Windows CE GWES (Graphics, Windowing, and Events Subsystem) touch interface. This allows for calibration via the built in CE control panel Stylus option and provides an interface to the gesture interface in Windows CE 6.0 and later. The old ‘mouse’ interface is retained for testing purposes and can also be used in situations whereby the GWES touch interface is not part of the CE image.
This UPDD version is built on the same software base as all other UPDD variants so that most UPDD functions available on other platforms are now supported in Windows CE (except for minor differences to accommodate variance in the Windows CE implementation). Known exceptions are listed in the below.
The UPDD Application Program Interface is supported on Windows CE allowing 3rd party utilities to be developed.
The main differences between the new and previous driver are:
· based on the new 4.1.10 driver architecture
· has been implemented as a native CE touch device driver interfacing with the standard Windows CE GWES touch interface
· utilises CE calibration procedure
· supports the native gesture interface introduced in Win CE 6
· is shipped with the new command line utility
· uses the standard UPDD settings file
Serial – Available Oct 11 build onwards.
USB has been tested on X86 and ARM processors. If there are USB interface issues on other processors we may need to be supplied a target system to investigate further and modify the UPDD USB interface where applicable.
I2C has been tested on CE6 X86 only. Needs a manual setting to be defined in the setting file.
Other interfaces such as PS/2, ISA etc could be added if required.
See important Port Interface issues below.
The driver has been tested in house with X86 and ARM CE. We can build drivers for other processors, as supported by the Microsoft CE Platform Builder, on request.
At the time of writing, the processors supported by UPDD in the various versions of CE are as follows:
More information on the CE product range is available here:
Any system/processor can be supported as long as a Board Support Package is available for the target processor. Read
for more information on BSP’s
Target hardware may have to be supplied for testing if any problems are experienced with the driver.
Important note: Although we have built the CE components for the processors listed above we can not test the driver on all supported processors due to lack of target hardware. In theory the drivers should work on the target processor as long as the component build process utilises the relevant BSP.
In this environment, UPDD is supplied as a number of separate components. Software sent via email will be held in the file ZIP file TBUPDDCE.ZIP.. Touch-Base utilises virus detection software on all of our systems but recipients of the software should pass the files through their own virus checking software before proceeding with installation.
Normally a software package will be supplied with just one touch controller supported in which case the settings file can be used as supplied, unless using a serial controller and the com port needs to be changed via the autoinstalldevice setting. If the software package contains more than one controller definition this setting is also used to indicate the serial controller definition to use.
The UPDD CE package consists of the following
The basic system requirements for utilising UPDD are as follows:
· Supported CE version: 5, 6 or 7.
· Supported processor version or one where a BSP program can be supplied. Alternatively x86 based images can be run on a standard PC using the LOADCEPC utility.
· Supported touch controller
driver’s touch interface into CE is via GWES or standard mouse port.
system image must have been created with the appropriate platform builder
with any relevant system packs. We
have had a customer report that he was showing ‘crazy’ errors in
the CE log file and identified the problem as being a CE update applied to
his Visual Studio 2005. He rolled back
the updates and the error disappeared!
Specific embedded or post install requirements are specified in the relevant section below.
The components can either be installed on an existing CE system or embedded into a CE image as detailed below.
Installing on existing image
Installing into an already created image can be performed for two reasons, either to test / demo the driver prior to embedding or as a permanent installation solution whereby there is not an option to embed the driver into the desired image.
If installing the driver for test or demo purposes then the driver can be installed, tested/demoed and then discarded. However, if the installation is being used to install the driver as a fully working solution this can only be achieved on systems that have persistent storage for the file system and the registry such that the changes to the system are retained over a reboot and available during driver load.
These notes are based on installing on a CE5 image that did not contain the touch stylus components built into the image and therefore the driver was configured to use the basic mouse interface to handle cursor movements and click.
Whether a post installation is possible for a given system depends completely on the architecture of that specific system and in some cases may simply not be possible. However these notes can be used as a starting point to experiment.
As a minimum the system will need:
1) Persistent disk storage, such as a flash drive or similar device.
to save updates to the registry again typically on a flash device.
3) A mechanism to load files onto the target system.
You will also need a tool to edit the registry. One such editor is described here
Without these aspects the software will probably not work in a post installation scenario. There may well be other dependencies which prevent this working so we cannot guarantee that post installation will be successful and this will need to be assessed on a case by case basis.
The steps to follow are:
Identify the system path
by examining registry entry HKEY_LOCAL_MACHINE\Loader\SystemPath or
HKEY_LOCAL_MACHINE\Launch\SystemPath for the system path entry. This lists
the folders searched by the system for .dll or .exe files. Identify if one of
these folders is on your persistent storage device which can be used for the
driver modules and settings file or create a new folder and add its location
to this registry entry. If you need to add additional folder names to the
system path you will need a registry editor, such as ceregeditor or SLRE.
driver’s touch interface into CE is via GWES or standard mouse port.
The GWES interface will only be available if the image was built for touch
and includes the Touch
Screen (Stylus) components. If the
touch component is not built into the image (the stylus calibration option
in the control panel will be missing) then enable
the mouse port interface.
supplied updd files and copy to the target system by whatever means are
appropriate, copy to the folder described in Step 1 above. The files *.bib,
*.dat, *.h *.reg are not required on the target.
further registry setting
It is assumed that the developer is using the appropriate Visual Studio, Platform Builder and service packs to create the relevant Win CE image for the target hardware.
The software is supplied in a form to make it easy for users with little experience with Windows CE to get up and running as quickly as possible. CE experts with knowledge of the BIB structure are free to amend the configuration files as required, so long as the embedded files are located in accessible locations on the target and with the correct attributes.
For users unfamiliar with Windows CE we suggest the following guides to creating a Windows CE image.
1. Expand the
tbupddce.zip file. Some of the files are target specific, these target specific
files are shown by the black highlight in the example below (in this case for
the x86 target):
2. Copy the
files for your chosen target (processor) to the root folder of your build
system (typically c:\wince500, c:\wince600 or c:\wince700).
An interesting article describing this functionality is available at
Another comprehensive gesture article: http://blogs.msdn.com/b/marcpe/archive/2009/06/29/let-s-talk-about-touch-part1.aspx
gestures in WEC7 are further described here http://msdn.microsoft.com/en-us/library/ee499124.aspx
and caters for dual touch gestures.
A video relating to WEC7 multi-touch is available here: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=508dba11-4955-437f-abc0-3fef8ccd0b5b.
Having followed the above instructions you should now be able to build and test your CE image.
Additional embedding notes:
1. Registry entries
If using a USB device then one
of the entries in the .reg settings refers to the device and will contain the
USB Vendor and Product ID values. The VID and PID values MUST match the VID
and PID of the controller in use, e.g. Controller has hex VID = 1234 and PID = 11 values. Hex 1234 = decimal 4660 and Hex 11 = decimal 17. Based on this example the settings
would be as follows:
entries for a USB controller define a named USB device that is a placement
holder for the UPDD device and not a device that is actually used but must
· Ensure the InputConfig entry is updated to indicate a touch screen is in use. For more information on this setting see http://msdn.microsoft.com/en-us/library/ee482243.aspx
If, for any reason, the GWES
component cannot be utilised in the image then it is important to enable the ‘mouse’ interface.
4. If system does not have persistent registry or file system determine appropriate
calibration strategy as described in the calibrate section below.
5. Make any
required software changes to the system components. See “Port interface issues” below.
One feature of the CE touch interface is that there is no mouse cursor shown if the Touch Stylus has been enabled in the image. This is by design as in a touch environment the visual feedback is at the point of touch. If no cursor is present, the easiest and quickest test is to touch on the CE desktop – when dragging on this screen a “wire frame” marker is seen. This is particularly useful when working with an uncalibrated or unattached touch screen.
There is also a touch verification utility for WEC7 when using the GWES interface called CETouchView, a standalone tool in the Windows Embedded Compact Test Kit (CTK), You can use CETouchView to verify the raw touch data and gesture messages generated by your device as seen in this screen shot:
Note: In the CETouchView documentation it states you need to set up a registry entry DriverExName in order to view both raw touch data and gesture messages. In our testing we found this to be incorrect and the registry entry should be named DriverName.
The touch screen needs to be calibrated with the desktop such that the point of touch generates a touch at the correct position on the desktop. The calibration procedure generates touch co-ordinate data that is associated with known positions on the desktop. Using this data the driver can calculate the correct desktop position from incoming touch co-ordinate data. This calibration data can be both generated and utilised in a number of ways as discussed below. The method you select will be dependant on your system’s configuration.
Based on your requirements you may choose any combination of the following calibration options to cater for calibration within your system.
The native stylus or UPDD calibration functions are invoked to perform manual calibration. An implementation using manual calibration needs to decide on a strategy for initiating the calibration procedure. E.g. executing the calibration program at start-up or placing an icon on the desktop.
These and other options are implemented via the platform configuration.
One option we are considering is that the driver will automatically invoke the calibration procedure at startup based on a system setting. This would be used in environments where calibration was performed every time the system started. Please contact us if this is required.
Native CE stylus
Once the image is running you can calibrate the touch screen by using the Stylus option in the control panel. This is illustrated below. Note that the exact screens vary according to the system configuration.
This will invoke the calibration procedure:
The native calibration procedure will store calibration co-ordinates in the registry at HKEY_LOCAL_MACHINE\Hardware\DeviceMap\Touch\CalibrationData. Given that the UPDD driver is a GWES conformant driver the native calibration calls the SetCalibrationPoints function within our driver. The calibration data is converted to the format used by UPDD and stored in the UPDD settings file. If eeprom storage is enabled and configured for UPDD data storage then the calibration data is also written to eeprom.
We understand that registry setting HKLM\HARDWARE\DEVICEMAP\TOUCH\MaxCalError deals with how picky the touch calibration application will be when you touch the calibration crosses.
UPDD Calibration function
Once the image is running you can calibrate the touch screen by using the TBcalib program. The calibration data is stored in the UPDD settings file. The number of calibration points used and their position is dictated by the values in the tbupdd.ini file, branch [updd\parameters\1\calibration styles\0]. The active calibration data, taken during a calibration, is then stored in branch [updd\parameters\1]. In this example the default values of 4 calibration points set at 10% margin has been change to 5 points, no margin (0% - corner). Note any changes to the number of calibration points must be reflected in the number of cal and ref entries defined.
calibration start pct=0x00000000
If eeprom storage is enabled and configured for UPDD data storage then the calibration data is also written to eeprom.
If eeprom storage is enabled and configured for hardware eeprom the associated hardware calibration procedure is performed such that the controller scales the co-ordinate output accordingly.
In cases where neither persistent storagen (registry or file) nor EEPROM based calibration are available the calibrated data can be embedded in the target image to pre-calibrate the system. This approach is only suitable for systems where the calibration data does not change significantly over time or with use.
To pre-calibrate the system:
From a command prompt (cmd.exe) type “tbutils dump4tba”.
– for more information see Command Line Interface
Open the file tbcalib.tba created by this process and copy the string
contained in it (if no file is created ensure you are running the program in
a writable folder and try again, e.g. /application/data/updd).
Paste the string into the calibration styles section for the controller
replacing the default info shown in red below. This is in the copy of
tbupdd.ini in your build environment:
Adjust the following settings to cater for any calibration inversion
6) Rebuild the target image.
Define HKEY_LOCAL_MACHINE\Hardware\DeviceMap\Touch\CalibrationData with pre-defined calibration data taken from a system calibrated with the stylus calibration option.
However, we suggest that precalibration in the registry be avoided if possible as these values interact with other items (e.g. will override file based persistence) and the format of this data could possibly change with future UPDD releases.
If correct calibration data is stored in the settings file or registry then the default settings will offer a calibrated system.
Some controllers support the saving of calibration data in persistent memory (eeprom) on the controller itself. Subject to the controller supporting this feature and UPDD implementing EEPROM support for the specific device then calibration data can be saved on the device.
If the UPDD setting file has an entry ‘eeprom protocol = ‘protocol id’ then this indicates that updd supports eeprom storage for the touch controller but it does not necessarily indicate if this is supported in CE due to differences in the CE platform. See EEprom documentation for more information about supported controllers under CE.
For supported controllers simply set the eeprom calibration option in tbupdd.ini to 1
eeprom protocol=’protocol id’ – This is the protocol id used by the driver to support eeprom in the controller.
For the eeprom data to be read from the device automatically at startup the following registry setting must also be set; eepromreadatstart=1; e.g.:-
" eepromreadatstart "= dword:1
Important Note, reading the eeprom data at startup loads an additional module (tbcalib.exe) into kernel memory so in some cases the memory mapping layout of the image may need to change. We most often see this in debug images. If enabling this option leads to a crash in tbcalib at startup this is very likely the cause.
For hardware based eeprom calibration (where supported) the controller’s coordinate touch data will be scaled accordingly.
A common issue with CE devices is saving
calibration data when the device is reset or restarted. There are three
possibly choices available depending on the touch controller hardware and the
setup of the CE device.
1) Registry storage. If using the native calibration program (not tbcalib.exe) calibration data is saved in the registry at HKLM\HARDWARE\DEVICEMAP\TOUCH\CalibrationData. At the point of calibration or at a system restart UPDD is passed this data which is converted to UPDD format and stored in the tbupdd.ini file. If the registry is in persistent storage then the calibration data held there will be saved across a system restart.
2) File system storage. Irrespective of calibration utility used (Stylus or tbcalib based calibration) the calibration data is stored in the driver’s setting file tbupdd.ini. If the file is in persistent storage then the calibration data held there will be saved across a system restart. If the file is placed in a different location to that expected by the driver this setting can be used to specify the alternate location. Note, if both registry and file based calibration data is available the driver will utilise the registry based data although the data will be written to both locations.
3) EEPROM storage. Subject to the controller supporting this feature and UPDD implementing support for the specific device calibration data can be saved on the device.
Unless the target system has persistent storage for the registry, or the file system holding tbupdd.ini, or eeprom storage is used then calibration data will not be saved across a reboot.
If persistent storage is available for the tbupdd.ini or registry file then no further action is required. In the case that a persistent registry is available the software saves the calibration data to the registry and this data is written to tbupdd.ini at startup.
However, if calibration data is not held in permanent or non volatile memory then additional calibration options, such as pre-calibration, should be considered.
Calibration beep option to be investigated and not currently available. Please contact Touch-Base should this be required.
Calling calibration from an application
This section to be confirmed as is untested and speculation only. It has been copied from an article on the internet…
Sometimes it may be necessary to cause a touch calibration to occur from an application, perhaps because of drift or because the initial values as set during the production process weren’t quite right.
This is fairly straightforward to achieve as the relevant method is exposed by coredll.dll
All that is needed is to declare a platform invoke (P/Invoke) to the coredll.dll method, which can then be called from within application code:
A C# compact framework example would be:
public class NativeMethods
public static extern void TouchCalibrate();
The current version of the driver supports operation in a fixed rotated mode. All that is required is to calibrate in the desired rotation (as long as your system’s display driver supports rotation).
The following articles discuss Win CE rotation
Win CE 5 - http://msdn.microsoft.com/en-us/library/ms914404.aspx describes how to set Portrait mode as default if required
Win CE 6 – http://msdn.microsoft.com/en-us/library/ee499095%28v=winembedded.60%29.aspx
Win CE 7 - http://msdn.microsoft.com/en-us/library/ee505713.aspx
Dynamic rotation is not yet supported. Given that GWES is used and is responsible for rotation it is possible that this will also just work, but this is subject to confirmation.
The driver’s settings are located in the UPDD settings file and will usually be set to the default settings for the controller in use. These settings are defined as part of generating the CE driver for a given touch screen device.
On the CE target system there will be 2 copies of tbupdd.ini, the location of which is dictated by the contents of the tbupdd.dat file.
\windows\tbupdd.ini or \Windows\tbupdd.ini.orig (Oct 11 onwards)
This is because the BIB script creates the first entry and the DAT script then creates the second real working entry.
The working copy has to be writeable hence placed in \application data. Should you require this to be in a different writable location modify the tbupdd.dat file accordingly and then define the following registry entry:
HKEY_LOCAL_MACHINE\Drivers\BuiltIn\updd\settings=<path to ini> which identifies the full path to tbupdd.ini
e.g. \Hard Disk\System\tbupdd.ini (please note that the path it must contain the name of the file)
Pre Oct 11 - We did not find a method to eliminate the \windows copy. The redundant copy can be ignored and in any case is very small.
Post Oct 11 - We determined it is not possible to delete the \windows copy so we now copy the file to \Windows\tbupdd.ini.orig and this is in turn copied to the active area. This is handled by the .dat file so no user action is required.
Missing Explorer issues
If the Windows CE image
does not have the Windows explorer component (explorer.exe) the Windows API used
to return screen resolution details returns incorrect information. In this
situation the following entries are required to specify the video resolution:
WEC7 introduced support for dual touch and gestures that can work with gesture aware applications. We added support for dual touch in UPDD version 5.0.2. This is only available via the GWES interface if the appropriate settings have been enabled in the image. The driver receives single and dual touch data from the touch device and posts this to the GWES interface. As long as the controller output characteristics are adequate (data rate, timely pen clicks, correct stylus streams etc) then gestures should be correctly calculated and performed.
As documented: “Depending on your touch screen driver, Compact 7 supports multi-touch gestures with two contact points, or dual-symmetrical gestures. If your touch screen driver supports dual-symmetrical gestures, the gesture engine will try to determine how the X and Y coordinates should be paired. For both dual-touch symmetrical and multi-touch gestures, the gesture recognizer designates one contact point as the primary contact and keeps track of the distance between the primary contact and the secondary contact.
You can use CETouchView to test the raw touch data and gesture messages generated by your device.
The driver’s touch interface into CE is via GWES or standard mouse port. The GWES interface will only be available if the image was built for touch and includes the Touch Screen (Stylus) components. If the touch component is not built into the image (the stylus calibration option in the control panel will be missing) then enable the mouse port interface as follows:
Edit the supplied
settings file tbupdd.ini to add this entry:
Serial port device and com port issues
Device and port definition
The setting autoinstalldevice is used to direct the installation of the device through the UPDD PNP manager. For USB devices this is handled automatically but for serial devices this setting is used to select the required serial device and specify the com port, even when only one is configured in the software package.
This setting is described below.
autoinstalldevice=1¬Microchip, AR1100, Serial¬¬COM1
autoinstalldevice is comprised of several fields separated by the “¬” symbol as described below:
1) The controller id. Usually 1. This tells the PnP manager which TSNNN (default controller settings – one per supported controller in the settings file) entry to select during installation of the device. This value should not be changed unless you have a software package with multiple controllers and you wish to select a controller other than the first defined for installation. E.g. to select TS003 set this to 3.
2) The name with which the device will be installed. This can be freely edited.
3) Unused (needed for compatibility with the standard updd installer).
4) The COM port. This can be edited as required. This is the com port that will be selected when the device is installed. See important Port Interface issues below when defining serial ports.
Stop bit definition
As of the driver issued Aug 2012 the stop bit definition in the UPDD setting file has changed such that the entry StopBits=0x0000000N defines the stop bit usage as follows, where N =:
1 = ONESTOPBIT
2 = TWOSTOPBITS
3 = ONE5STOPBITS (1.5)
Prior to this date the driver interpreted these settings differently, 0 = 1, 1 = 1.5 and 2 = 2.
Important note: when defining a serial device it is important that you do not define the USB settings in the registry as this will prevent touch working in serial mode. USB is considered configured if the vid is defined in the registry
It should not be defined or commented out as in the example above.
To configure this interface you need to manually update the port type in the settings file thus:
The current implementation uses a I2C proxy driver, which must be loaded, and you need to define the Port value to a valid value for the proxy driver. In the system we used to develop the I2C interface the port value was set to “I2C1”. We believe that an I2C interface will be very implementation specific and the driver may need tailoring to the specific utilisation of the I2C interface. Please contact us to discuss further.
Not currently supported in the new driver. Please contact us should this be required.
As standard the GWES touch interface does not utilize the mouse cursor therefore there is no mouse cursor movement when touching the screen. In fact, when using the touch interface the mouse cursor becomes invisible. For test purposes, during the development of the new native touch interface we retained the previous mouse interface (which utilises the SendInputAPI) and this can be enabled if mouse emulation (and therefore mouse cursor movement) is required. It should be noted that operating systems are moving away from the system cursor when utilising touch and we believe more end users should be encouraged to use touch without the traditional mouse cursor utilized for visual placement feedback. Mouse cursor is Mouse interface, other or no visual feedback is Touch.
However, should you wish to see mouse cursor movement then the following UPDD setting will enable the old mouse interface:
It should be noted that any touch functionality built into the OS which is enabled when touch input is processed via the GWES touch interface will be lost if the touch data is passed via the mouse interface. This is likely to be more relevant to Windows Compact (CE 7) than pre CE 7 versions.
We believe that for mouse mode to work you will need to configure the Mouse Catalog in your CE image.
Windows Compact Edition 7 supports SMP (Symmetric multi-processor) systems. Until recently all CE systems have utilised a single processor core and updd has been tested on such systems.
The core UPDD driver software runs on a number of systems and is known to be stable on multi processor systems.
However we have been advised by a customer that on SMP systems problems can occur.
Until such time as we can reproduce this issue we have implemented a solution to run all UPDD threads on a single core.
To utilise this new feature set a registry DWORD value at
The value specified is the processor number to be used, we understand that this is a number from 0 – n-1 where n is the number of processors available.
In order to provide adequate performance it is necessary for the driver to execute at a higher priority than other active processes. In particular the explorer component consumes a lot of CPU in some cases, so dragging items on the desktop can be slowed. By default all critical threads in the driver execute at priority level 249 (Hex FA) which gives good results in most cases (which was the same as the HID mouse).
Should you wish to alter this priority for any reason you can change the following settings.
For the main driver (upddce.dll) add the Priority setting in tbupdd.ini setting in the [updd] section.
priority=0x000000FA <change as required
For the USB interface component (tbupddceusb.dll) add the registry setting
"priority"=dword:fa <change as required
Module size and ram usage
The tbupdd.bib specifies that all modules/files are loaded:
upddce.dll $(_WINCEROOT)\upddce.dll NK SHK
tbapi.dll $(_WINCEROOT)\tbapi.dll NK
tbupddceusb.dll $(_WINCEROOT)\tbupddceusb.dll NK SHK
tbcalib.exe $(_WINCEROOT)\tbcalib.exe NK
tbutils.exe $(_WINCEROOT)\tbutils.exe NK
ace.dll $(_WINCEROOT)\ace.dll NK
tbupdd.ini.orig $(_WINCEROOT)\tbupdd.ini NK
The ACE and TBAPI files are loaded in both user and kernel space and the user space version may not be required if the utilities, such as tbutils and tbcalib, are not being utilised in which case they can be excluded from the tbupdd.bib file. When using serial devices the tbupddceusb.dll can also be excluded.
Excluding these modules is subject to verification within your own image.
Touch packet data rate
In years gone by it had been observed on some lower end systems that if all the incoming data packets from fast touch controllers are processed it can have a detrimental effect on the performance of the system. By default the driver processes 100% of the packets. This percentage can be adjusted by the UPDD setting [updd\Parameters\1\]:SampleRate.
Changing the setting from 64hex (100 dec) to 32hex (50 dec) indicates to process 50% of incoming packets.
Windows CE does not support multiple monitors. However UPDD will support a configuration where 2 or more monitor and associated touch-screens are utilized in a “shadow” configuration, i.e. where both monitors show the same image. No special UPDD configuration is required for this mode, each additional controller detected will bind to the same device definition. Calibration can take place on either monitor. It is assumed that calibration on one monitor is good for the other so the devices must be identical.
In some cases you may receive a package that supports multiple controller definitions. In this case you will see multiple entries listed in tbupdd.reg in sections beginning:
This occurs when a controller case have multiple VID or PID designators.
In this case the default tbupdd.reg file must be amended so that the bootstrap VID and PID entries (shown here)
Match the controller in use. The default settings will match the first listed controller. NB the bootstrap entries are in HEX whereas the LoadClients entries are in decimal.
A toolbar is an area on the touch screen that acts independently from the main calibrated video area. A toolbar can simply be used to mask off areas of the calibrated video area or they can be used to trigger an event. Toolbar utilisation is described in the Toolbar document. To utilize in a CE environment the toolbars would need to be configured in a OS using the UPDD Console, Toolbar dialog and then embed the toolbar entries in the settings file into the CE settings file.
We are aware that Microsoft publishes a number of settings that relate to the GWES touch stylus and we are unsure if these settings relate to all versions of CE or have in some cases been superseded by newer versions of the OS. Nevertheless we are aware that various settings are documented that may or may not affect stylus usage. Experimentation would be necessary to determine the affect they have on the stylus interface. One such reference to stylus registry settings is here.
Double Click Setting
One interesting entry is the dblTapDist (also described for WEC7) setting at HKEY_CURRENT_USER\ControlPanel\Pen documented as “Default setting is 20 pixels. Indicates the size of a reference rectangle constructed around the location of a stylus tap. If a second tap occurs inside the rectangle within the allowed time, it is considered a double-tap.”
This Win CE 6 link also references dblTapTime but indicates it is only used with the Thin Client shell instead of the Standard shell. It is documented as “Indicates the time between clicks in a double-click action. The default value for a thin client is 256 milliseconds or 0xFF in hexadecimal format.”
A good overview of CE touch related issues can be viewed here.
If you’ve embedded the software and the touch does not work there are several things you can check. Several of these require an active debugger connection, such as that provided by Platform Builder.
1) Check for known issues
Check the known issues section.
2) Manually reload the driver
This operation requires a connection to the driver process (implemented in upddce.dll). If a message indicates that this connection cannot be made then recheck that upddce.dll is in place and check all registry settings.
If you are using a USB controller and a message box pops up at startup asking for a driver for a specified device, then check if this message occurs without the controller plugged in. If not then this suggests an error in the registry settings, pay particular attention that the vendor id and product id match the controller in use. See the multi controller definitions section later in this document if you have more than one controller listed.
3) Check the UPDD modules loaded
Check in the debug log that both upddce.dll and tbupddceusb.dll (if using USB) are loaded and not subsequently unloaded. The usage and location of the debug log will be image specific.
Typically the module load entry will read:
PID:00400003 TID:03770006 OSAXST1: >>> Loading Module 'tbupddceusb.dll' (0xC0845838) at address 0xEE5B0000-0xEE5B6000 in Process 'NK.EXE' (0x85302A60)
As see in the debug log below:
Check the log for other messages including the text UPDD, particularly when touching the screen. In the event of USB errors useful information is output in the log. Typical touch related entries are as follows, showing the driver loading and starting to function:
PID:400002 TID:10f0002 DEVICE!RegReadActivationValues
RegQueryValueEx(Drivers\BuiltIn\updd\BusPrefix) returned 2
In this example an exception has been thrown on the first touch (possibly due to the missing Touch Stylus component):
4294869773 PID:400002 TID:5300062 TBUPDD: 1748 CUSBConnection::ReadInterruptDataThread read 1 bytes
4294869783 PID:400002 TID:526000a TBUPDD: 1748 CCEMousePort::MouseEvent 41335 43949
4294869827 PID:400002 TID:526000a
4294869827 PID:400002 TID:526000a !ERROR: Calling EnterCriticalSection on a CS (c0fe2fa0) that is not initialized!
4294869852 PID:400002 TID:526000a Coredll: DEBUGCHK failed in file d:\yzkiqfe\private\winceos\coreos\core\dll\cscode.c at line 117
4294869881 PID:400002 TID:5300062
4) Enable UPDD debug log information
Additional UPDD debug information can also be seen by setting the tbupdd.ini debuglevel setting to 5.
The USB component also shows more debug information when executed in a debug build.
5) File based debug
To enable file based debugging define these settings:
Under CE the file produced is /application data/updd.log.
FileDebug=0x00000000 is OFF.
If after following the steps above you are unable to resolve the issue please send the log file to us for further analysis.
Serial debug connection
If you wish to use a Serial connection to the Windows CE device for debug purposes we did document many years ago that there is a consideration that is not always made clear in the Microsoft documentation. A null modem cable is required, but this differs from a standard null modem cable in that the RI pin is connected straight through. Without this connection it will be impossible to make a serial connection from the NT host to the Win CE device. Nowadays most system integrators do not debug over serial so we are not sure if this is still a valid issue.
Touch-screens may be connected to a CE device via a standard serial (COM). A CE image builder should bear in mind that the default CE image generated by platform builder might well make assumptions regarding the usage of such ports. E.g. debug output will be sent to the first physical COM port, preventing its use. By default, CE creates two com port instances, Com 0 and Com 1. Com 0 is used as the debug port and relates to the physical port com 1. Com 1 is therefore the first port that can be used by the touch screen that actually relates to the physical Com 2 port.
Many customers have been unable to get their touch screens working with a default CE build until they have plugged the touch screen into com2 or changed the BIOS so that serial port is referenced as Com2, although the references in the CE build refer to com 1 !!!!
In some circumstances the CE builder will need to amend the CE configuration to alter the default serial port behavior. If you are not familiar with this procedure we have technical bulletin that covers this subject.
We have discovered that with serial communications on some motherboards if we set up UART flow control options then we receive either no data or garbage. When this setup is omitted the serial port works as expected. This is fine for serial controllers that do not need either a specific state or change of state in the CTS/RTS lines in order to operate.
We have introduced a device level setting called “IgnoreDCB” and if it is set to 0x00000001 then the com port flow control initialisation is skipped.
[updd\Parameters\1\]:IgnoreDCB = 0x00000001
We found that the TI OMAP Platform motherboard required this setting.
This is also used for the Zytronic ZXY100 controller on ARM hardware where setting DCB causes rubbish to be read
The CE image must be amended to support the USB host controller (this is the system’s USB host controller and NOT the USB touch controller). Consult the manufacturer’s documentation and or Platform Builder help for details of how to achieve this with the particular model of hardware in use. A 3rd party driver might be required for the host controller, although this has not the case for the hardware we have tested so far. To ensure the CE system’s USB host controller is functioning use a HID mouse prior to testing the USB touch controller.
PS/2 support needs to be reinstated for the new driver as and when required….
The list of known issues is as follows:
warning message in debug log with touch working fine
installing driver image worked once but failed to boot on subsequent reboots
Hot plug of
device not working
\application data\updd folder and therefore no tbupdd.ini
shown in system log when touching – touch no longer working
working although debug logs showed GWES and Cesendinput driver interfaces
both working as expected
Known limitations to be addressed as required:
USB and serial and i2c (Nov 12) support only. Other interfaces to be added as required.
No sound support.
Dynamic rotate untested.
Hardware based eeprom storage not supported.
Limited testing of software based eeprom calibration storage.
No GUI settings dialog (UPDD Console) to allow for dynamic setting changes.
For further information or technical assistance please email the technical support team at email@example.com.