When connected via USB, the Touch Sensor Module communicates in Full Speed (12 Mbit/s) in two modes: Raw HID mode (also called HID Pipe) and HID Touch Digitizer mode. HID Touch Digitizer mode is initiated automatically as soon as the sensor module is plugged in. In order to use Raw HID mode, the module's operation mode must be changed. For more information, refer to Initializing Sensor Modules.
HID Touch Digitizer Mode
The Touch Sensor Module acts as a HID Input device and communicates directly with the OS, and is completely plug and play.
Ubuntu 17.10 - 18.04
The sensor module is not recognized as a touch screen in the Ubuntu versions 17.10 - 18.04. This has been fixed and works fine in Ubuntu 18.10.
Raw HID Mode / HID Pipe
This mode uses two HID Feature Reports to communicate with the host.
- Send data to the sensor module by writing to Feature Report 1.
- Read data from the sensor module by reading from Feature Report 2.
Refer to zForce Message Specification for examples of requests, responses and notifications.
USB Communication in Different Operating Systems
Depending on the system and programming language you are using to write and read from a feature report, the implementation differs. For example, in Windows, this is abstracted and the hid.dll offers a function to get and set feature reports, while in for example a UNIX based OS, you might have to implement your own function to get and set a feature report.
The communication heading below describes how to implement your own get and set feature report functions, using a control transfer.
USB Permission
Depending on operating system you might need explicit permission for your program to have access to the HID device.
How to Implement Custom Functions for Raw HID Communication
In order to communicate with the sensor module the data flow type called control transfer should be used. The control transfer usually takes the following parameters:
- Request Type (int)
- Request (int)
- Value (int)
- Index (int)
- Data (byte array)
- Length (int)
- Timeout (int)
Writing to Feature Report 1
When writing to the sensor module, a full 257 bytes need to be sent no matter how long the actual message is. Take a look at the code snippet below, to see how this could be done.
uint8_t operationMode[] = { 0x01, 0x17, 0xEE, 0x15, 0x40, 0x02, 0x02, 0x00, 0x67, 0x0F, 0x80, 0x01, 0xFF, 0x81, 0x01, 0x00, 0x82, 0x01, 0x00, 0x83, 0x01, 0x00, 0x84, 0x01, 0x00 }; // The first two bytes are the header. First byte is feature report, second byte is length of the following data. uint8_t data[257]; memcpy(data, operationMode, sizeof(operationMode)); int requestType = 0x00 | (0x01 << 5) | 0x01; // USB_HOST_TO_DEVICE | USB_TYPE_CLASS | USB_RECIPIENT_INTERFACE int request = 0x09; // SET_CONFIGURATION = 0x09 int value = 0x0301; // 0x03 for feature report, 0x01 for feature report 1 int index = 0x0000; int length = sizeof(data); int timeout = 0; connection.controlTransfer( requestType, request, value, index, data, length, timeout);
Reading from Feature Report 2
When reading from feature report 2, the message is always 258 bytes long.
uint8_t data[258]; int requestType = 0x80 | (0x01 << 5) | 0x01; // USB_DEVICE_TO_HOST | USB_TYPE_CLASS | USB_RECIPIENT_INTERFACE int request = 0x01; // CLEAR_FEATURE = 0x01 int value = 0x0302; // 0x03 for feature report, 0x02 for feature report 2 int index = 0x0000; int length = sizeof(data); int timeout = 0; connection.controlTransfer( requestType, request, value, index, data, length, timeout);
Read More on Software Integration
- Preparing the Sensor for Communication
- zForce Communication Protocol
- Update Firmware
- Parameter Overview
Read More