|Top Previous Next|
The HidDevice object is use to interact with the opened hid device.
The first byte of data must contain the Report ID. For devices which only support a single report, this must be set to 0x0. The remaining bytes contain the report data. Since the Report ID is mandatory, calls to write will always contain one more byte than the report contains. For example, if a hid report is 16 bytes long, 17 bytes must be passed to write, the Report ID (or 0x0, for devices with a single report), followed by the report data (16 bytes). In this example, the length passed in would be 17.
hid_write() will send the data on the first OUT endpoint, if one exists. If it does not, it will send the data through the Control Endpoint (Endpoint 0).
Input reports are returned to the host through the INTERRUPT IN endpoint. The first byte will contain the Report number if the device uses numbered reports. Timeout is the number of milliseconds to wait or 0 if wait indefinitely. Len is the length of the data to receive.
In non-blocking mode calls to read will return immediately with a value of 0 if there is no data to be read. In blocking mode, read will wait (block) until there is data to read before returning.
Feature reports are sent over the Control endpoint as a Set_Report transfer. The first byte of data must contain the Report ID. For devices which only support a single report, this must be set to 0x0. The remaining bytes contain the report data. Since the Report ID is mandatory, calls to setFeatureReport will always contain one more byte than the report contains. For example, if a hid report is 16 bytes long, 17 bytes must be passed to setFeatureReport: the Report ID (or 0x0, for devices which do not use numbered reports), followed by the report data (16 bytes). In this example, the length passed in would be 17.
Gets the feature report for report id reportId. Note that report id is passed as a number not a binary.
Closes the resources associated with the hid device. Make very sure that you are no longer using this device, especially any blocking HidDevice::read or getFeatureReport functions. These will crash Girder if you close while they are still running.
The code below sends a CCF code from a PIR-1 or PIR-4. The hidDev variable came from the example code in the hid.open section. What the function below does is basically split the CCF code into 60 byte chunks. Prepends a header with report id = 0, PIR command id = 14, flags 0 (continue), 1 (first packet) or 2 (last packet) plus the length of the data in bytes followed by the CCF data. The reason for splitting the CCF code like this is that USB-HID has a maximum transfer size of 64 bytes.
Receiving data is as easy as calling HidDevice::read( reportSize + 1, 1000). This is great as long as your device does not generate any data unsolicited. How would you know when to call read in that case. To solve this problem you can start a new thread that reads with a timeout.
Since we cannot rip the HidDevice from underneat the thread without crashing Girder we're going to do it the nice way. We check if hidTerminated has been set to false. If so we set it to true and wait for the thread to set it to false or nil.
The code above work just fine but it uses some global variables and is scattered across a few actions. Let's put it into a nice class.