External touch controller over UART

Technical Support
, , , ,
1

Hello,

I am trying to connect an external touchscreen driver to a Colibri SOM. The touchscreen controller has an RS232 interface and WEC2013 drivers provided at http://www.eeti.com.tw/drivers_WinCE.html After following the vendor’s driver installation instructions, I am able to run the drawtest application and interact with the touchscreen, however, I am unable to use the touchscreen to interact with any windows UI element. Are there additional settings that I need to override/modify in the Toradex BSP to enable this touchscreen? I do not need the 4 or 5 wire touchscreen interface which is included in the BSP by default - do I need to remove this from the BSP?

Thanks,

Aaron

2

Dear @aaron.h
There should be no additional registry settings required. I suspect that the EETI touch driver does not generate regular touch / mouse events. Their DrawTest application could be written in a way to react on EETI custom events.
For such situations we offer the Capacitive Multi-Touch solution. This is kind of a dummy driver that your application can feed witch touch coordinates. The dummy driver turns them into regular touch events to allow interaction with WinCE.

Unfortunately the documentation on the EETI web site is quite sparse and does not explain what the driver does, or how the DrawTest application is coded. I recommend to contact EETI to get additional information.

3

There’s another possible explanation: The EETI touch driver might rely on a standard touchproxy driver which is not our default touch driver.

If this is the problem, you can fix it by simply modifying one registry setting:

[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\TOUCH]
DriverName="tchproxy.dll"    ;The Toradex factory-default value is "colibri_touch.dll"
4

@andy.tx

Thanks for the suggestion. Unfortunately, the driver at the location above was already populated with Touch.dll. Modifying this registry entry actually prevented my system from booting at all. The vendor has replied with the recommendation to check our registry settings. Do you have any other ideas? I noticed that the COM port I am using has a unimodem.dll associated with it - could this prevent the touch screen driver from properly communicating with the COM port?

Thanks!

5

Hi @aaron.h
I was able to reproduce the issue: The system actually is booting. tchproxy.dll tries to load the actual touch driver, and if there is no valid touch driver available, it waits for 120 seconds before it continues the boot process.

The following article describes the options for loading touch drivers with and without the tchproxy.dll. Maybe this helps to make your driver work.

The unimodem.dll driver is not active and therefore doesn’t have any impact on the behavior of the serial port.