[fpc-pascal] USB Human Interface Devices

Stefan V. Pantazi svpantazi at gmail.com
Sun Aug 18 23:19:37 CEST 2019


On 8/18/19 3:58 PM, James Richters wrote:
> As far as reading it goes, things are going pretty well.. I still have yet to write to the display.. I can't get any of my attempts to send data to it to be successful at all.. I get "control transfer to usb device failed!"

Assuming there are no other bugs in the libusbxhid library, for writing 
data you have to guess the reportType (in, out, feature) and reportNum 
parameter and set the report data buffer correctly (first byte is the 
report number) for your device. Have a look at similar devices.

> 
> One thing I'm really not sure how to handle with threads is this....  ok so I have my main fast read thread going in the tightest loop possible... but now I want to write something to the display (assuming I ever figure that out and don't just put a sticker over the display and look at the screen instead :D  )  It seems I would have to stop reading to get a chance to write something..  I did a little test and I can do  a suspend(Thread_ID) and resume(Thread_ID)  but what if it's in the middle of a read.. but only got 6 of the 8 bytes when I do the suspend??  Now I am not really ready to write..... so what method can I use to do a suspend_thread_just_before_the_next_read_happens() ?  so that when the thread is suspended, the read is completed and the buffer updated.. etc.. and the USB system and libusb are all ready for me to send my write commands?  Resuming would be no problem.. because it was suspended at the correct position.. I can just resume when I am done with the write and everything should be fine.

My guess is that it would be better to leave the time sensitive read 
thread to do the fast reads and immediate calculations and leave writing 
to the device screen in a separate thread (even main thread), with a 
lower update frequency!

> 
> I also still am hoping to find a method of making the device wait for me to read it... even with threads in my program, the operating system could go off and do something that takes all the processor time for a second and I would just not know about events that happened during that time.

If an operating system were realtime that should not happen. This is why 
LinuxCNC uses the realtime extensions (http://linuxcnc.org/)

Some devices have multiple functional modes that can be selected by 
writing their appropriate settings/registers. For example, a graphic 
tablet I used before has a finger input mode (really becomes a trackpad) 
and a pen mode (uses the stylus, as usual). For more complex devices, 
guessing such things is less practical, you really need knowledge of the 
device or similar ones.


>


More information about the fpc-pascal mailing list