Re: [fpc-pascal] USB Human Interface Devices
Yes, that makes sense.. probably best not to over complicate it.
James
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Thursday, August 29, 2019 2:18 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] USB Human Interface Devices
I see your point. But since libusbhid is mostly a wrapper library, its messages
are going to be a higher level of debugging anyway - mostly related to how you
handle a particular device. So once you are confident that things are working
for your device, turning debug off completely seems the way to go, programs
will be smaller and faster (no continuous checking for debug messages are to be
displayed). If bugs or problems resurface, the underlying libusb is going to
yell at you anyway. Alternatively, you can just compile one release and one
debug version of your executable.
On Thu, Aug 29, 2019 at 1:21 PM James Richters mailto:ja...@productionautomation.net> > wrote:
Yes, and besides the errors, everything else seems to work properly. I did
notice that the one machine uses an AMD processor and all the others are Intel,
not sure what that would have to do with anything, but it is a major system
configuration difference.
Thanks for the debug level information. I will probably just shut off all
messages but it would be nice to have a way to turn them on if I need to debug
something on a remote system.
How about the libusbxhid debug messages? Since they are controlled with
{$ifdef DEBUG_MSG} you can’t really turn them on and off without re-compiling.
Could another variable be used to make libusbxhid messages optional but only if
{$ifdef DEBUG_MSG} is used? It would be helpful to be able to hide them most
of the time but show them if trying to debug without re-compiling.
James
From: fpc-pascal mailto:fpc-pascal-boun...@lists.freepascal.org> > On Behalf Of Stefan V.
Pantazi
Sent: Thursday, August 29, 2019 1:11 PM
To: FPC-Pascal users discussions mailto:fpc-pascal@lists.freepascal.org> >
Subject: Re: [fpc-pascal] USB Human Interface Devices
I would chalk this up to differences between OS versions, configurations,
devices, etc and move on. I see all memory is released. At least it does not
crash and burn badly.
The function call you want to play with is:
libusb_set_debug
http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b7a863a5a8d5b8824feb8a427a
Of course, you can set the level dynamically, from your program.
On Thu, Aug 29, 2019 at 12:34 PM James Richters mailto:ja...@productionautomation.net> > wrote:
At least I can shut off the messages with that.. but any idea what these
messages actually mean? It’s an init_device error but no one was tying to do
anything but get the list of devices from the system.
Is there a description of the verbosity level anywhere?
Is this a variable I can change during program execution without re-compiling
it? It would be helpful if I was having an issue to turn on debug info, then
turn it back off without exiting my program or needing to compile.
James
>libusb has a debug verbosity level which currently is set to 3 (i.e., very
>verbose) in the device open function.
>There is a define in libusbx.pas that you can change to shut off debug
>messages.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
<mailto:fpc-pascal@lists.freepascal.org>
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
<mailto:fpc-pascal@lists.freepascal.org>
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I see your point. But since libusbhid is mostly a wrapper library, its
messages are going to be a higher level of debugging anyway - mostly
related to how you handle a particular device. So once you are confident
that things are working for your device, turning debug off completely seems
the way to go, programs will be smaller and faster (no continuous checking
for debug messages are to be displayed). If bugs or problems resurface, the
underlying libusb is going to yell at you anyway. Alternatively, you can
just compile one release and one debug version of your executable.
On Thu, Aug 29, 2019 at 1:21 PM James Richters <
ja...@productionautomation.net> wrote:
> Yes, and besides the errors, everything else seems to work properly. I
> did notice that the one machine uses an AMD processor and all the others
> are Intel, not sure what that would have to do with anything, but it is a
> major system configuration difference.
>
>
>
> Thanks for the debug level information. I will probably just shut off all
> messages but it would be nice to have a way to turn them on if I need to
> debug something on a remote system.
>
>
>
> How about the libusbxhid debug messages? Since they are controlled with
> {$ifdef DEBUG_MSG} you can’t really turn them on and off without
> re-compiling. Could another variable be used to make libusbxhid messages
> optional but only if {$ifdef DEBUG_MSG} is used? It would be helpful to
> be able to hide them most of the time but show them if trying to debug
> without re-compiling.
>
>
>
> James
>
>
>
> *From:* fpc-pascal *On Behalf
> Of *Stefan V. Pantazi
> *Sent:* Thursday, August 29, 2019 1:11 PM
> *To:* FPC-Pascal users discussions
> *Subject:* Re: [fpc-pascal] USB Human Interface Devices
>
>
>
> I would chalk this up to differences between OS versions, configurations,
> devices, etc and move on. I see all memory is released. At least it does
> not crash and burn badly.
>
>
>
> The function call you want to play with is:
>
> libusb_set_debug
>
>
> http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b7a863a5a8d5b8824feb8a427a
>
>
>
> Of course, you can set the level dynamically, from your program.
>
>
>
>
>
>
>
> On Thu, Aug 29, 2019 at 12:34 PM James Richters <
> ja...@productionautomation.net> wrote:
>
> At least I can shut off the messages with that.. but any idea what these
> messages actually mean? It’s an init_device error but no one was tying to
> do anything but get the list of devices from the system.
>
>
>
> Is there a description of the verbosity level anywhere?
>
>
>
> Is this a variable I can change during program execution without
> re-compiling it? It would be helpful if I was having an issue to turn on
> debug info, then turn it back off without exiting my program or needing to
> compile.
>
>
>
> James
>
>
>
>
>
> >libusb has a debug verbosity level which currently is set to 3 (i.e.,
> very verbose) in the device open function.
>
> >There is a define in libusbx.pas that you can change to shut off debug
> messages.
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Yes, and besides the errors, everything else seems to work properly. I did
notice that the one machine uses an AMD processor and all the others are Intel,
not sure what that would have to do with anything, but it is a major system
configuration difference.
Thanks for the debug level information. I will probably just shut off all
messages but it would be nice to have a way to turn them on if I need to debug
something on a remote system.
How about the libusbxhid debug messages? Since they are controlled with
{$ifdef DEBUG_MSG} you can’t really turn them on and off without re-compiling.
Could another variable be used to make libusbxhid messages optional but only if
{$ifdef DEBUG_MSG} is used? It would be helpful to be able to hide them most
of the time but show them if trying to debug without re-compiling.
James
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Thursday, August 29, 2019 1:11 PM
To: FPC-Pascal users discussions
Subject: Re: [fpc-pascal] USB Human Interface Devices
I would chalk this up to differences between OS versions, configurations,
devices, etc and move on. I see all memory is released. At least it does not
crash and burn badly.
The function call you want to play with is:
libusb_set_debug
http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b7a863a5a8d5b8824feb8a427a
Of course, you can set the level dynamically, from your program.
On Thu, Aug 29, 2019 at 12:34 PM James Richters mailto:ja...@productionautomation.net> > wrote:
At least I can shut off the messages with that.. but any idea what these
messages actually mean? It’s an init_device error but no one was tying to do
anything but get the list of devices from the system.
Is there a description of the verbosity level anywhere?
Is this a variable I can change during program execution without re-compiling
it? It would be helpful if I was having an issue to turn on debug info, then
turn it back off without exiting my program or needing to compile.
James
>libusb has a debug verbosity level which currently is set to 3 (i.e., very
>verbose) in the device open function.
>There is a define in libusbx.pas that you can change to shut off debug
>messages.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
<mailto:fpc-pascal@lists.freepascal.org>
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I would chalk this up to differences between OS versions, configurations, devices, etc and move on. I see all memory is released. At least it does not crash and burn badly. The function call you want to play with is: libusb_set_debug http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b7a863a5a8d5b8824feb8a427a Of course, you can set the level dynamically, from your program. On Thu, Aug 29, 2019 at 12:34 PM James Richters < ja...@productionautomation.net> wrote: > At least I can shut off the messages with that.. but any idea what these > messages actually mean? It’s an init_device error but no one was tying to > do anything but get the list of devices from the system. > > > > Is there a description of the verbosity level anywhere? > > > > Is this a variable I can change during program execution without > re-compiling it? It would be helpful if I was having an issue to turn on > debug info, then turn it back off without exiting my program or needing to > compile. > > > > James > > > > > > >libusb has a debug verbosity level which currently is set to 3 (i.e., > very verbose) in the device open function. > > >There is a define in libusbx.pas that you can change to shut off debug > messages. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
At least I can shut off the messages with that.. but any idea what these messages actually mean? It’s an init_device error but no one was tying to do anything but get the list of devices from the system. Is there a description of the verbosity level anywhere? Is this a variable I can change during program execution without re-compiling it? It would be helpful if I was having an issue to turn on debug info, then turn it back off without exiting my program or needing to compile. James >libusb has a debug verbosity level which currently is set to 3 (i.e., very >verbose) in the device open function. >There is a define in libusbx.pas that you can change to shut off debug >messages. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Looks like email removed all my linefeeds... Here is the output with errors on just the one sytem: https://pastebin.com/axtH3hvn Here is typical output on all other sytems: https://pastebin.com/ZaJYU3ak James -Original Message- From: fpc-pascal On Behalf Of James Richters Sent: Thursday, August 29, 2019 12:03 PM To: 'FPC-Pascal users discussions' Subject: Re: [fpc-pascal] USB Human Interface Devices Now I have a new strange issue. I've been working with my sample program here: https://github.com/Zaaphod/libusbxhid/blob/WHB04B-4/whb04b.pas And it's been working just fine for me.. just some minor little tweaks and adding new functionality.. etc.. I was just about to start to merge this into my large project when I sent the sample program to my dad... on his system he just gets a screen full of errors... but on mine, it's nice and clean. I don't understand what is happening.. I reduced my test program down to the most basic sample that demonstrates the issue here: https://github.com/Zaaphod/libusbxhid/blob/System_Specific_Bug/bugtest.pas All this program does is checks to see if a specific device exists.. this program works perfectly on 4 computers and has no issue, but on one of my dad's computers I get the following errors: libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no longer connected! libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning. libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected! I don't know why Libusb is reporting this, no one tried to open anything so who cares if some devices are not connected, and how does it know they were connected at one time... this is not even an error.. if it's not connected, just ignore it, nobody cares about that device anyway. So I have two questions: 1. any idea why these errors are being generated and how to fix it? 2. Is there a way to turn off libusb errors, info and warnings? All systems are windows 10 Pro 64 bit, program was compiled for windows 64bit as well. Here is the complete output with debug info: ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
libusb has a debug verbosity level which currently is set to 3 (i.e., very verbose) in the device open function. There is a define in libusbx.pas that you can change to shut off debug messages. On Thu, Aug 29, 2019 at 12:03 PM James Richters < ja...@productionautomation.net> wrote: > Now I have a new strange issue. I've been working with my sample program > here: https://github.com/Zaaphod/libusbxhid/blob/WHB04B-4/whb04b.pas > > And it's been working just fine for me.. just some minor little tweaks and > adding new functionality.. etc.. I was just about to start to merge this > into my large project when I sent the sample program to my dad... on his > system he just gets a screen full of errors... but on mine, it's nice and > clean. I don't understand what is happening.. I reduced my test program > down to the most basic sample that demonstrates the issue here: > https://github.com/Zaaphod/libusbxhid/blob/System_Specific_Bug/bugtest.pas > > All this program does is checks to see if a specific device exists.. this > program works perfectly on 4 computers and has no issue, but on one of my > dad's computers I get the following errors: > > libusb: error [init_device] device > 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! > libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no > longer connected! > libusb: info [cache_config_descriptors] could not access configuration > descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A > device attached to the system is not functioning. > libusb: error [init_device] device > 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected! > > > I don't know why Libusb is reporting this, no one tried to open anything > so who cares if some devices are not connected, and how does it know they > were connected at one time... this is not even an error.. if it's not > connected, just ignore it, nobody cares about that device anyway. > So I have two questions: > 1. any idea why these errors are being generated and how to fix it? > 2. Is there a way to turn off libusb errors, info and warnings? > > All systems are windows 10 Pro 64 bit, program was compiled for windows > 64bit as well. > > Here is the complete output with debug info: > > K:\ProAuto>bugtest.exe > libusb: error [init_device] device > 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! > libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no > longer connected! > libusb: info [cache_config_descriptors] could not access configuration > descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A > device attached to the system is not functioning. > libusb: error [init_device] device > 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected! > Looking for $10CE, $EB93: DEBUG Found 20 devices attached > DEBUG 1038:1310, bus: 7, address: 6 > DEBUG 1002:4399, bus: 10, address: 0 > DEBUG 1B21:1142, bus: 3, address: 0 > DEBUG 046D:C31C, bus: 7, address: 3 > DEBUG 1B21:1142, bus: 1, address: 0 > DEBUG 2109:0812, bus: 1, address: 1 > DEBUG 2109:2812, bus: 7, address: 2 > DEBUG 1002:4397, bus: 6, address: 0 > DEBUG 1002:4397, bus: 5, address: 0 > DEBUG 0A12:0001, bus: 5, address: 1 > DEBUG 2109:2811, bus: 7, address: 9 > DEBUG 1002:4397, bus: 9, address: 0 > DEBUG 0C45:7403, bus: 7, address: 4 > DEBUG 1002:4396, bus: 8, address: 0 > DEBUG 1002:4396, bus: 7, address: 0 > DEBUG 0E50:0002, bus: 7, address: 7 > DEBUG 1B21:1142, bus: 2, address: 0 > DEBUG 1002:4396, bus: 4, address: 0 > DEBUG 1A40:0101, bus: 7, address: 1 > DEBUG 2109:2812, bus: 7, address: 5 > DEBUG Index of device 4302:60307=-1 > DEBUG Freeing device list with 20 devices > DEBUG USB device list freed. good boy! > FALSE > libusb: error [init_device] device > 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! > libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no > longer connected! > libusb: info [cache_config_descriptors] could not access configuration > descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A > device attached to the system is not functioning. > libusb: error [init_device] device > 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected! > Looking for $10CE, $EB93: DEBUG Found 20 devices attached > DEBUG 1038:1310, bus: 7, address: 6 > DEBUG 1002:4399, bus: 10, address: 0 > DEBUG 1B21:1142, bus: 3, address: 0 > DEBUG 046D:C31C, bus: 7, address: 3 > DEBUG 1B21:1142, bus: 1, address: 0 > DEBUG 2109:0812, bus: 1, address: 1 > DEBUG 2109:2812, bus: 7, address: 2 > DEBUG 1002:4397, bus: 6, address: 0 > DEBUG 1002:4397, bus: 5, address: 0 > DEBUG 0A12:0001, bus: 5, address: 1 > DEBUG 2109:2811, bus: 7, address: 9 > DEBUG 1002:4397, bus: 9, address: 0 > DEBUG 0C45:7403, bus: 7, address: 4 > DEBUG 1002:4396, bus: 8, address: 0 > DEBUG 1002:4396, bus: 7, address: 0 > DEBUG 0E50:0002, bus: 7, address: 7 > DEBUG 1B21:1142, bus: 2, addre
Re: [fpc-pascal] USB Human Interface Devices
I use circular buffers for another project as well, but I made my own.. and the program doesn't use threads... it's buffering data being sent to a serial port in a really complicated way with a series of loops and timers to manage to function in a single thread... I'm thinking of overhauling it to work with threads as it will greatly simplify things and probably perform better as well. It sounds like there is already circular buffer functions available in FPC? I would really like to see your code sample if you don't mind, it all sounds very useful! James -Original Message- From: fpc-pascal On Behalf Of Brian Sent: Thursday, August 29, 2019 11:57 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Yes , and it works well on Linux. I use it on a circular (ring) buffer where the main program reads data from the circular buffer and increments the read index while a totally random thread reads data from an incoming Ethernet UDP , serial port or a custom hardware port , writes to the circular buffer and increments the write index. The functions used are : procedure ResetEvent; procedure SetEvent; function WaitFor(); // one of the events in your program READ or WRITE must wait until the other event finishes. The condition for a read of the circular buffer is WriteIndex <> ReadIndex which is in the main loop (not a thread) which is continuously polled in the main loop. Hope this helps. I can send a code clip but not until next week (out of the office) , showing how it is configured. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Now I have a new strange issue. I've been working with my sample program here: https://github.com/Zaaphod/libusbxhid/blob/WHB04B-4/whb04b.pas And it's been working just fine for me.. just some minor little tweaks and adding new functionality.. etc.. I was just about to start to merge this into my large project when I sent the sample program to my dad... on his system he just gets a screen full of errors... but on mine, it's nice and clean. I don't understand what is happening.. I reduced my test program down to the most basic sample that demonstrates the issue here: https://github.com/Zaaphod/libusbxhid/blob/System_Specific_Bug/bugtest.pas All this program does is checks to see if a specific device exists.. this program works perfectly on 4 computers and has no issue, but on one of my dad's computers I get the following errors: libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no longer connected! libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning. libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected! I don't know why Libusb is reporting this, no one tried to open anything so who cares if some devices are not connected, and how does it know they were connected at one time... this is not even an error.. if it's not connected, just ignore it, nobody cares about that device anyway. So I have two questions: 1. any idea why these errors are being generated and how to fix it? 2. Is there a way to turn off libusb errors, info and warnings? All systems are windows 10 Pro 64 bit, program was compiled for windows 64bit as well. Here is the complete output with debug info: K:\ProAuto>bugtest.exe libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no longer connected! libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning. libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected! Looking for $10CE, $EB93: DEBUG Found 20 devices attached DEBUG 1038:1310, bus: 7, address: 6 DEBUG 1002:4399, bus: 10, address: 0 DEBUG 1B21:1142, bus: 3, address: 0 DEBUG 046D:C31C, bus: 7, address: 3 DEBUG 1B21:1142, bus: 1, address: 0 DEBUG 2109:0812, bus: 1, address: 1 DEBUG 2109:2812, bus: 7, address: 2 DEBUG 1002:4397, bus: 6, address: 0 DEBUG 1002:4397, bus: 5, address: 0 DEBUG 0A12:0001, bus: 5, address: 1 DEBUG 2109:2811, bus: 7, address: 9 DEBUG 1002:4397, bus: 9, address: 0 DEBUG 0C45:7403, bus: 7, address: 4 DEBUG 1002:4396, bus: 8, address: 0 DEBUG 1002:4396, bus: 7, address: 0 DEBUG 0E50:0002, bus: 7, address: 7 DEBUG 1B21:1142, bus: 2, address: 0 DEBUG 1002:4396, bus: 4, address: 0 DEBUG 1A40:0101, bus: 7, address: 1 DEBUG 2109:2812, bus: 7, address: 5 DEBUG Index of device 4302:60307=-1 DEBUG Freeing device list with 20 devices DEBUG USB device list freed. good boy! FALSE libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no longer connected! libusb: info [cache_config_descriptors] could not access configuration descriptor 0 (dummy) for 'USB\VID_2109&PID_2811\5&34472DFD&0&4': [31] A device attached to the system is not functioning. libusb: error [init_device] device 'USB\VID_1058&PID_10B8\57583631413934354E345939' is no longer connected! Looking for $10CE, $EB93: DEBUG Found 20 devices attached DEBUG 1038:1310, bus: 7, address: 6 DEBUG 1002:4399, bus: 10, address: 0 DEBUG 1B21:1142, bus: 3, address: 0 DEBUG 046D:C31C, bus: 7, address: 3 DEBUG 1B21:1142, bus: 1, address: 0 DEBUG 2109:0812, bus: 1, address: 1 DEBUG 2109:2812, bus: 7, address: 2 DEBUG 1002:4397, bus: 6, address: 0 DEBUG 1002:4397, bus: 5, address: 0 DEBUG 0A12:0001, bus: 5, address: 1 DEBUG 2109:2811, bus: 7, address: 9 DEBUG 1002:4397, bus: 9, address: 0 DEBUG 0C45:7403, bus: 7, address: 4 DEBUG 1002:4396, bus: 8, address: 0 DEBUG 1002:4396, bus: 7, address: 0 DEBUG 0E50:0002, bus: 7, address: 7 DEBUG 1B21:1142, bus: 2, address: 0 DEBUG 1002:4396, bus: 4, address: 0 DEBUG 1A40:0101, bus: 7, address: 1 DEBUG 2109:2812, bus: 7, address: 5 DEBUG Index of device 4302:60307=-1 DEBUG Freeing device list with 20 devices DEBUG USB device list freed. good boy! FALSE libusb: error [init_device] device 'USB\VID_2109&PID_2812&ASMEDIAUSBD_HUB\0830' is no longer connected! libusb: error [init_device] device 'USB\VID_1778&PID_0224\4030' is no longer connected! libusb:
Re: [fpc-pascal] USB Human Interface Devices
Yes , and it works well on Linux. I use it on a circular (ring) buffer where the main program reads data from the circular buffer and increments the read index while a totally random thread reads data from an incoming Ethernet UDP , serial port or a custom hardware port , writes to the circular buffer and increments the write index. The functions used are : procedure ResetEvent; procedure SetEvent; function WaitFor(); // one of the events in your program READ or WRITE must wait until the other event finishes. The condition for a read of the circular buffer is WriteIndex <> ReadIndex which is in the main loop (not a thread) which is continuously polled in the main loop. Hope this helps. I can send a code clip but not until next week (out of the office) , showing how it is configured. -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Thanks for the Sybcobs suggestion, I didn't know there was such a thing but it seems like a great way to prevent simultaneous data/hardware events. James -Original Message- From: fpc-pascal On Behalf Of Brian Sent: Thursday, August 29, 2019 10:50 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices A bit of clarification .. Also rather than using critical sections , use syncobs to ensure that you are not trying to /SIMULTANEOUSLY/ read and write to the same USB address or your data memory. Try using an Ethernet UDP connection to simulate the USB connection as it may illuminate an issue in your program. The Synapse UDP function works well -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
A bit of clarification .. Also rather than using critical sections , use syncobs to ensure that you are not trying to /SIMULTANEOUSLY/ read and write to the same USB address or your data memory. Try using an Ethernet UDP connection to simulate the USB connection as it may illuminate an issue in your program. The Synapse UDP function works well -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
A few general thoughts. Having been in similar situations when dealing with hardware interfaces .. the hardware is what it is .. and annoying as it is you have to work around it , as the hardware isn't going to change. It seems you have two problems 1) the USB hardware and 2) your program , in which you are not certain if it is doing something wrong .. been there many times. Sometimes it helps to make a simulator program which simulates (how you think the hardware is supposed to work) , and use that to shake out the bugs in your software. It is a lot of extra work but sometime there is no alternative. For example use a 2nd PC and an Ethernet UDP connection to test your software concept. Also rather than using critical sections , use syncobs to ensure that you are not trying to read and write to the same USB address or your data memory. https://www.freepascal.org/docs-html/current/fcl/syncobjs/teventobject.html Most guys/gals when writing interrupt handlers tend to use as simple a mechanism as possible .. from previous bad experiences. Try testing on Linux as you can run your program in graphics mode ( if that is what it does) while viewing events by writing write() messages to a terminal. This occurs if you launch your program from a terminal , then all writeln() messages go to the text terminal. -- Sent from: http://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I have a system working by just checking error codes and shutting down the thread and starting it as needed and using a few flags to know when thread is running or not. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Wednesday, August 28, 2019 5:50 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices I was wondering whether it works on Windows - I only had time to test on Linux. It looks like bad news. Error code -12 is LIBUSB_ERROR_NOT_SUPPORTED Operation not supported or unimplemented on this platform. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I have the critical section working now with init and done. Thanks for the information! For my test program I don't think I need it, but when I integrate it into the real project I will need to write to the same variables at different times, so I'll make sure to define the writes in critical sections. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Wednesday, August 28, 2019 5:46 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Yeah you are right, Windows was less forgiving. Sorry about that and thank you Jean. For simple data structures written only from one thread, using critical section may be overkill. But if your data structure is a queue or a longer buffer, with length, etc. that is being produced by one thread and consumed by another (i.e., modified by more than one thread) then you should use some form of synchronization such as a critical section. On 8/28/19 7:26 AM, James Richters wrote: > Thanks for figuring out the critical section needs to be initialized. > Stefan's example did not do this: > https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_wit > h_thread.pp > > maybe it's something you can get away with on Linux... > > I'll put in the init and done. Should I enter critical section only for > writing to shared variables, or also when reading them? > > I'm also wondering if there is some way to tell if a thread is currently > running or not... I don't want to try to start it again if it's already > running. I can make some flag that the threat sets when it starts and clears > when it exits, but I am wondering if there already something in place to > check to see if a thread exists. > > James > > > -Original Message- > From: fpc-pascal On Behalf > Of Jean SUZINEAU > Sent: Wednesday, August 28, 2019 7:04 AM > To: fpc-pascal@lists.freepascal.org > Subject: Re: [fpc-pascal] USB Human Interface Devices > > Hello, > > It seems you didn't initialized you critical section using > InitCriticalSection. > The documentation of EnterCriticalSection : > https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.h > tml > The one of InitCriticalSection: > https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.ht > ml > > At the end, you need to call DoneCriticalSection to release the associated > system resources ( > https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html). > > Note: these is related to freepascal implementation of critical > sections, in windows API, the function names are slightly different, > InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection > (https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-syncha > pi-entercriticalsection) > > > Le 28/08/2019 à 01:50, James Richters a écrit : >> One thing I wasn't able to duplicate however was the use of >> EnterCriticalsection(criticalSection); and >> LeaveCriticalsection(criticalSection); when writing to shared variables. >> If I try to ever use EnterCriticalsection(criticalSection); in the read >> thread, My program just instantly locks up and I can't even break out of it. >>If I try to use it in the main program I instantly get >> EAccessViolation: Access violation >> $7FFF18A2DF23 >> $7FFF189E9BBC >> $7FFF189E9AD0 >> $0001DCDA >> $0001D54B >> $0001218B PROCESS_USB_DATA, line 475 of WHB04B-4_test.pas >> $00012B37 SIMPLETERMINAL, line 641 of WHB04B-4_test.pas >> $00012DDD USE_MPG_DEVICE, line 675 of WHB04B-4_test.pas >> $00012F93 main, line 699 of WHB04B-4_test.pas >> $00012FE6 >> $000100011350 >> $00011980 >> $7FFF17B47E94 >> $7FFF18A4A251 >> Line 475 isEnterCriticalsection(criticalSection); >> I left where I had the criticalsection stuff in the program but commented >> out. It does seem to work fine without it though.. since the read, I am >> curious what I'm doing wrong, or if I need to do something else because I'm >> on Windows. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I was wondering whether it works on Windows - I only had time to test on
Linux. It looks like bad news. Error code -12 is
LIBUSB_ERROR_NOT_SUPPORTED
Operation not supported or unimplemented on this platform.
On 8/28/19 6:24 AM, James Richters wrote:
I tried the hotplug test on Windows with my device, but I am getting a return
code of -12 from libusb_hotplug_register_callback I put some extra writeln's
the test program:
https://github.com/Zaaphod/libusbxhid/blob/Test/libusbx_hotplug_test.pp
Here is the output:
Running "i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe "
Testing With: $10CE $EB93 0
Libusb Initialized
register done, Result:-12
Heap dump by heaptrc unit of
i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe
54 memory blocks allocated : 1913/2120
54 memory blocks freed : 1913/2120
0 unfreed memory blocks : 0
True heap size : 98304 (192 used in System startup)
True free heap : 98112
James
-Original Message-
From: fpc-pascal On Behalf Of James
Richters
Sent: Wednesday, August 28, 2019 5:03 AM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] USB Human Interface Devices
Thanks for adding the hotplug functions and the sample program. I will give
that a try.
I have come up with another solution before I saw you added the hotplug
functions:
My thinking is that the interrupt read is going to know about the missing
device before anything because it will be constantly reading as fast is it can
and my main thread will be cycling much slower, so detecting the failure of
the interrupt read would be the fastest way to know the device was not
connected anymore.
I noticed that lib_interupt_transfer produces a return code if anything
prevents the transfer from being completed. But this information is only used
for optional debug reports, and not returned from the libusbhid_interrupt_write
and libusbhid_interrupt_read functions, they only return the number of bytes
transferred. Since the number of bytes read or sent is irrelevant due to an
error, and the error codes seem to always be negative, then there is no
ambiguity if we return the error if it is negative or bytes transferred if it
is not negative. That way calls to libusbhid_interrupt_write and
libusbhid_interrupt_read can quckly get the return code and / or the number of
bytes transferred, just by checking if the result is negative or not. Since the
interrupt read is happening in a tight loop and running way faster than
anything else, it's likely that this will be the fastest way to stop the read
thread when the device is unplugged, then I can go back to looking for it in
the main program again. The first read that produces an error will stop the
thread.
I have tested this on my test branch. I get one negative return code during
normal use... and that is if I get a timeout, I get a -7, perhaps because I
asked for 8 bytes maybe? This is also useful information to have in my loop as
if I get a -7, I don't need to bother checking the data at all since it was not
read, it was just a timeout. https://github.com/Zaaphod/libusbxhid/tree/Test
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Tuesday, August 27, 2019 10:35 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
libusbhid_interrupt_read. failed! return code: -1
0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2]
The system cannot find the file specified.
But I don't really know how I can detect this and exit the process and signal
my other program that the device is no longer present. My read command:
hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
length, varies by device}, {timeout=}50);
only reports the number of bytes read, and when the device is removed, the
result of the libusbhid_interrupt_read seems to be 64. I’m wondering what the
proper way to gracefully detect the device has been disconnected is so I can
just exit out of the mode the uses the device and return to normal processing
without generating any errors.
You can try to handle the error return code by checking that a device that was
present before has actually disappeared for the libusb device list.
It also appears that in newer versions of libusb, there are provisions for
registering and unregistering a hotplug callback.
http://libusb.sourceforge.net/api-1.0/hotplug.html
It it easy to add the calls to libusbx but they need to be tested that they
actually work as expected.
Any ideas?
James
-Original Message-
From: fpc-pascal On Behalf
Of Stefan V. Pantazi
Sent: Friday, August 23, 2019 10:54 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
Thanks for pushing on this. I think any pending timeout/transfer must be
explicitl
Re: [fpc-pascal] USB Human Interface Devices
Yeah you are right, Windows was less forgiving. Sorry about that and thank you Jean. For simple data structures written only from one thread, using critical section may be overkill. But if your data structure is a queue or a longer buffer, with length, etc. that is being produced by one thread and consumed by another (i.e., modified by more than one thread) then you should use some form of synchronization such as a critical section. On 8/28/19 7:26 AM, James Richters wrote: Thanks for figuring out the critical section needs to be initialized. Stefan's example did not do this: https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp maybe it's something you can get away with on Linux... I'll put in the init and done. Should I enter critical section only for writing to shared variables, or also when reading them? I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running. I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists. James -Original Message- From: fpc-pascal On Behalf Of Jean SUZINEAU Sent: Wednesday, August 28, 2019 7:04 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hello, It seems you didn't initialized you critical section using InitCriticalSection. The documentation of EnterCriticalSection : https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.html The one of InitCriticalSection: https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.html At the end, you need to call DoneCriticalSection to release the associated system resources ( https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html). Note: these is related to freepascal implementation of critical sections, in windows API, the function names are slightly different, InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection (https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection) Le 28/08/2019 à 01:50, James Richters a écrit : One thing I wasn't able to duplicate however was the use of EnterCriticalsection(criticalSection); and LeaveCriticalsection(criticalSection); when writing to shared variables. If I try to ever use EnterCriticalsection(criticalSection); in the read thread, My program just instantly locks up and I can't even break out of it.If I try to use it in the main program I instantly get EAccessViolation: Access violation $7FFF18A2DF23 $7FFF189E9BBC $7FFF189E9AD0 $0001DCDA $0001D54B $0001218B PROCESS_USB_DATA, line 475 of WHB04B-4_test.pas $00012B37 SIMPLETERMINAL, line 641 of WHB04B-4_test.pas $00012DDD USE_MPG_DEVICE, line 675 of WHB04B-4_test.pas $00012F93 main, line 699 of WHB04B-4_test.pas $00012FE6 $000100011350 $00011980 $7FFF17B47E94 $7FFF18A4A251 Line 475 isEnterCriticalsection(criticalSection); I left where I had the criticalsection stuff in the program but commented out. It does seem to work fine without it though.. since the read, I am curious what I'm doing wrong, or if I need to do something else because I'm on Windows. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I agree with you: the libusbhid_interrupt_read and libusb_interrupt_transfer are very close semantically and returning as a result either the length of transferred data or the error code would make a lot of sense. But in rare cases one may still need to check both parameters: http://libusb.sourceforge.net/api-1.0/group__syncio.html#gac412bda21b7ecf57e4c76877d78e6486 "Also check transferred when dealing with a timeout error code. libusb may have to split your transfer into a number of chunks to satisfy underlying O/S requirements, meaning that the timeout may expire after the first few chunks have completed. libusb is careful not to lose any data that may have been transferred; do not assume that timeout conditions indicate a complete lack of I/O." At any rate, switching around and returning both: the error code as the result of libusb_interrupt_transfer and the length of data transfer as an out parameter maybe the right thing to do. That would probably make the semantics of libusbhid_interrupt_read and libusb_interrupt_transfer almost identical. On 8/28/19 5:03 AM, James Richters wrote: Thanks for adding the hotplug functions and the sample program. I will give that a try. I have come up with another solution before I saw you added the hotplug functions: My thinking is that the interrupt read is going to know about the missing device before anything because it will be constantly reading as fast is it can and my main thread will be cycling much slower, so detecting the failure of the interrupt read would be the fastest way to know the device was not connected anymore. I noticed that lib_interupt_transfer produces a return code if anything prevents the transfer from being completed. But this information is only used for optional debug reports, and not returned from the libusbhid_interrupt_write and libusbhid_interrupt_read functions, they only return the number of bytes transferred. Since the number of bytes read or sent is irrelevant due to an error, and the error codes seem to always be negative, then there is no ambiguity if we return the error if it is negative or bytes transferred if it is not negative. That way calls to libusbhid_interrupt_write and libusbhid_interrupt_read can quckly get the return code and / or the number of bytes transferred, just by checking if the result is negative or not. Since the interrupt read is happening in a tight loop and running way faster than anything else, it's likely that this will be the fastest way to stop the read thread when the device is unplugged, then I can go back to looking for it in the main program again. The first read that produces an error will stop the thread. I have tested this on my test branch. I get one negative return code during normal use... and that is if I get a timeout, I get a -7, perhaps because I asked for 8 bytes maybe? This is also useful information to have in my loop as if I get a -7, I don't need to bother checking the data at all since it was not read, it was just a timeout. https://github.com/Zaaphod/libusbxhid/tree/Test James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Thanks for the information I'm going to end the thread if the USB device is unplugged, so then I need the main program to also know the thread has ended so it can go back to occasionally checking to see if the device was plugged back in. >You can find whether your thread is running or not with the >readThread.Suspended property, >but in your program, your thread is always running, it's nether suspended. >It's just blocked in a call (to libusbhid_interrupt_read I guess) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Le 28/08/2019 à 13:26, James Richters a écrit : Thanks for figuring out the critical section needs to be initialized. Stefan's example did not do this: https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp maybe it's something you can get away with on Linux... Maybe, it seems EnterCriticalSection is defined by the current thread manager. But if your variable is uninitialized, you can have anything in it, I think EnterCriticalSection cannot do anything reliable with it. I'll put in the init and done. Should I enter critical section only for writing to shared variables, or also when reading them? You don't need to enter the Critical section to read the variable. The critical section is essentially used to prevent the case where your main thread and your read thread write two different values to the same variable at the same time. In this case without a critical section, you cannot predict the value of the variable. If the variable is always written by the same thread, you don't need the critical section. I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running. I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists. You can find whether your thread is running or not with the readThread.Suspended property, but in your program, your thread is always running, it's nether suspended. It's just blocked in a call (to libusbhid_interrupt_read I guess) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Thanks for figuring out the critical section needs to be initialized. Stefan's example did not do this: https://github.com/svpantazi/libusbxhid/blob/master/libusbhid_test_with_thread.pp maybe it's something you can get away with on Linux... I'll put in the init and done. Should I enter critical section only for writing to shared variables, or also when reading them? I'm also wondering if there is some way to tell if a thread is currently running or not... I don't want to try to start it again if it's already running. I can make some flag that the threat sets when it starts and clears when it exits, but I am wondering if there already something in place to check to see if a thread exists. James -Original Message- From: fpc-pascal On Behalf Of Jean SUZINEAU Sent: Wednesday, August 28, 2019 7:04 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hello, It seems you didn't initialized you critical section using InitCriticalSection. The documentation of EnterCriticalSection : https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.html The one of InitCriticalSection: https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.html At the end, you need to call DoneCriticalSection to release the associated system resources ( https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html). Note: these is related to freepascal implementation of critical sections, in windows API, the function names are slightly different, InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection (https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection) Le 28/08/2019 à 01:50, James Richters a écrit : > One thing I wasn't able to duplicate however was the use of > EnterCriticalsection(criticalSection); and > LeaveCriticalsection(criticalSection); when writing to shared variables. If > I try to ever use EnterCriticalsection(criticalSection); in the read thread, > My program just instantly locks up and I can't even break out of it.If I > try to use it in the main program I instantly get > EAccessViolation: Access violation >$7FFF18A2DF23 >$7FFF189E9BBC >$7FFF189E9AD0 >$0001DCDA >$0001D54B >$0001218B PROCESS_USB_DATA, line 475 of WHB04B-4_test.pas >$00012B37 SIMPLETERMINAL, line 641 of WHB04B-4_test.pas >$00012DDD USE_MPG_DEVICE, line 675 of WHB04B-4_test.pas >$00012F93 main, line 699 of WHB04B-4_test.pas >$00012FE6 >$000100011350 >$00011980 >$7FFF17B47E94 >$7FFF18A4A251 > Line 475 isEnterCriticalsection(criticalSection); > I left where I had the criticalsection stuff in the program but commented > out. It does seem to work fine without it though.. since the read, I am > curious what I'm doing wrong, or if I need to do something else because I'm > on Windows. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hello, It seems you didn't initialized you critical section using InitCriticalSection. The documentation of EnterCriticalSection : https://www.freepascal.org/docs-html/rtl/system/entercriticalsection.html The one of InitCriticalSection: https://www.freepascal.org/docs-html/rtl/system/initcriticalsection.html At the end, you need to call DoneCriticalSection to release the associated system resources ( https://www.freepascal.org/docs-html/rtl/system/donecriticalsection.html). Note: these is related to freepascal implementation of critical sections, in windows API, the function names are slightly different, InitializeCriticalSection/EnterCriticalSection/DeleteCriticalSection (https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-entercriticalsection) Le 28/08/2019 à 01:50, James Richters a écrit : One thing I wasn't able to duplicate however was the use of EnterCriticalsection(criticalSection); and LeaveCriticalsection(criticalSection); when writing to shared variables. If I try to ever use EnterCriticalsection(criticalSection); in the read thread, My program just instantly locks up and I can't even break out of it.If I try to use it in the main program I instantly get EAccessViolation: Access violation $7FFF18A2DF23 $7FFF189E9BBC $7FFF189E9AD0 $0001DCDA $0001D54B $0001218B PROCESS_USB_DATA, line 475 of WHB04B-4_test.pas $00012B37 SIMPLETERMINAL, line 641 of WHB04B-4_test.pas $00012DDD USE_MPG_DEVICE, line 675 of WHB04B-4_test.pas $00012F93 main, line 699 of WHB04B-4_test.pas $00012FE6 $000100011350 $00011980 $7FFF17B47E94 $7FFF18A4A251 Line 475 isEnterCriticalsection(criticalSection); I left where I had the criticalsection stuff in the program but commented out. It does seem to work fine without it though.. since the read, I am curious what I'm doing wrong, or if I need to do something else because I'm on Windows. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I tried the hotplug test on Windows with my device, but I am getting a return
code of -12 from libusb_hotplug_register_callback I put some extra writeln's
the test program:
https://github.com/Zaaphod/libusbxhid/blob/Test/libusbx_hotplug_test.pp
Here is the output:
Running "i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe "
Testing With: $10CE $EB93 0
Libusb Initialized
register done, Result:-12
Heap dump by heaptrc unit of
i:\programming\gcode\libusbxhid\libusbx_hotplug_test.exe
54 memory blocks allocated : 1913/2120
54 memory blocks freed : 1913/2120
0 unfreed memory blocks : 0
True heap size : 98304 (192 used in System startup)
True free heap : 98112
James
-Original Message-
From: fpc-pascal On Behalf Of James
Richters
Sent: Wednesday, August 28, 2019 5:03 AM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] USB Human Interface Devices
Thanks for adding the hotplug functions and the sample program. I will give
that a try.
I have come up with another solution before I saw you added the hotplug
functions:
My thinking is that the interrupt read is going to know about the missing
device before anything because it will be constantly reading as fast is it can
and my main thread will be cycling much slower, so detecting the failure of
the interrupt read would be the fastest way to know the device was not
connected anymore.
I noticed that lib_interupt_transfer produces a return code if anything
prevents the transfer from being completed. But this information is only used
for optional debug reports, and not returned from the libusbhid_interrupt_write
and libusbhid_interrupt_read functions, they only return the number of bytes
transferred. Since the number of bytes read or sent is irrelevant due to an
error, and the error codes seem to always be negative, then there is no
ambiguity if we return the error if it is negative or bytes transferred if it
is not negative. That way calls to libusbhid_interrupt_write and
libusbhid_interrupt_read can quckly get the return code and / or the number of
bytes transferred, just by checking if the result is negative or not. Since the
interrupt read is happening in a tight loop and running way faster than
anything else, it's likely that this will be the fastest way to stop the read
thread when the device is unplugged, then I can go back to looking for it in
the main program again. The first read that produces an error will stop the
thread.
I have tested this on my test branch. I get one negative return code during
normal use... and that is if I get a timeout, I get a -7, perhaps because I
asked for 8 bytes maybe? This is also useful information to have in my loop as
if I get a -7, I don't need to bother checking the data at all since it was not
read, it was just a timeout. https://github.com/Zaaphod/libusbxhid/tree/Test
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Tuesday, August 27, 2019 10:35 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> libusbhid_interrupt_read. failed! return code: -1
> 0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2]
> The system cannot find the file specified.
>
> But I don't really know how I can detect this and exit the process and signal
> my other program that the device is no longer present. My read command:
>
> hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
> length, varies by device}, {timeout=}50);
> only reports the number of bytes read, and when the device is removed, the
> result of the libusbhid_interrupt_read seems to be 64. I’m wondering what
> the proper way to gracefully detect the device has been disconnected is so I
> can just exit out of the mode the uses the device and return to normal
> processing without generating any errors.
You can try to handle the error return code by checking that a device that was
present before has actually disappeared for the libusb device list.
It also appears that in newer versions of libusb, there are provisions for
registering and unregistering a hotplug callback.
http://libusb.sourceforge.net/api-1.0/hotplug.html
It it easy to add the calls to libusbx but they need to be tested that they
actually work as expected.
>
> Any ideas?
>
> James
>
>
> -Original Message-
> From: fpc-pascal On Behalf
> Of Stefan V. Pantazi
> Sent: Friday, August 23, 2019 10:54 AM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Thanks for pushing on this. I think any pending timeout/transfer must be
> explicitly canceled before closing the USB device, so that the thread can end
> gracefully.
>
>
Re: [fpc-pascal] USB Human Interface Devices
Thanks for adding the hotplug functions and the sample program. I will give
that a try.
I have come up with another solution before I saw you added the hotplug
functions:
My thinking is that the interrupt read is going to know about the missing
device before anything because it will be constantly reading as fast is it can
and my main thread will be cycling much slower, so detecting the failure of
the interrupt read would be the fastest way to know the device was not
connected anymore.
I noticed that lib_interupt_transfer produces a return code if anything
prevents the transfer from being completed. But this information is only used
for optional debug reports, and not returned from the libusbhid_interrupt_write
and libusbhid_interrupt_read functions, they only return the number of bytes
transferred. Since the number of bytes read or sent is irrelevant due to an
error, and the error codes seem to always be negative, then there is no
ambiguity if we return the error if it is negative or bytes transferred if it
is not negative. That way calls to libusbhid_interrupt_write and
libusbhid_interrupt_read can quckly get the return code and / or the number of
bytes transferred, just by checking if the result is negative or not. Since the
interrupt read is happening in a tight loop and running way faster than
anything else, it's likely that this will be the fastest way to stop the read
thread when the device is unplugged, then I can go back to looking for it in
the main program again. The first read that produces an error will stop the
thread.
I have tested this on my test branch. I get one negative return code during
normal use... and that is if I get a timeout, I get a -7, perhaps because I
asked for 8 bytes maybe? This is also useful information to have in my loop as
if I get a -7, I don't need to bother checking the data at all since it was not
read, it was just a timeout. https://github.com/Zaaphod/libusbxhid/tree/Test
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Tuesday, August 27, 2019 10:35 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> libusbhid_interrupt_read. failed! return code: -1
> 0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2]
> The system cannot find the file specified.
>
> But I don't really know how I can detect this and exit the process and signal
> my other program that the device is no longer present. My read command:
>
> hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
> length, varies by device}, {timeout=}50);
> only reports the number of bytes read, and when the device is removed, the
> result of the libusbhid_interrupt_read seems to be 64. I’m wondering what
> the proper way to gracefully detect the device has been disconnected is so I
> can just exit out of the mode the uses the device and return to normal
> processing without generating any errors.
You can try to handle the error return code by checking that a device that was
present before has actually disappeared for the libusb device list.
It also appears that in newer versions of libusb, there are provisions for
registering and unregistering a hotplug callback.
http://libusb.sourceforge.net/api-1.0/hotplug.html
It it easy to add the calls to libusbx but they need to be tested that they
actually work as expected.
>
> Any ideas?
>
> James
>
>
> -Original Message-
> From: fpc-pascal On Behalf
> Of Stefan V. Pantazi
> Sent: Friday, August 23, 2019 10:54 AM
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] USB Human Interface Devices
>
> Thanks for pushing on this. I think any pending timeout/transfer must be
> explicitly canceled before closing the USB device, so that the thread can end
> gracefully.
>
> The only way I see is to use something like
>
> libusb_handle_events_timeout_completed
>
> http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760
> b41a0cf8a4a472fbd5b
>
>
> before closing the USB device context.
>
> That function is not currently part of the libusbx and has a time_t parameter
> that appears C-specific but for some reason is not included in ctypes unit.
> But I am sure Pascal equivalents can be defined. I will do some tests to
> include the libusb_handle_events_timeout_completed in libusbx and libusbhid
> and let you know.
>
>
>
> On 8/23/19 7:07 AM, James Richters wrote:
>> Stefan ,
>> Do you get the following errors when you exit your program? Is there some
>> way I should shut down the read thread so I don't get this error? I've been
>> using a timeout of 0
>>
>&
Re: [fpc-pascal] USB Human Interface Devices
libusbhid_interrupt_read. failed! return code: -1
0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2]
The system cannot find the file specified.
But I don't really know how I can detect this and exit the process and signal
my other program that the device is no longer present. My read command:
hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
length, varies by device}, {timeout=}50);
only reports the number of bytes read, and when the device is removed, the
result of the libusbhid_interrupt_read seems to be 64. I’m wondering what the
proper way to gracefully detect the device has been disconnected is so I can
just exit out of the mode the uses the device and return to normal processing
without generating any errors.
You can try to handle the error return code by checking that a device
that was present before has actually disappeared for the libusb device list.
It also appears that in newer versions of libusb, there are provisions
for registering and unregistering a hotplug callback.
http://libusb.sourceforge.net/api-1.0/hotplug.html
It it easy to add the calls to libusbx but they need to be tested that
they actually work as expected.
Any ideas?
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Friday, August 23, 2019 10:54 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
Thanks for pushing on this. I think any pending timeout/transfer must be
explicitly canceled before closing the USB device, so that the thread can end
gracefully.
The only way I see is to use something like
libusb_handle_events_timeout_completed
http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760b41a0cf8a4a472fbd5b
before closing the USB device context.
That function is not currently part of the libusbx and has a time_t parameter
that appears C-specific but for some reason is not included in ctypes unit. But
I am sure Pascal equivalents can be defined. I will do some tests to include
the libusb_handle_events_timeout_completed in libusbx and libusbhid and let you
know.
On 8/23/19 7:07 AM, James Richters wrote:
Stefan ,
Do you get the following errors when you exit your program? Is there some way
I should shut down the read thread so I don't get this error? I've been using
a timeout of 0
libusb: error [do_close] Device handle closed while transfer was still
being processed, but the device is still connected as far as we know
libusb: error [do_close] A cancellation hasn't even been scheduled on
the transfer for which the device is closing
libusb: warning [libusb_exit] some libusb_devices were leaked
Assertion failed!
Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe
File: os/poll_windows.c, Line 145
Expression: fd != NULL
Heap dump by heaptrc unit of
i:\programming\gcode\libusbxhid\whb04b-4_test.exe
50 memory blocks allocated : 1782/1968
50 memory blocks freed : 1782/1968
0 unfreed memory blocks : 0
True heap size : 131072 (160 used in System startup) True free heap :
130912 ___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
___
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
___
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I finally have this working fairly well. I used Stefan's sample program as a
guide and used classes to define my thread... and that seemed to solve the
crashing issue I was having when trying to write to the LCD from outside the
fast read thread. Here is the current version:
https://github.com/Zaaphod/libusbxhid/blob/Test/WHB04B-4_test.pas
One thing I wasn't able to duplicate however was the use of
EnterCriticalsection(criticalSection); and
LeaveCriticalsection(criticalSection); when writing to shared variables. If I
try to ever use EnterCriticalsection(criticalSection); in the read thread, My
program just instantly locks up and I can't even break out of it.If I try
to use it in the main program I instantly get
EAccessViolation: Access violation
$7FFF18A2DF23
$7FFF189E9BBC
$7FFF189E9AD0
$0001DCDA
$0001D54B
$0001218B PROCESS_USB_DATA, line 475 of WHB04B-4_test.pas
$00012B37 SIMPLETERMINAL, line 641 of WHB04B-4_test.pas
$00012DDD USE_MPG_DEVICE, line 675 of WHB04B-4_test.pas
$00012F93 main, line 699 of WHB04B-4_test.pas
$00012FE6
$000100011350
$00011980
$7FFF17B47E94
$7FFF18A4A251
Line 475 isEnterCriticalsection(criticalSection);
I left where I had the criticalsection stuff in the program but commented out.
It does seem to work fine without it though.. since the read, I am curious
what I'm doing wrong, or if I need to do something else because I'm on Windows.
Also, there are two versions of this device, once is hard wired to the USB
port, the other is wireless. They both have power buttons on them. When I
turn off the power button on the wireless version, the transceiver still
plugged into the USB port just reports that the device is turned off.. but the
hard wired version just basically unplugs it from the USB port. When this
happens, my read loop generates:
libusbhid_interrupt_read. failed! return code: -1
0libusb: error [winusbx_submit_bulk_transfer] ReadPipe/WritePipe failed: [2]
The system cannot find the file specified.
But I don't really know how I can detect this and exit the process and signal
my other program that the device is no longer present. My read command:
hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
length, varies by device}, {timeout=}50);
only reports the number of bytes read, and when the device is removed, the
result of the libusbhid_interrupt_read seems to be 64. I’m wondering what the
proper way to gracefully detect the device has been disconnected is so I can
just exit out of the mode the uses the device and return to normal processing
without generating any errors.
Any ideas?
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Friday, August 23, 2019 10:54 AM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
Thanks for pushing on this. I think any pending timeout/transfer must be
explicitly canceled before closing the USB device, so that the thread can end
gracefully.
The only way I see is to use something like
libusb_handle_events_timeout_completed
http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760b41a0cf8a4a472fbd5b
before closing the USB device context.
That function is not currently part of the libusbx and has a time_t parameter
that appears C-specific but for some reason is not included in ctypes unit. But
I am sure Pascal equivalents can be defined. I will do some tests to include
the libusb_handle_events_timeout_completed in libusbx and libusbhid and let you
know.
On 8/23/19 7:07 AM, James Richters wrote:
> Stefan ,
> Do you get the following errors when you exit your program? Is there some
> way I should shut down the read thread so I don't get this error? I've been
> using a timeout of 0
>
>
> libusb: error [do_close] Device handle closed while transfer was still
> being processed, but the device is still connected as far as we know
> libusb: error [do_close] A cancellation hasn't even been scheduled on
> the transfer for which the device is closing
> libusb: warning [libusb_exit] some libusb_devices were leaked
> Assertion failed!
>
> Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe
> File: os/poll_windows.c, Line 145
>
> Expression: fd != NULL
> Heap dump by heaptrc unit of
> i:\programming\gcode\libusbxhid\whb04b-4_test.exe
> 50 memory blocks allocated : 1782/1968
> 50 memory blocks freed : 1782/1968
> 0 unfreed memory blocks : 0
> True heap size : 131072 (160 used in System startup) True free heap :
> 130912 ___
> fpc
Re: [fpc-pascal] USB Human Interface Devices
Thanks for pushing on this. I think any pending timeout/transfer must be explicitly canceled before closing the USB device, so that the thread can end gracefully. The only way I see is to use something like libusb_handle_events_timeout_completed http://libusb.sourceforge.net/api-1.0/group__poll.html#ga43e52b912a760b41a0cf8a4a472fbd5b before closing the USB device context. That function is not currently part of the libusbx and has a time_t parameter that appears C-specific but for some reason is not included in ctypes unit. But I am sure Pascal equivalents can be defined. I will do some tests to include the libusb_handle_events_timeout_completed in libusbx and libusbhid and let you know. On 8/23/19 7:07 AM, James Richters wrote: Stefan , Do you get the following errors when you exit your program? Is there some way I should shut down the read thread so I don't get this error? I've been using a timeout of 0 libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: error [do_close] A cancellation hasn't even been scheduled on the transfer for which the device is closing libusb: warning [libusb_exit] some libusb_devices were leaked Assertion failed! Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe File: os/poll_windows.c, Line 145 Expression: fd != NULL Heap dump by heaptrc unit of i:\programming\gcode\libusbxhid\whb04b-4_test.exe 50 memory blocks allocated : 1782/1968 50 memory blocks freed : 1782/1968 0 unfreed memory blocks : 0 True heap size : 131072 (160 used in System startup) True free heap : 130912 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Stefan , Do you get the following errors when you exit your program? Is there some way I should shut down the read thread so I don't get this error? I've been using a timeout of 0 libusb: error [do_close] Device handle closed while transfer was still being processed, but the device is still connected as far as we know libusb: error [do_close] A cancellation hasn't even been scheduled on the transfer for which the device is closing libusb: warning [libusb_exit] some libusb_devices were leaked Assertion failed! Program: i:\programming\gcode\libusbxhid\whb04b-4_test.exe File: os/poll_windows.c, Line 145 Expression: fd != NULL Heap dump by heaptrc unit of i:\programming\gcode\libusbxhid\whb04b-4_test.exe 50 memory blocks allocated : 1782/1968 50 memory blocks freed : 1782/1968 0 unfreed memory blocks : 0 True heap size : 131072 (160 used in System startup) True free heap : 130912 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Yes if I set it to zero so it never times out, it never happens.. but then I have the crash when I try to write. The same thing happened if I set it to 20 seconds... but I can only find out about it if I disable the write... if I put the write in the read loop thread, then I have to have the timeout or I can never write without input. It doesn't happen for EVERY timeout.. just occasionally.. I'm pretty sure it only happens if input happens to come in coincidentally with the between the time the timeout is issued and the time the read is actually stopped. You would think the chances of the timeout happening to start just a few machine cycles before some data came in and completed the read would be unlikely.. but this seems to come quite often.I can solve the timeout error by setting the timeout to 0 and only doing reads in the read loop... but I'll have to solve the crashing when writing while waiting for a read problem to do that. I'm curious if there is a mode available where I can set it to 'always try to read data and jump to this procedure when there is some' so I don't have to keep starting and stopping a read request... kind of a request to read constantly? Where I get things set up and everytime data comes in, my read thread gets activated and my variables populated... or maybe the best solution is to find out why it's crashing when I try to write while the wait for read is happening. James >Here is something you can try immediately. How about setting the timeout on >interrupt read to some ridiculously larger value, say 20 seconds to see if the >error happens less >frequently. Of course, when you close the program you may have to wait up to >20 seconds for the read thread to finish. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I suspect when the timeout time has been reached interrupt_read is calling libusb_cancel_transfer to stop waiting for the transfer. It seems likely that what's happening is that once in a while it tries to cancel the transfer, but before libusb_cancel_transfer has a chance to cancel it, some data comes in real quick and now it's done and there is nothing to cancel.. that would explain why it happens only intermittently.. it just has to happen that some data comes in at almost the exact same time as the timeout time. Since this error is generated by:LIBUSB_ERROR_NOT_FOUND if the transfer is not in progress, already complete, or already cancelled. And nothing else could have cancelled it except the timeout, and the timeout would not have been issued if the transfer was in progress.. that leaves that the transfer popped in real quick and completed before the timeout was done calling for a cancel transfer. Here is something you can try immediately. How about setting the timeout on interrupt read to some ridiculously larger value, say 20 seconds to see if the error happens less frequently. Of course, when you close the program you may have to wait up to 20 seconds for the read thread to finish. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
>I added libusbhid_test_with_thread.pp to github. In that test you will notice >I also attempted to test sharing across threads a data structure with >(hypothetical) pen positions, using critical sections. Seems to work ok, but >more testing is needed to make sure there are no problems. Thank you, I'll have a look! >The way I see this working in your particular context, would be that the >shared data structure would be written to/updated in the read thread and read >less frequently in the main thread in order to update the display. Yes, that's the way I see it too.. data would be updated every cycle in the read thread, but only accessed by the main thread just before a display update, which would be much slower. >-5 is LIBUSB_ERROR_NOT_FOUND - this may give a clue >http://libusb.sourceforge.net/api-1.0/group__asyncio.html#ga685eb7731f9a0593f75beb99727bbe54 I only ever get that message if timeout is not 0... so it's the timeout's way of stopping things. I suspect when the timeout time has been reached interrupt_read is calling libusb_cancel_transfer to stop waiting for the transfer. It seems likely that what's happening is that once in a while it tries to cancel the transfer, but before libusb_cancel_transfer has a chance to cancel it, some data comes in real quick and now it's done and there is nothing to cancel.. that would explain why it happens only intermittently.. it just has to happen that some data comes in at almost the exact same time as the timeout time. Since this error is generated by:LIBUSB_ERROR_NOT_FOUND if the transfer is not in progress, already complete, or already cancelled. And nothing else could have cancelled it except the timeout, and the timeout would not have been issued if the transfer was in progress.. that leaves that the transfer popped in real quick and completed before the timeout was done calling for a cancel transfer. So the question is... did I end up loosing the packet? If this is what's happening... and interrupt_read timed out.. but then data came in before the timeout was complete.. does interrupt_read discard that data because it timed out so no point in doing anything with it.. or does it store the data if it comes in before LIBUSB_TRANSFER_CANCELLED is received. Perhaps Linux is faster at getting the transfer finished than windows.. maybe windows has some buffer thing going on or? But yes it could be an OS difference. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I added libusbhid_test_with_thread.pp to github. In that test you will notice I also attempted to test sharing across threads a data structure with (hypothetical) pen positions, using critical sections. Seems to work ok, but more testing is needed to make sure there are no problems. The way I see this working in your particular context, would be that the shared data structure would be written to/updated in the read thread and read less frequently in the main thread in order to update the display. On 8/22/19 11:21 AM, James Richters wrote: That sounds like exactly like what I was trying to do.. would you mind sending me your graphic tablet test? Maybe I can learn something from seeing how you do things. clear halt failed it seems to work fine.. but I always get that error.. not sure where that is coming from, or if that might be related to these other issues. That error message is fine. It is an attempt to revive an USB endpoint that has stalled, just in case. If your devices are behaving, then you may even skip that attempt in the open function call. It seems no matter what I do... even write out dummy data so I'm not even using the same variables I am reading at all.. I either get a fatal error on read, a fatal error on write, or occasional libusb: warning [handle_timeout] async cancel failed -5 errno=0 messages. -5 is LIBUSB_ERROR_NOT_FOUND - this may give a clue http://libusb.sourceforge.net/api-1.0/group__asyncio.html#ga685eb7731f9a0593f75beb99727bbe54 As to why your transfers are being canceled, I have no idea. Anyway, keep in mind that I am using Linux and a completely different USB device - so libusb implementations, OS and device differences may play a role in how the programs behave. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
That sounds like exactly like what I was trying to do.. would you mind sending
me your graphic tablet test? Maybe I can learn something from seeing how you
do things.
I just noticed I am always getting :
device attempting go clear halt on ep $81
libusb: error [winusbx_clear_halt] unable to match endpoint to an open
interface - cannot clear
clear halt failed
it seems to work fine.. but I always get that error.. not sure where that is
coming from, or if that might be related to these other issues.
Since it's working for you, I thought I would give it another try.. I made a
TEST branch on my repository here:
https://github.com/Zaaphod/libusbxhid/blob/Test/WHB04B-4_test.pas
This goes back to having the read thread do the reading, and the writing
happening in the main thread much slower. I have come up with three different
schemes for writing... all with mixed results... or maybe the same results but
they just happened to show up randomly at different times. Most of the time
it's failing on the write, but sometimes it's on there read.. and sometimes I
get non fatal warnings: libusb: warning [handle_timeout] async cancel failed
-5 errno=0. When I got done putting the details below, I tried to go back to
the configuration that seemed to work the best.. but now it is failing as
well.. I think I just have something fundamentally wrong, or maybe it's
something to do with windows? It's just not behaving the way you describe.
Here are the details:
First I tried writing the data like this:
Sleep(300);
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet1 );
Sleep(300);
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet2 );
Sleep(300);
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet3 );
the device doesn't seem to mind the delay between packets... packet 1 has 2
specific bytes that identify it as packet1..
With the timeout set to zero, if I leave it alone for a few seconds, I get
An unhandled exception occurred at $7FFF189F03C6:
EAccessViolation: Access violation
$7FFF189F03C6
.. .. ..
$00010001B1FA LIBUSBHID_SET_REPORT, line 149 of libusbhid.pas
$0001222A main, line 421 of whb04b-4_test.pas
Which is part of ALL this:
https://pastebin.com/u99f3a0p
line 421 is libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6 ,
8 , WhB04_Packet2 );
with a timeout of any sort... last test was 50, at least it doesn't have a
fatal error, but I get messages like this every once in a while:
libusb: warning [handle_timeout] async cancel failed -5 errno=0
They don't seem to hurt anything.. but I'm not sure if I am missing a read
packet or not...
So I tried writing out the data like this:
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet1 );
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet2 );
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet3 );
Sleep(1000);
With a timeout of 0 or timeout of 50 I got this:
An unhandled exception occurred at $7FFF189F03C6:
EAccessViolation: Access violation
$7FFF189F03C6
.. .. ..
$00010001B1EA LIBUSBHID_SET_REPORT, line 149 of libusbhid.pas
$0001222A main, line 421 of whb04b-4_test.pas
Which is part of all this (not as much as above but basically the same error):
https://pastebin.com/KY6X3xmR
Sleep(100);
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet1 );
Sleep(100);
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet2 );
Sleep(100);
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6
, 8 , WhB04_Packet3 );
Sleep(1000);
Now I get this:
An unhandled exception occurred at $7FFF189F4D1B:
EAccessViolation: Access violation
$7FFF189F4D1B
.. .. ..
$00010001B366 LIBUSBHID_INTERRUPT_READ, line 170 of libusbhid.pas
$000118FB READUSBPORT, line 273 of whb04b-4_test.pas
https://pastebin.com/VTqFyAiB
Line 273 is:
hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
length, varies by device}, {timeout=}50);
It seems no matter what I do... even write out dummy data so I'm not even using
the same variables I am reading at all.. I either get a fatal error on read, a
fatal error on write, or occasional libusb: warning [handle_timeout] async
cancel failed -5 errno=0 messages.
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Wednesday, August 21, 2019 10:20 PM
To: fpc-pascal@lists.
Re: [fpc-pascal] USB Human Interface Devices
On 8/21/19 6:35 PM, James Richters wrote: I had them separated, but whenever it happened that I tried to write while it was waiting to read, I would get the error below. If it was reading all the time it seemed fine.. just if it was idle waiting to read and I did a write that it would fail with EAccessViolation: Access violation That should not happen - out of curiosity I modified a graphic tablet test program and included: - a separate read thread with a timeout of 1 second and - in the main thread, one set feature report call followed by a get feature report call (every 1 second). This was the behaviour: 1) if there is no input: - the main thread keeps calling set report +get report every 1 second - in the read thread, the interrupt read times out every second but generates report data every 5 seconds (tablet generates an interrupt read even if there is no input - a sort of heartbeat); 2) if there is input (pen approaches tablet or writes on tablet) there is a flurry of data from the read thread and of course, no more interrupt read timeouts; the main thread is business as usual, setting and getting feature reports every second; see the attached debug log Note that the interrupt read report size is specific to the device (10 bytes for the tablet); is the length for your device correct? DEBUG Found 15 devices attached [...] DEBUG Found device with vid:pid 1386:222 at idx:12! DEBUG Device instance found: 1 at idx:12! [...] DEBUG Device opened. Next I must claim the interface. [...] DEBUG Claiming interface.fingers crossed... DEBUG Interface claimed ... yay! DEBUG 22:13:42:711 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:42:713 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:43:711 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:43:715 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:43:812 libusbhid_get_report. received: 2 bytes from device DEBUG 22:13:44:718 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:44:812 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:44:913 libusbhid_get_report. received: 2 bytes from device DEBUG 22:13:45:720 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:45:914 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:46:014 libusbhid_get_report. received: 2 bytes from device DEBUG 22:13:46:722 libusbhid_interrupt_read. TIMEOUT bytes read: 0 DEBUG 22:13:46:852 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:858 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:866 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:874 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:882 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:888 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:895 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:904 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:912 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:918 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:926 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:934 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:942 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:948 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:956 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:964 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:972 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:978 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:986 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:46:994 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:002 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:008 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:015 libusbhid_set_report. written: 2 bytes to device DEBUG 22:13:47:015 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:024 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:032 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:038 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:046 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:054 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:062 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:068 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:076 libusbhid_interrupt_read. received: 10 bytes from device DEBUG 22:13:47:084 libusbhid_interrupt_read. received: 10 by
Re: [fpc-pascal] USB Human Interface Devices
I had them separated, but whenever it happened that I tried to write while it was waiting to read, I would get the error below. If it was reading all the time it seemed fine.. just if it was idle waiting to read and I did a write that it would fail with EAccessViolation: Access violation I put them in the same thread but only allow writes when it's been idle for a few timeouts.. the only time I need to read the port like crazy if I spin the hand wheel really fast. I also use the slow main program to only tell the fast read thread that data is available to write at a pretty slow rate.I think this could be improved.. I just don't know how to us this locking system you mention. If I can lock it from reading when I try to write or to properly interrupt the read if it is just sitting there waiting for data that would be better. The device only answers the read request when it has something to send, so it will sit there for hours just waiting if no one gives it any input.. but I want to update the display all the time... all the time that it's turned on anyway... so that's the issue I'm facing. Whenever I try to write when the device is idle.. it blows up.. probably because I did not finish the read and lock reading. Anyway what I have now can't read and write at the same time.. I am using a timeout to stop trying to read.. and then if I get enough time outs in a row, I figure I'm not too busy reading, so I send out the write.. but if I blast it with data (turn the wheel super fast for a long time) then it never tries to write because I never time out.. so the display doesn't change.. but that's ok.. it corrects itself when I stop the crazy input. 99% of the time. The wheel will be turned slowly.. just once in a while the user might want to move a large distance with it and whirl it around really fast. I thought I saw something about sending a request to read.. then doing something else for a while and getting a call back when it's got something there.. maybe that's something like asynchronous? I think if I can figure that out it would solve the problem (maybe) of wanting to write something while I wait for input. I'm thinking if I don't use a timeout like I am now, I wouldn't get libusb: warning [handle_timeout] async cancel failed -5 errno=0 ... I wonder if that is a know issue and the reason why the timout was originally set to zero in the interrupt read function... Still all in all, I'm pretty happy with it! I do still miss like 2 pulses out of 800.. so not a super huge deal, but room for improvement... if I use the library the proper way, it will probably help. I'm wondering there is something in threads that I can set to make my fast read thread always run faster than the others.. some kind of priority or percentage?? Or do I just have to put enough delays with Sleep() commands to slow everything else down... James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Wednesday, August 21, 2019 5:31 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices From your example it looks like you placed the device reading (interrupt read) and writing (set report) into the same read thread. I thought keeping them separate was a good idea: tight loop reads and less frequent writes (LCD updates). Libusb is supposed to be thread-safe. Not really an issue for your app but if you need to make sure only one thread out of multiple threads is processing libusb events the library has asynchronous API that does offer locking functionality. On 8/21/19 3:48 PM, James Richters wrote: > Well.. It doesn’t always work just reading constantly and writing in a > different thread.. > > So I have my fast read loop always reading then my LCD write loop sending the > 3 packets every 0.3 Seconds.. and it functions ok, and I don’t miss too many > counts... but every so often I get this message: > libusb: warning [handle_timeout] async cancel failed -5 errno=0 > > I have a timeout on my read loop of 10ms. I tried setting that to 0 so it > would just wait for input in it's thread.. but when I do that I get this as > soon as I attempt to write to it: > An unhandled exception occurred at $7FFF189F03C6: > EAccessViolation: Access violation >$7FFF189F03C6 >$7FFF189EDA21 >$7FFF17AAA1A1 >$7FFF17AA9CB5 >$6B607FFB >$6B6081E7 >$6B60C695 >$6B605D6F >$6B607E40 >$00010001B1CA >$000121BF main, line 445 of whb04b-4_test.pas >$000122B6 >$0001EC20 >$00011880 >$7FFF17B47E94 >$7FFF18A4A251 > > Also if I put in a really long timeout like 1000ms I get that. Line > 445 is
Re: [fpc-pascal] USB Human Interface Devices
From your example it looks like you placed the device reading (interrupt read) and writing (set report) into the same read thread. I thought keeping them separate was a good idea: tight loop reads and less frequent writes (LCD updates). Libusb is supposed to be thread-safe. Not really an issue for your app but if you need to make sure only one thread out of multiple threads is processing libusb events the library has asynchronous API that does offer locking functionality. On 8/21/19 3:48 PM, James Richters wrote: Well.. It doesn’t always work just reading constantly and writing in a different thread.. So I have my fast read loop always reading then my LCD write loop sending the 3 packets every 0.3 Seconds.. and it functions ok, and I don’t miss too many counts... but every so often I get this message: libusb: warning [handle_timeout] async cancel failed -5 errno=0 I have a timeout on my read loop of 10ms. I tried setting that to 0 so it would just wait for input in it's thread.. but when I do that I get this as soon as I attempt to write to it: An unhandled exception occurred at $7FFF189F03C6: EAccessViolation: Access violation $7FFF189F03C6 $7FFF189EDA21 $7FFF17AAA1A1 $7FFF17AA9CB5 $6B607FFB $6B6081E7 $6B60C695 $6B605D6F $6B607E40 $00010001B1CA $000121BF main, line 445 of whb04b-4_test.pas $000122B6 $0001EC20 $00011880 $7FFF17B47E94 $7FFF18A4A251 Also if I put in a really long timeout like 1000ms I get that. Line 445 is libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6 , 8 , WhB04_Packet1 ); so I can't write while I'm reading or waiting for a read after all. So I came up with a scheme to set all the variables in the slow loop then set a Boolean variable when it's done.. then the fast loop checks for the flag if it is idle for a time, meaning it's not trying to keep up with input.. and that does work.. and I don't miss many counts... but it does miss a few... but I STILL get this libusb: warning [handle_timeout] async cancel failed -5 errno=0 even though as far as I can tell, I can't possible be reading and writing at the same time. I've updated my test project here: https://github.com/Zaaphod/libusbxhid/blob/master/WHB04B-4_test.pas I don't really know what libusb: warning [handle_timeout] async cancel failed -5 errno=0 is trying to tell me... it is having an issue canceling waiting for data after the time out I guess.. but why is that a problem? Any Ideas? James -Original Message- From: fpc-pascal On Behalf Of James Richters Sent: Wednesday, August 21, 2019 8:30 AM To: 'FPC-Pascal users discussions' Subject: Re: [fpc-pascal] USB Human Interface Devices I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to libusb-win32... After I gave up on Python, I went back to FPC and just ran my existing sample program, and I noticed where it used have an error sending to device, it now said 8 bytes sent!! It's very strange I could read it just fine but not write to it without messing with the driver... but it's working now! I tried suspending the read thread to write to it.. and well it must have ended up suspending in the middle of a read because the whole thing locked up.. so I just tried as suggested and let it keep reading in a tight loop in it's own thread and then just throw in a write every few seconds on the main program.. and that actually worked fine.. I guess libusb takes care of worry about finishing a read before writing.. I think I did see libusb had something to do with threads. So now it's just a matter of small details. The display is a little odd... in that instead of sending it just a real number, you send it an integer for the numbers before the decimal and another integer for the numbers after the decimal.. but it's 2 bytes for each (4 bytes total) but they are in reverse order.. I need to send LowByte_Integer, High_Byte_Integer, LowByte_decimal, High_Byte_decimal so the bits from a 16 bit integer end up being 76543210,FEDCBA98 I think this is that edian byte order thing that was mentioned. I'm just curious if there is already a function available to reverse these like this.. or if I just need to write my own. It's just some rotates and then split it, so I can do that, but I'm just wondering if there is something already there to do this.. I seem to recall that this kind of thing needs to happen quite a bit. Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ;
Re: [fpc-pascal] USB Human Interface Devices
Hmm I'll see what I can come up with. The language of all these units is completely foreign to me. I really don't understand how constructors and this inherited stuff or how even the functions and procedures manage to get anything done. I've been programming with Pascal since Turbo Pascal back in the 80's but I can't make any sense of this coding style at all. I'll have to do some research to see how this method of programing even works at all. I've done some stuff that uses units like this, so I can create and object and manage to use it, but the unit's themselves... well. I just don't get it. I keep going around in circles trying to follow the way things get done and it seems like I go round and round and never find any functions or procedures that really do anything at all.. they just keep calling each other. I was trying to just compile Snapi.pas with libusboop just to figure out the syntax.. then I can copy sections and modify it as needed. James >Hmm, no. You should make your own unit for your device, from scratch. >And then use snapi.pas as a guide how to do that. As I've written in my >previous EMail: ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Montag, den 19.08.2019, 18:22 -0400 schrieb James Richters: > Oh, for some reason I wasn't thinking I was replacing mydevice.pas > with snapi.pas... Ok.. so if > I understand this correctly, make the changes necessary in snapi.pas > to use libusboop.pas instead of the old usb.pas, and then use > TSNAPIDevice.Create to create a TLIBUSBPseudoHIDInterface to my > device? ... and that will allow me a more generic method to access > the device? Hmm, no. You should make your own unit for your device, from scratch. And then use snapi.pas as a guide how to do that. As I've written in my previous EMail: --- schnipp --- You really should create your own class descending from TLibUsbDevice (instead of TLibUsbDeviceWithFirmware). In your constructor, you have to get a reference to the HID interface of your device, e.g., by TLibUsbPseudoHIDInterface.Create(...) analogous to https://github.com/Zaaphod/pas-libusb/blob/Hack/src/examples/mydevice.pas#L141 . This internally also gets references to the necessary endpoints, therefore you most probably don't need manual FInterface.FindEndpoint() (like TMyDevice). --- schnapp --- But please pay attention to the new methods, parameters, ... Bye Hansi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Thanks for the suggestion! James >Move(LCD_Array[0..6],Device_Array[1],7) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Well.. It doesn’t always work just reading constantly and writing in a different thread.. So I have my fast read loop always reading then my LCD write loop sending the 3 packets every 0.3 Seconds.. and it functions ok, and I don’t miss too many counts... but every so often I get this message: libusb: warning [handle_timeout] async cancel failed -5 errno=0 I have a timeout on my read loop of 10ms. I tried setting that to 0 so it would just wait for input in it's thread.. but when I do that I get this as soon as I attempt to write to it: An unhandled exception occurred at $7FFF189F03C6: EAccessViolation: Access violation $7FFF189F03C6 $7FFF189EDA21 $7FFF17AAA1A1 $7FFF17AA9CB5 $6B607FFB $6B6081E7 $6B60C695 $6B605D6F $6B607E40 $00010001B1CA $000121BF main, line 445 of whb04b-4_test.pas $000122B6 $0001EC20 $00011880 $7FFF17B47E94 $7FFF18A4A251 Also if I put in a really long timeout like 1000ms I get that. Line 445 is libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6 , 8 , WhB04_Packet1 ); so I can't write while I'm reading or waiting for a read after all. So I came up with a scheme to set all the variables in the slow loop then set a Boolean variable when it's done.. then the fast loop checks for the flag if it is idle for a time, meaning it's not trying to keep up with input.. and that does work.. and I don't miss many counts... but it does miss a few... but I STILL get this libusb: warning [handle_timeout] async cancel failed -5 errno=0 even though as far as I can tell, I can't possible be reading and writing at the same time. I've updated my test project here: https://github.com/Zaaphod/libusbxhid/blob/master/WHB04B-4_test.pas I don't really know what libusb: warning [handle_timeout] async cancel failed -5 errno=0 is trying to tell me... it is having an issue canceling waiting for data after the time out I guess.. but why is that a problem? Any Ideas? James -Original Message- From: fpc-pascal On Behalf Of James Richters Sent: Wednesday, August 21, 2019 8:30 AM To: 'FPC-Pascal users discussions' Subject: Re: [fpc-pascal] USB Human Interface Devices I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to libusb-win32... After I gave up on Python, I went back to FPC and just ran my existing sample program, and I noticed where it used have an error sending to device, it now said 8 bytes sent!! It's very strange I could read it just fine but not write to it without messing with the driver... but it's working now! I tried suspending the read thread to write to it.. and well it must have ended up suspending in the middle of a read because the whole thing locked up.. so I just tried as suggested and let it keep reading in a tight loop in it's own thread and then just throw in a write every few seconds on the main program.. and that actually worked fine.. I guess libusb takes care of worry about finishing a read before writing.. I think I did see libusb had something to do with threads. So now it's just a matter of small details. The display is a little odd... in that instead of sending it just a real number, you send it an integer for the numbers before the decimal and another integer for the numbers after the decimal.. but it's 2 bytes for each (4 bytes total) but they are in reverse order.. I need to send LowByte_Integer, High_Byte_Integer, LowByte_decimal, High_Byte_decimal so the bits from a 16 bit integer end up being 76543210,FEDCBA98 I think this is that edian byte order thing that was mentioned. I'm just curious if there is already a function available to reverse these like this.. or if I just need to write my own. It's just some rotates and then split it, so I can do that, but I'm just wondering if there is something already there to do this.. I seem to recall that this kind of thing needs to happen quite a bit. Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ; Ah.. but that doesn't work.. is there a way to do this with syntax or do I just need to make a loop to copy the array elements the way they need to be? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
On 8/21/19 8:30 AM, James Richters wrote: I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to Persistence pays off. Congrats! Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ; Try Move (https://www.freepascal.org/docs-html/rtl/system/move.html) Move(LCD_Array[0..6],Device_Array[1],7) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I FINALLY wrote some data to the LCD!! YAY !!! I was trying to get the python application to work.. without any luck.. but I ended up going ahead and trying Zadig changing the driver to libusb-win32... After I gave up on Python, I went back to FPC and just ran my existing sample program, and I noticed where it used have an error sending to device, it now said 8 bytes sent!! It's very strange I could read it just fine but not write to it without messing with the driver... but it's working now! I tried suspending the read thread to write to it.. and well it must have ended up suspending in the middle of a read because the whole thing locked up.. so I just tried as suggested and let it keep reading in a tight loop in it's own thread and then just throw in a write every few seconds on the main program.. and that actually worked fine.. I guess libusb takes care of worry about finishing a read before writing.. I think I did see libusb had something to do with threads. So now it's just a matter of small details. The display is a little odd... in that instead of sending it just a real number, you send it an integer for the numbers before the decimal and another integer for the numbers after the decimal.. but it's 2 bytes for each (4 bytes total) but they are in reverse order.. I need to send LowByte_Integer, High_Byte_Integer, LowByte_decimal, High_Byte_decimal so the bits from a 16 bit integer end up being 76543210,FEDCBA98 I think this is that edian byte order thing that was mentioned. I'm just curious if there is already a function available to reverse these like this.. or if I just need to write my own. It's just some rotates and then split it, so I can do that, but I'm just wondering if there is something already there to do this.. I seem to recall that this kind of thing needs to happen quite a bit. Also I need to stick a $06 in front of all my packets to send to the device. I have my data all in arrays, so I want to do something like this Device_Array[0]:=$06; Device_Array[1..7] := LCD_Array[0..6] ; Ah.. but that doesn't work.. is there a way to do this with syntax or do I just need to make a loop to copy the array elements the way they need to be? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I'm trying to get this to work with libusboop.pas but I'm getting a compiler
error I don't really know how to fix:
157 Constructor TSNAPIDevice.Create(idVendor, idProduct: LongInt; AConfig,
AInterface, AAltInterface: LongInt);
158 Var Intf : Plibusb_interface_descriptor;
159 Begin
160inherited Create(idVendor,idProduct,AConfig);
161{ create USB interface }
162Intf := TLibUsbDevice.FindInterface(AInterface,AAltInterface,FDevice); {
better: search for iInterface = "SNAPI Command Interface" }
163FSNAPICommandInterface := TLIBUSBPseudoHIDInterface.Create(Self,Intf);
164FSNAPICommandInterface.OnIntrReport := @IntrReport;
165 End;
First compilation of i:\programming\pas-libusb_test_dll\src\examples\snapi.pas
snapi.pas(160,28) Error: Incompatible type for arg no. 1: Got "LongInt",
expected "TLibUsbContext"
snapi.pas(162,72) Error: Wrong number of parameters specified for call to
"FindInterface"
libusboop.pas(911,24) Error: Found declaration:
FindInterface(TLibUsbInterfaceMatchMethod):^libusb_interface_descriptor;
libusboop.pas(943,24) Error: Found declaration:
FindInterface(TLibUsbInterfaceMatchClass;Boolean=`TRUE`):^libusb_interface_descriptor;
libusboop.pas(958,24) Error: Found declaration:
FindInterface(TLibUsbInterfaceMatchFunc;Pointer):^libusb_interface_descriptor;
libusboop.pas(981,24) Error: Found declaration:
FindInterface(Byte;Byte):^libusb_interface_descriptor;
libusboop.pas(991,24) Error: Found declaration:
FindInterface:^libusb_interface_descriptor;
snapi.pas(432) Fatal: There were 7 errors compiling module, stopping
snapi.pas(0) Fatal: Compilation aborted
I've put my attempt on my repository in the TEST branch here:
https://github.com/Zaaphod/pas-libusb/blob/Test/src/examples/snapi.pas
I don't really understand how this inherited stuff and constructors and all
that works.. but I figure if I get snapi.pas to compile correctly with
libusboop.pas then I will have an example of how to create the
TLIBUSBPseudoHIDInterface for my device... but maybe I need to do it completely
differently than this?Sorry I'm so confused.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Oh, for some reason I wasn't thinking I was replacing mydevice.pas with snapi.pas... Ok.. so if I understand this correctly, make the changes necessary in snapi.pas to use libusboop.pas instead of the old usb.pas, and then use TSNAPIDevice.Create to create a TLIBUSBPseudoHIDInterface to my device? ... and that will allow me a more generic method to access the device? James >Please see snapi.pas, which I've sent you on 2019-08-10. This does exactly >that. I've sent this file specifically that you use it instead of mydevice.pas. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Sonntag, den 18.08.2019, 10:43 -0400 schrieb James Richters: > I just pushed it. Sorry for the delayed reply. After comparing the exception stack trace you've sent (see below) and your code, the access violation happens at https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusboop.pas#L1330 . The code dereferences the parameter AEndpoint. Most probably it is however Nil, because the preceding FInterface.FindEndpoint(EP_IN) in https://github.com/Zaaphod/pas-libusb/blob/Hack/src/examples/mydevice.pas#L143 didn't find that endpoint. As I've written, TMyDevice is NOT a generic device! It is specific for EZ-USB chips. You really should create your own class descending from TLibUsbDevice (instead of TLibUsbDeviceWithFirmware). In your constructor, you have to get a reference to the HID interface of your device, e.g., by TLibUsbPseudoHIDInterface.Create(...) analogous to https://github.com/Zaaphod/pas-libusb/blob/Hack/src/examples/mydevice.pas#L141 . This internally also gets references to the necessary endpoints, therefore you most probably don't need manual FInterface.FindEndpoint() (like TMyDevice). Please see snapi.pas, which I've sent you on 2019-08-10. This does exactly that. I've sent this file specifically that you use it instead of mydevice.pas. Bye Hansi > > Could you please "git push" the source code to Github so that the > > line numbers match the output? At least in line 1330 of > > libusboop.pas there is no Create. Please ensure that the > > version on Github is the very same version where you executed the > > program and got the line numbers. > > Thanks > Hansi > > > Running "i:\programming\pas- > > libusb_test_dll\src\examples\testopendevic_vidpid2.exe " > > start > > 1 > > 2 > > a05472131 > > a10CEEB93 > > b > > c > > FALSE 8086 10CE A36D EB93 > > FALSE 8087 10CE 0AAA EB93 > > FALSE 0424 10CE 2734 EB93 > > FALSE 1D50 10CE 6015 EB93 > > FALSE 1B1C 10CE 0C15 EB93 > > TRUE 10CE 10CE EB93 EB93 > > FALSE 05E3 10CE 0610 EB93 > > FALSE 04E8 10CE 61F5 EB93 > > FALSE 1B1C 10CE 0C10 EB93 > > FALSE 0424 10CE 274C EB93 > > FALSE 047D 10CE 1020 EB93 > > FALSE 1B1C 10CE 1B4F EB93 > > FALSE 1A40 10CE 0101 EB93 > > FALSE 0C45 10CE 7403 EB93 > > FALSE 10C4 10CE EA60 EB93 > > d > > e > > N > > P > > L > > H1 > > I > > I2 > > Q > > R > > K > > M > > O1 > > An unhandled exception occurred at $00010002D0BB: > > EAccessViolation: Access violation > > $00010002D0BB CREATE, line 1330 of libusboop.pas > > $00010002B3AB > > $00011942 main, line 75 of ../../pas- > > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > > $00011AF6 main, line 96 of ../../pas- > > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > > $000100010040 > > $000117F0 > > $7FFB66D07E94 > > $7FFB675FA251 > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
On 8/19/19 4:24 AM, James Richters wrote: I've been reading about libusb here: https://www.cs.unm.edu/~hjelmn/libusb_hotplug_api/group__syncio.html some things I just don't really understand, I'm hoping someone can explain: The wValue, wIndex and wLength fields values should be given in host-endian byte order. What does host-endian byte order mean?? if your machine is little endian, then you set those values in little endian... if your machine is big endian, then you use that... intel/amd PC systems are generally little endian... https://en.wikipedia.org/wiki/Endianness -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
On Mon, 2019-08-19 at 04:24 -0400, James Richters wrote: > I've been reading about libusb here: > https://www.cs.unm.edu/~hjelmn/libusb_hotplug_api/group__syncio.html > > some things I just don't really understand, I'm hoping someone can explain: I can't help with the details, but these sites are very informative, especially the first one is nicely readable, the other has lots of details: http://www.usbmadesimple.co.uk/index.html https://www.beyondlogic.org/usbnutshell/usb1.shtml > The wValue, wIndex and wLength fields values should be given in host-endian > byte order. > What does host-endian byte order mean?? > > wLength > the length field for the setup packet. The data buffer should be at least > this size. > > What is this length supposed to be? I've been using the length of the data > I'm trying to send... so trying to send 8 bytes, I made it 8... but maybe > it's wanting some other length? > > It seems to me that there would be little point in asking for this value if > it was always just the length of the data field because the function could > just get len(data) on it's own, so why bother passing something so obvious > as a parameter... this leads me to wonder if this length needs to be > something else? > > James > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I've been reading about libusb here: https://www.cs.unm.edu/~hjelmn/libusb_hotplug_api/group__syncio.html some things I just don't really understand, I'm hoping someone can explain: The wValue, wIndex and wLength fields values should be given in host-endian byte order. What does host-endian byte order mean?? wLength the length field for the setup packet. The data buffer should be at least this size. What is this length supposed to be? I've been using the length of the data I'm trying to send... so trying to send 8 bytes, I made it 8... but maybe it's wanting some other length? It seems to me that there would be little point in asking for this value if it was always just the length of the data field because the function could just get len(data) on it's own, so why bother passing something so obvious as a parameter... this leads me to wonder if this length needs to be something else? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Yes, I did see that... it happens that before I found that page I had it on one of the axis anyway because if you switch it to off the handwheel gets disabled. I'm not sure why I am getting an IO error trying to send data to the device.. I'm not sure if it's Windows, or FPC, or the method I am trying to use.. etc.. I also don't have a lot of devices that even have a way to output anything to them... most are input devices. So I bought some usb-relays... those seem to have more documentation available, maybe I'll learn something when those come in. One thing that just confuses me is the first byte of data being sent as the report number.. I'm not sure I'm understanding that correctly, but it seems to be the only way it will work at all. James >Oh, it's chinese - forget about getting any information. >Did you read there >https://github.com/rubienr/machinekit/tree/feature-xhc-whb04b-6/src/hal/user_comps/xhc-whb04b-6#findings >that the axis dial has to be switched on for the display to be updated? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
On Mon, 2019-08-19 at 03:11 +0200, Marc Santhoff wrote: > Hi James, > > are you really sure the WHB04B-6 is exactly the same as your WHB04B-4 viewn to > the USB API? > > If those thingys come with a dll, maybe you can compare the header files? > If there is no header file you could ask the manufacturer for it. If they made > a programm using that dll, there must be a header file. Oh, it's chinese - forget about getting any information. Did you read there https://github.com/rubienr/machinekit/tree/feature-xhc-whb04b-6/src/hal/user_comps/xhc-whb04b-6#findings that the axis dial has to be switched on for the display to be updated? > HTH somehow... > > -- > Marc Santhoff > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- Marc Santhoff -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
My concern was that I could not read and write at the exact same time -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Sunday, August 18, 2019 9:32 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices >> 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! > > Yes, that was what I was attempting to describe.. but I can't write to the > usb device if the read thread happens to be in the middle of a read... so how > do I pause the read thread at the correct time so it's not partially in the > middle of reading a packet, and I can't read again until I'm done writing. I > figure I can just check for some period of time of idle handwheel input > before I stop the read thread and do the write then start the read thread > again, because only the handwheel produces such a large stream of data.. but > still I’m not sure how to make sure I stop it at the correct time. I do not get why should you stop the read thread, when that is the actual advantage of having multiple threads. While the read thread is busily reading input in a buffer/queue/what have you, you are free within limits) to do whatever you need to do (e.g., output to LCD display, do calculations) in the other threads, including the main thread, after which, you can get back to consuming and processing the (hopefully only slightly larger now) data from the read thread buffer/queue. After you figured writing to the LCD screen you could try writing random data to it while reading and processing handwheel and button input *at the same time*. Hope this makes sense. ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
They come with a little CD, but not much really useful on them.. mostly instructions on how to get them to work with Mach3. But the manual does cover both models. The only difference is one has a selection switch for 4 axis and the other has one for 6 axis, but the 4 axis version shows 6 axis on the LCD so I think everything else is identical even the firmware. The manual does have a dll on it called ShuttlePro.dll I have no idea what to do with that... they don't include any program at all, just instructions for mach3. The documentation is very poor and there is no support at all on how to access it.. I'm just going on what everyone else has kind of figured out plus what I could figure out from just pushing the buttons on it. There's a readme in the same folder as ShuttlePro.dll: ShuttlePro.dll is the Driver of HB04BX for MACH3 cnc control system. You could externd the IO input with our wireless handle.To do reset,start,stop etc. The handle is just like ShuttlePRO,you coul do jog mpg and step with the handle. In all,you could control much things if you had our wireless HB04Bx. installation: first you must install mach3 and then insert HB04Bx handle usb controller.then install the batteries to HB04Bx handle's cell box. 1.You should copy the ShuttlePro.dll to Mach3\plugins\ directroy; 2.M930.m1s is the probez file.You should copy the it to Mach3\macros\Mach3Mill directroy; 3.M990.m1s is the ref all home file.You should copy the it to Mach3\macros\Mach3Mill directroy; 4.m933 is go to zero work macro,You should copy the it to Mach3\macros\Mach3Mill directroy; 5.you could change the macro file M930.m1s ,M990.m1s, m933 to satisfy your cnc system; It seems to indicate the designation after the B is not important to the operation.. W is for wireless and they are HB04Bx (either -4 or -6 as far as I know.. maybe there is a -3 as well) I have no idea what the DLL could possibly be for though James -Original Message- From: fpc-pascal On Behalf Of Marc Santhoff Sent: Sunday, August 18, 2019 9:12 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hi James, are you really sure the WHB04B-6 is exactly the same as your WHB04B-4 viewn to the USB API? If those thingys come with a dll, maybe you can compare the header files? If there is no header file you could ask the manufacturer for it. If they made a programm using that dll, there must be a header file. HTH somehow... -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
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! Yes, that was what I was attempting to describe.. but I can't write to the usb device if the read thread happens to be in the middle of a read... so how do I pause the read thread at the correct time so it's not partially in the middle of reading a packet, and I can't read again until I'm done writing. I figure I can just check for some period of time of idle handwheel input before I stop the read thread and do the write then start the read thread again, because only the handwheel produces such a large stream of data.. but still I’m not sure how to make sure I stop it at the correct time. I do not get why should you stop the read thread, when that is the actual advantage of having multiple threads. While the read thread is busily reading input in a buffer/queue/what have you, you are free within limits) to do whatever you need to do (e.g., output to LCD display, do calculations) in the other threads, including the main thread, after which, you can get back to consuming and processing the (hopefully only slightly larger now) data from the read thread buffer/queue. After you figured writing to the LCD screen you could try writing random data to it while reading and processing handwheel and button input *at the same time*. Hope this makes sense. ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi James, are you really sure the WHB04B-6 is exactly the same as your WHB04B-4 viewn to the USB API? If those thingys come with a dll, maybe you can compare the header files? If there is no header file you could ask the manufacturer for it. If they made a programm using that dll, there must be a header file. HTH somehow... -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
>>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.
I don't know if there is a bug or not... but I "Think" I have the information I
need. I found this device documented here:
https://github.com/rubienr/machinekit/tree/feature-xhc-whb04b-6/src/hal/user_comps/xhc-whb04b-6
it states: "Data transmitted is packed as 7 bytes plus a constant leading byte
0x06 which is the report ID. The data exclusive report ID reads as follows:"
this matches the python code I was trying to duplicate... so I send a $06 then
7 bytes of data at a time. It also describes the data structure as well.
The C code at
https://github.com/rubienr/machinekit/blob/feature-xhc-whb04b-6/src/hal/user_comps/xhc-whb04b-6/usb.cc
Uses libusb... here is the relevant section: It's in C but it's commented
pretty well.. and describes the exact parameters passed to
libusb_control_transfer
void Usb::sendDisplayData()
{
outputPackageBuffer.asBlocks.init(&outputPackageData);
if (mIsSimulationMode)
{
*verboseTxOut << "out 0x" << outputPackageBuffer.asBlocks << endl <<
std::dec << "out size " <<
sizeof(outputPackageBuffer.asBlockArray) << "B " << outputPackageData
<< endl;
}
for (size_t idx = 0; idx < (sizeof(outputPackageBuffer.asBlockArray) /
sizeof(UsbOutPackageBlockFields)); idx++)
{
UsbOutPackageBlock& block = outputPackageBuffer.asBlockArray[idx];
size_t blockSize = sizeof(UsbOutPackageBlock);
// see also
// http://www.beyondlogic.org/usbnutshell/usb6.shtml
// http://libusb.sourceforge.net/api-1.0/group__desc.html
// http://libusb.sourceforge.net/api-1.0/group__misc.html
intr = libusb_control_transfer(deviceHandle,
// send to hid descriptor: bmRequestType == LIBUSB_DT_HID == 0x21
== (interface | endpoint)
LIBUSB_DT_HID,
// bRequest == LIBUSB_REQUEST_SET_CONFIGURATION == 0x09 == set
configuration
LIBUSB_REQUEST_SET_CONFIGURATION,
// wValue: if bRequest == LIBUSB_REQUEST_SET_CONFIGURATION the
configuration value
0x0306,
// wIndex, device interface number
0x00,
// data to transmit
block.asBuffer.asBytes,
// wLength, data length
blockSize,
// transfer timeout[ms]
0);
if (r < 0)
{
std::cerr << "transmission failed, try to reconnect ..." << endl;
setDoReconnect(true);
return;
}
}
}
So I tried with libusbxhid:
libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, $6 , 8 ,
WhB04_Packet )
and I get control transfer to usb device failed!
so inside function libusbhid_set_report, I put a bunch of writelns to show what
is being passed to libusb_control_transfer:
Writeln('device handle =');
Writeln('bmRequestType = $', inttohex(LIBUSB_CONTROL_REQUEST_TYPE_OUT,4));
Writeln('bRequest = $', inttohex(HID_SET_REPORT,4) );
Writeln('wValue= $', inttohex((reportType << 8) or reportNum,4) );
Writeln('wIndex= $', 0 );
Writeln('data = ', '$'+Inttohex(report_data[0],2),'
$'+Inttohex(report_data[1],2),' $'+Inttohex(report_data[2],2),'
$'+Inttohex(report_data[3],2),' $'+Inttohex(report_data[4],2),'
$'+Inttohex(report_data[5],2),
' $'+Inttohex(report_data[6],2),'
$'+Inttohex(report_data[7],2));
Writeln('wLength = $', Inttohex(reportLen,2) );
Writeln('timeout = $', 0 );
Result:=libusb_control_transfer(hid_device_context.usb_device_handle,LIBUSB_CONTROL_REQUEST_TYPE_OUT{},HID_SET_REPORT,(reportType
<< 8) or reportNum, 0{interface_num}, @report_data,
reportLen{sizeof(data)},0{no timeout});
Suspend
06 FD FE FF 01 02 03 04
device handle =
bmRequestType = $0021
bRequest = $0009
wValue= $0306
wIndex= $0
data = $06 $FD $FE $FF $01 $02 $03 $04
wLength = $08
timeout = $0
control transfer to usb device failed!
-1
It shows I'm getting the same values for everything but yet it's still
failing. I have this attempt on my fork at
https://github.com/Zaaphod/libusbxhid
I'm not sure it's libusbxhid though.. because I also can't get it to work with
pas-libusb I can run test3controlasync.pas with my device and it
Re: [fpc-pascal] USB Human Interface Devices
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. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
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!" Thanks for the advice on a thread safe queue! For the moment I've been trying to do the math inside thread reading the usb device... it's pretty simple, and that allows me to read the totals at any time.. but I can see what you mean that if I just read the device and dump everything into maybe some kind of ring buffer without bothering to try to process it at all, and increment the buffer position then it could be ready to read again even faster. I could have my other slow process crunch the buffer. I have two of these devices, one is wireless, the other has a USB cable attached to it.. they both work a little differently.. the wireless one only responds to my interrupt read when some data has been generated... the wired version always responds to my request whether any data has been generated or not. For that one I would have to do a compare on the data to see if anything changed before adding to the buffer otherwise the buffer would always be overrun. Still I can't image my math is taking very long.. here is what I am doing: Read device If wheel moved then add wheel counts to appropriate variable then read device Else Update other variables if they changed then read device So when the wheel is moving I have very few instructions between reads.. I don't bother checking for buttons or anything else.. I just keep accumulating the total, and that's all I care about, and then I read again.. I only bother with the buttons if the wheel didn't move. 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. 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. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Sunday, August 18, 2019 3:12 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices James, From the looks of it you made good progress reading the hardware and using a dedicated thread for it. Congrats! Seems you're in the thick of it now ready to get the minute details sorted out. Anyway, just a heads up that concurrent programming (threads, synchronization, etc) has many pitfalls. My armchair guess is that your program is just not reading fast enough to keep up with the rate of data that the hardware is generated. Having time sensitive code in a separate thread is a good idea but you should also store the report data in an adequately sized and thread safe data structure such as a thread-safe list/queue. FreePascal has something you could use (https://www.freepascal.org/docs-html/rtl/classes/tthreadlist.html) and although dynamically allocated, it may be fast enough for your purposes. Thread safety is crucial to avoid multiple threads overwriting the data structures they share. The way I see it, your timing sensitive hardware reading thread would fill up the queue and then, every so often, your main thread would consume the data from it. You have to also imagine mechanisms to check that one can keep up with the other and signal errors when that is not the case. Hope this helps, and good luck! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
James, From the looks of it you made good progress reading the hardware and using a dedicated thread for it. Congrats! Seems you're in the thick of it now ready to get the minute details sorted out. Anyway, just a heads up that concurrent programming (threads, synchronization, etc) has many pitfalls. My armchair guess is that your program is just not reading fast enough to keep up with the rate of data that the hardware is generated. Having time sensitive code in a separate thread is a good idea but you should also store the report data in an adequately sized and thread safe data structure such as a thread-safe list/queue. FreePascal has something you could use (https://www.freepascal.org/docs-html/rtl/classes/tthreadlist.html) and although dynamically allocated, it may be fast enough for your purposes. Thread safety is crucial to avoid multiple threads overwriting the data structures they share. The way I see it, your timing sensitive hardware reading thread would fill up the queue and then, every so often, your main thread would consume the data from it. You have to also imagine mechanisms to check that one can keep up with the other and signal errors when that is not the case. Hope this helps, and good luck! On 8/18/19 12:05 PM, James Richters wrote: I have a question about USB data transfer.. but it's going to take some explanation... I've been doing more testing with my device and Libusbxhid. Here's the device: https://www.amazon.com/gp/product/B07M5ZY1P2 I have all the inputs working, still have to figure out how to output to the LCD... I've implemented a test program that shows what button I have pressed, and it also processes the switches and handwheel properly... The hand wheel has 100 indents on it, and if I rotated it clockwise, it gives me a positive count, and if I rotate it counter-clockwise, it gives me two's compliment representation of a negative count, it only sends a single byte, and the number it sends is the number of ticks since the last time it reported so it would have to be read at least every 127 ticks. ok.. so I got that all working but then I discovered an issue... I thought the count on the hand wheel was the number of ticks since the last time I got the report... because if I turn the when very slow, I only get 1 or -1... but if I turn it faster, I get larger numbers... but once I got it reporting the total count... I found that if I start with the wheel at the 0 mark, and turn it really slow, it will count exactly 100 times when it returns to the zero point.. but if I got at even a slow (but not ridiculous) speed, then the count would come up short, and if I turned it fast, it would come up really short... So I tried a test, and disabled the writeln to the console... and now it is much more accurate.. at slow and medium speeds it is exact but at really fast speeds it is still slightly short. So I thought this would be a great use for a thread! So I looked into it.. and I guess in windows I don't even need a unit to run a thread.. I just need to define a function and do a BeginThread() to run the function in a thread... well I didn't think it would be THAT easy.. but yes it works! Now I'm going to have threads everywhere LOL. I have the thread running the tightest possible loop to just read the data and store it in the fastest way possible so it can get back to reading again... then outside the thread I read the variables once every 5 seconds and just put where it is... well this improved things greatly, and I will probably use the thread method in the final program... but one thing is still bugging me... it's just not 100% exact all the time, even with the thread method, I still miss count here and there... So back to the in-line code with writeln's of a minute... I tried another test... this time I read the device as normal, then I put a huge delay in.. 5 seconds or so, then I started reading it again.. now if my previous theory was correct, then I should be able to give up to 127 pulses during the delay and it would show the total since the last report... but that's not what happened.. it just forgets about whatever happened during the delayI was careful to only do 1/2 rotation which would be about 50 pulses so I know I didn't make it overflow so this behavior makes me think I am not reading it the correct way it's like it sends the report out every so often whether I am reading it or not.. and when I do read it I get whatever count it is since the last OUTPUT, even if I missed the last output... also if I push a button and release it during the delay, I have no indication it was ever pressed. So my question is.. does this behavior suggest that the device is expecting some other transfer method that would guarantee synchronization? I see in pas-libusb there are test2controlsync and test test3controlasync I'm curious if synchronous transfer would be the way to commun
Re: [fpc-pascal] USB Human Interface Devices
I have a question about USB data transfer.. but it's going to take some
explanation...
I've been doing more testing with my device and Libusbxhid. Here's the device:
https://www.amazon.com/gp/product/B07M5ZY1P2
I have all the inputs working, still have to figure out how to output to the
LCD... I've implemented a test program that shows what button I have pressed,
and it also processes the switches and handwheel properly... The hand wheel
has 100 indents on it, and if I rotated it clockwise, it gives me a positive
count, and if I rotate it counter-clockwise, it gives me two's compliment
representation of a negative count, it only sends a single byte, and the number
it sends is the number of ticks since the last time it reported so it
would have to be read at least every 127 ticks.
ok.. so I got that all working but then I discovered an issue... I thought the
count on the hand wheel was the number of ticks since the last time I got the
report... because if I turn the when very slow, I only get 1 or -1... but if I
turn it faster, I get larger numbers... but once I got it reporting the total
count... I found that if I start with the wheel at the 0 mark, and turn it
really slow, it will count exactly 100 times when it returns to the zero
point.. but if I got at even a slow (but not ridiculous) speed, then the count
would come up short, and if I turned it fast, it would come up really short...
So I tried a test, and disabled the writeln to the console... and now it is
much more accurate.. at slow and medium speeds it is exact but at really fast
speeds it is still slightly short. So I thought this would be a great use for
a thread! So I looked into it.. and I guess in windows I don't even need a
unit to run a thread.. I just need to define a function and do a BeginThread()
to run the function in a thread... well I didn't think it would be THAT easy..
but yes it works! Now I'm going to have threads everywhere LOL. I have the
thread running the tightest possible loop to just read the data and store it in
the fastest way possible so it can get back to reading again... then outside
the thread I read the variables once every 5 seconds and just put where it
is... well this improved things greatly, and I will probably use the thread
method in the final program... but one thing is still bugging me... it's just
not 100% exact all the time, even with the thread method, I still miss count
here and there...
So back to the in-line code with writeln's of a minute... I tried another
test... this time I read the device as normal, then I put a huge delay in.. 5
seconds or so, then I started reading it again.. now if my previous theory was
correct, then I should be able to give up to 127 pulses during the delay and it
would show the total since the last report... but that's not what happened.. it
just forgets about whatever happened during the delayI was careful to only
do 1/2 rotation which would be about 50 pulses so I know I didn't make it
overflow so this behavior makes me think I am not reading it the correct
way it's like it sends the report out every so often whether I am reading
it or not.. and when I do read it I get whatever count it is since the last
OUTPUT, even if I missed the last output... also if I push a button and release
it during the delay, I have no indication it was ever pressed.
So my question is.. does this behavior suggest that the device is expecting
some other transfer method that would guarantee synchronization? I see in
pas-libusb there are test2controlsync and test test3controlasync I'm curious
if synchronous transfer would be the way to communicate with the device that
would guarantee no data loss. I don't really understand how either of these
work, but one is sync and the other is async, so I thought maybe sync was more
the method I should be using. My program in libusbxhid is using:
hidReportData[reportIdx].dataLen:=libusbhid_interrupt_read(device_context,$81{endpoint},{out}hidReportData[reportIdx].hid_data,64{report
length, varies by device}, {timeout=}3000);
Maybe it's not either of those.. but some other method where the device pushes
data into a buffer whenever it wants that I can then read.. or something like
that? Or maybe the interrupt read is the best I can do? Is there any way to
give my read thread to have a higher priority or something like that?
Any thoughts?
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I just pushed it. >Could you please "git push" the source code to Github so that the line numbers >match the output? At least in line 1330 of libusboop.pas there is no Create. >Please ensure that the >version on Github is the very same version where you executed the program and >got the line numbers. Thanks Hansi > Running "i:\programming\pas- > libusb_test_dll\src\examples\testopendevic_vidpid2.exe " > start > 1 > 2 > a05472131 > a10CEEB93 > b > c > FALSE 8086 10CE A36D EB93 > FALSE 8087 10CE 0AAA EB93 > FALSE 0424 10CE 2734 EB93 > FALSE 1D50 10CE 6015 EB93 > FALSE 1B1C 10CE 0C15 EB93 > TRUE 10CE 10CE EB93 EB93 > FALSE 05E3 10CE 0610 EB93 > FALSE 04E8 10CE 61F5 EB93 > FALSE 1B1C 10CE 0C10 EB93 > FALSE 0424 10CE 274C EB93 > FALSE 047D 10CE 1020 EB93 > FALSE 1B1C 10CE 1B4F EB93 > FALSE 1A40 10CE 0101 EB93 > FALSE 0C45 10CE 7403 EB93 > FALSE 10C4 10CE EA60 EB93 > d > e > N > P > L > H1 > I > I2 > Q > R > K > M > O1 > An unhandled exception occurred at $00010002D0BB: > EAccessViolation: Access violation > $00010002D0BB CREATE, line 1330 of libusboop.pas > $00010002B3AB > $00011942 main, line 75 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $00011AF6 main, line 96 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $000100010040 > $000117F0 > $7FFB66D07E94 > $7FFB675FA251 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Samstag, den 17.08.2019, 18:00 -0400 schrieb James Richters: > I commented out all the try & except stuff and ran it.. I get this > output: Could you please "git push" the source code to Github so that the line numbers match the output? At least in line 1330 of libusboop.pas there is no Create. Please ensure that the version on Github is the very same version where you executed the program and got the line numbers. Thanks Hansi > Running "i:\programming\pas- > libusb_test_dll\src\examples\testopendevic_vidpid2.exe " > start > 1 > 2 > a05472131 > a10CEEB93 > b > c > FALSE 8086 10CE A36D EB93 > FALSE 8087 10CE 0AAA EB93 > FALSE 0424 10CE 2734 EB93 > FALSE 1D50 10CE 6015 EB93 > FALSE 1B1C 10CE 0C15 EB93 > TRUE 10CE 10CE EB93 EB93 > FALSE 05E3 10CE 0610 EB93 > FALSE 04E8 10CE 61F5 EB93 > FALSE 1B1C 10CE 0C10 EB93 > FALSE 0424 10CE 274C EB93 > FALSE 047D 10CE 1020 EB93 > FALSE 1B1C 10CE 1B4F EB93 > FALSE 1A40 10CE 0101 EB93 > FALSE 0C45 10CE 7403 EB93 > FALSE 10C4 10CE EA60 EB93 > d > e > N > P > L > H1 > I > I2 > Q > R > K > M > O1 > An unhandled exception occurred at $00010002D0BB: > EAccessViolation: Access violation > $00010002D0BB CREATE, line 1330 of libusboop.pas > $00010002B3AB > $00011942 main, line 75 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $00011AF6 main, line 96 of ../../pas- > libusb_test_dll/src/examples/testopendevic_vidpid2.pas > $000100010040 > $000117F0 > $7FFB66D07E94 > $7FFB675FA251 > > > > > > > Could you please remove the try-except block in > > > testopendevic_vidpid2.pas and compile with debug line info to get > > > the full exception backtrace incl. line numbers? > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I commented out all the try & except stuff and ran it.. I get this output: Running "i:\programming\pas-libusb_test_dll\src\examples\testopendevic_vidpid2.exe " start 1 2 a05472131 a10CEEB93 b c FALSE 8086 10CE A36D EB93 FALSE 8087 10CE 0AAA EB93 FALSE 0424 10CE 2734 EB93 FALSE 1D50 10CE 6015 EB93 FALSE 1B1C 10CE 0C15 EB93 TRUE 10CE 10CE EB93 EB93 FALSE 05E3 10CE 0610 EB93 FALSE 04E8 10CE 61F5 EB93 FALSE 1B1C 10CE 0C10 EB93 FALSE 0424 10CE 274C EB93 FALSE 047D 10CE 1020 EB93 FALSE 1B1C 10CE 1B4F EB93 FALSE 1A40 10CE 0101 EB93 FALSE 0C45 10CE 7403 EB93 FALSE 10C4 10CE EA60 EB93 d e N P L H1 I I2 Q R K M O1 An unhandled exception occurred at $00010002D0BB: EAccessViolation: Access violation $00010002D0BB CREATE, line 1330 of libusboop.pas $00010002B3AB $00011942 main, line 75 of ../../pas-libusb_test_dll/src/examples/testopendevic_vidpid2.pas $00011AF6 main, line 96 of ../../pas-libusb_test_dll/src/examples/testopendevic_vidpid2.pas $000100010040 $000117F0 $7FFB66D07E94 $7FFB675FA251 >>Could you please remove the try-except block in testopendevic_vidpid2.pas and >>compile with debug line info to get the full exception backtrace incl. line >>numbers? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Samstag, den 17.08.2019, 16:16 +0200 schrieb Jean SUZINEAU: > Le 17/08/2019 à 15:00, James Richters a écrit : > > Function TLibUsbInterface.FindEndpoint(MatchFunc : > > TLibUsbEndpointMatchMethod) : Plibusb_endpoint_descriptor; > > MatchFunc(ED) is where the access violation occurs, but I can’t > > trace any further because I can’t find the function MatchFunc() I > > just don’t understand where the actual function is. > > MatchFunc is a parameter (its type is TLibUsbEndpointMatchMethod) of > TLibUsbInterface.FindEndpoint. > To find which function is actually called, you should trace back > where TLibUsbInterface.FindEndpoint is called and what function is > provided as parameter MatchFunc. > It's likely you'll have to "climb up" through several calls, may be > that TLibUsbInterface.FindEndpoint has itself a parameter MatchFunc > If you use the debugger, the callstack and a breakpoint just before > the offending call to MatchFunc should help you to find from where > comes your MatchFunc. > I wouldn't be surprised that it resolves somewhere to an overridden > method Match of an instance of a class derived from > TLibUsbDeviceMatchClass, likely TLibUsbDeviceMatchVidPid.Match, > TLibUsbDeviceMatchVidPidSerial.Match or > TLibUsbInterfaceMatchNumAlt.Match from unit libusbutil.pas > This can sound difficult for you at the beginning if you're not too > much accustomed with variables of type procedure and inheritance, but > after a few practice it's not that complicated. Thanks Jean for the explanation! The MatchFunc is a so called "callback". I've chosen this pattern to allow to implement flexible filter functions when searching for devices, interfaces, endpoints, ... As far as I can see, you are using TMyDevice in mydevice.pas. This unit is specifically implemented for the EZ-USB chips (Cypress AN2131), which do not have Flash or ROM, but only SRAM. The driver has to download the firmware before the real communication. This specific behavior is demonstrated in mydevice.pas. Therefore it is only of limited use for your device. One action of TMyDevice.Create is to open an interface and then two bulk endpoints (see lines 141-145 in your "Hack" branch. The interface can be opened (hence you see an 'e' in your output. Then wants to open the endpoint 2 (line 143) using TLibUsbInterface.FindEndpoint(bEndpointAddress : Byte) at libusboop.pas:1099. This calls via some detours the function where you've added the WriteLns. Actually all these functions should reside cleanly in the Pascal world and there are no calls to libusb functions, therefore I wouldn't expect any calling convention troubles here. Could you please remove the try-except block in testopendevic_vidpid2.pas and compile with debug line info to get the full exception backtrace incl. line numbers? Thanks Hansi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Is the segfault in the same place or has it changed? To debug further, you have to compare sizes of data structures, field types and function call parameter types between the libusb 1.0 and the old libusb0.1. - any mismatch could result in a segfault. On 8/17/19 3:51 PM, James Richters wrote: Oops, I got mixed up.. it's usb.pas that isn't used anymore... I changed LibUsb to stdcall and not it compiles again.. but I still get he access violation with stdcall. James from the copy of your github, looks like libusboop.pas has a uses statement for libusb.pas; so libusb.pas is still used https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusboop.pas (line 30) Uses Classes, SysUtils, LibUsb; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Oops, I got mixed up.. it's usb.pas that isn't used anymore... I changed LibUsb to stdcall and not it compiles again.. but I still get he access violation with stdcall. James > from the copy of your github, looks like libusboop.pas has a uses statement > for libusb.pas; so libusb.pas is still used > https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusboop.pas (line 30) >Uses > Classes, SysUtils, LibUsb; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
fromt he copy of your github, looks like libusboop.pas has a uses statement for libusb.pas; so libusb.pas is still used https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusboop.pas (line 30) Uses Classes, SysUtils, LibUsb; On 8/17/19 1:39 PM, James Richters wrote: I think maybe it is the calling convention... First I tried to change libusboop.pas (libusb.pas is the old unit, libusboop.pas is the one it uses) to stdcall, I was unable to compile it, I get an error libusboop.pas(1456,28) Error: Incompatible types: got "" expected "" libusboop.pas(1726) Fatal: There were 1 errors compiling module, stopping I'm not sure where or how it's expecting CDecl or how to change that to use stdcall. So for fun I tried doing it the other way around, and changed libusbxhid to cdecl... well it compiled ok but then I tried to run it I got this: device attempting go clear halt on ep $81 libusb: error [hid_clear_halt] unable to match endpoint to an open interface - cannot clear clear halt failed So I don't know what all that really means, but it was an endpoint match problem causing access denied. so maybe just need to figure out how to get stdcall to properly work with pas-libusb. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Saturday, August 17, 2019 12:11 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Libusb can be compiled with either calling convention - one just has to be sure which one. In https://github.com/Zaaphod/libusbxhid/blob/master/libusbx.pas (line 35), the windows calling convention is stdcall and that apparently works for both 64 and 32 bit windows. So, James' libusb10 dlls use stdcall. Also, I was under the impression that unlike linux, Windows apps would compile regardless of the calling convention. Only when launching the app and loading a dynamic library a wrong calling convention make things blow up. Anyway, this is definitely something to look into. On 8/17/19 11:46 AM, Jean SUZINEAU wrote: Le 17/08/2019 à 17:10, Stefan V. Pantazi a écrit : The obvious first thing to make sure is that the calling convention matches the library for the platform. I see that in https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusb.pas 9line 46) the calling convention on Windows is cdecl (the stdcall is commented out). In libusbxhid, if I remember correctly, the calling convention for windows dlls is set to stdcall. Yes it's curious. Usually with Microsoft dlls from the Windows API, you use stdcall. Here with stdcall I get an error "Import library not found for libusb-1.0". So I commented out the stcall changed it to cdecl. This allows to compile without errors and test1library.pas works without error, it seems cdecl is the right calling convention for libusb-1.0. One other thing is that debugging is much more tedious without an integrated debugger that allows you to step through each line before you can see which function call blows up with a segfault. James works on the command line but fp.exe seems to integrate gdb.exe the same way that lazarus does, you nearly have the same shortcuts keys for debugging between Turbo Pascal 5.5, fp.exe and lazarus ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I think maybe it is the calling convention... First I tried to change libusboop.pas (libusb.pas is the old unit, libusboop.pas is the one it uses) to stdcall, I was unable to compile it, I get an error libusboop.pas(1456,28) Error: Incompatible types: got "" expected "" libusboop.pas(1726) Fatal: There were 1 errors compiling module, stopping I'm not sure where or how it's expecting CDecl or how to change that to use stdcall. So for fun I tried doing it the other way around, and changed libusbxhid to cdecl... well it compiled ok but then I tried to run it I got this: device attempting go clear halt on ep $81 libusb: error [hid_clear_halt] unable to match endpoint to an open interface - cannot clear clear halt failed So I don't know what all that really means, but it was an endpoint match problem causing access denied. so maybe just need to figure out how to get stdcall to properly work with pas-libusb. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Saturday, August 17, 2019 12:11 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Libusb can be compiled with either calling convention - one just has to be sure which one. In https://github.com/Zaaphod/libusbxhid/blob/master/libusbx.pas (line 35), the windows calling convention is stdcall and that apparently works for both 64 and 32 bit windows. So, James' libusb10 dlls use stdcall. Also, I was under the impression that unlike linux, Windows apps would compile regardless of the calling convention. Only when launching the app and loading a dynamic library a wrong calling convention make things blow up. Anyway, this is definitely something to look into. On 8/17/19 11:46 AM, Jean SUZINEAU wrote: > Le 17/08/2019 à 17:10, Stefan V. Pantazi a écrit : >> The obvious first thing to make sure is that the calling convention >> matches the library for the platform. I see that in >> https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusb.pas 9line >> 46) the calling convention on Windows is cdecl (the stdcall is >> commented out). In libusbxhid, if I remember correctly, the calling >> convention for windows dlls is set to stdcall. > Yes it's curious. > > Usually with Microsoft dlls from the Windows API, you use stdcall. > Here with stdcall I get an error "Import library not found for libusb-1.0". > > So I commented out the stcall changed it to cdecl. > > This allows to compile without errors and test1library.pas works > without error, it seems cdecl is the right calling convention for libusb-1.0. > >> One other thing is that debugging is much more tedious without an >> integrated debugger that allows you to step through each line before >> you can see which function call blows up with a segfault. > James works on the command line but fp.exe seems to integrate gdb.exe > the same way that lazarus does, you nearly have the same shortcuts > keys for debugging between Turbo Pascal 5.5, fp.exe and lazarus ... > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Libusb can be compiled with either calling convention - one just has to be sure which one. In https://github.com/Zaaphod/libusbxhid/blob/master/libusbx.pas (line 35), the windows calling convention is stdcall and that apparently works for both 64 and 32 bit windows. So, James' libusb10 dlls use stdcall. Also, I was under the impression that unlike linux, Windows apps would compile regardless of the calling convention. Only when launching the app and loading a dynamic library a wrong calling convention make things blow up. Anyway, this is definitely something to look into. On 8/17/19 11:46 AM, Jean SUZINEAU wrote: Le 17/08/2019 à 17:10, Stefan V. Pantazi a écrit : The obvious first thing to make sure is that the calling convention matches the library for the platform. I see that in https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusb.pas 9line 46) the calling convention on Windows is cdecl (the stdcall is commented out). In libusbxhid, if I remember correctly, the calling convention for windows dlls is set to stdcall. Yes it's curious. Usually with Microsoft dlls from the Windows API, you use stdcall. Here with stdcall I get an error "Import library not found for libusb-1.0". So I commented out the stcall changed it to cdecl. This allows to compile without errors and test1library.pas works without error, it seems cdecl is the right calling convention for libusb-1.0. One other thing is that debugging is much more tedious without an integrated debugger that allows you to step through each line before you can see which function call blows up with a segfault. James works on the command line but fp.exe seems to integrate gdb.exe the same way that lazarus does, you nearly have the same shortcuts keys for debugging between Turbo Pascal 5.5, fp.exe and lazarus ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Le 17/08/2019 à 17:10, Stefan V. Pantazi a écrit : The obvious first thing to make sure is that the calling convention matches the library for the platform. I see that in https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusb.pas 9line 46) the calling convention on Windows is cdecl (the stdcall is commented out). In libusbxhid, if I remember correctly, the calling convention for windows dlls is set to stdcall. Yes it's curious. Usually with Microsoft dlls from the Windows API, you use stdcall. Here with stdcall I get an error "Import library not found for libusb-1.0". So I commented out the stcall changed it to cdecl. This allows to compile without errors and test1library.pas works without error, it seems cdecl is the right calling convention for libusb-1.0. One other thing is that debugging is much more tedious without an integrated debugger that allows you to step through each line before you can see which function call blows up with a segfault. James works on the command line but fp.exe seems to integrate gdb.exe the same way that lazarus does, you nearly have the same shortcuts keys for debugging between Turbo Pascal 5.5, fp.exe and lazarus ... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
The obvious first thing to make sure is that the calling convention
matches the library for the platform. I see that in
https://github.com/Zaaphod/pas-libusb/blob/Hack/src/libusb.pas 9line 46)
the calling convention on Windows is cdecl (the stdcall is commented
out). In libusbxhid, if I remember correctly, the calling convention for
windows dlls is set to stdcall.
One other thing is that debugging is much more tedious without an
integrated debugger that allows you to step through each line before you
can see which function call blows up with a segfault.
On 8/17/19 9:00 AM, James Richters wrote:
I’m trying to figure out why I get an access violation when I try to open my
device with pas-libusb but it works with libusbxhid they both are using
libusb-1.0.dll
I put a bunch of hacks into pas-libusb to try to figure it out… just a lot of
writeln’s so I can try to track down exactly what’s happening. Because if I
try to trace through the program I get “Program received signal SIGSEGV
Segmentation fault” before I get to the problem
I put this in a branch here:
https://github.com/Zaaphod/pas-libusb/tree/Hack/src
I’m using testopendevic_vidpid2.pas to test it with.
Here’s my output:
start
1
2
a05472131
a10CEEB93
b
c
FALSE 8086 10CE A36D EB93
FALSE 8087 10CE 0AAA EB93
FALSE 0424 10CE 2734 EB93
FALSE 1D50 10CE 6015 EB93
FALSE 1B1C 10CE 0C15 EB93
TRUE 10CE 10CE EB93 EB93
FALSE 05E3 10CE 0610 EB93
FALSE 04E8 10CE 61F5 EB93
FALSE 1B1C 10CE 0C10 EB93
FALSE 0424 10CE 274C EB93
FALSE 047D 10CE 1020 EB93
FALSE 1B1C 10CE 1B4F EB93
FALSE 1A40 10CE 0101 EB93
FALSE 0C45 10CE 7403 EB93
FALSE 10C4 10CE EA60 EB93
d
e
H1
I
4
Cousldn't connect to device: Access violation
Here’s as far as I could get….
(**
* Find endpoint according to MatchFunc
*
* @param MatchFunc method to compare a given endpoint descriptor with a
* criterion
*
* @returns endpoint or Nil
*)
Function TLibUsbInterface.FindEndpoint(MatchFunc : TLibUsbEndpointMatchMethod)
: Plibusb_endpoint_descriptor;
Var IEP : Integer;
ED : Plibusb_endpoint_descriptor;
Begin
writeln('H',FInterface^.bNumEndpoints);
For IEP := 0 to FInterface^.bNumEndpoints-1 do
Begin
Writeln('I');
ED:= @(FInterface^.endpoint^[IEP]);
if MatchFunc(ED) then
Begin
Writeln('J');
Exit(ED);
End
else
Writeln('K');
End;
Result := Nil;
End;
MatchFunc(ED) is where the access violation occurs, but I can’t trace any
further because I can’t find the function MatchFunc() I just don’t understand
where the actual function is.
Maybe I made an error in the way I’m trying to open the device? It can’t be
any problem with the device itself or using libusb-1.0.dll because that is all
working with libusbxhid.. in fact I have all inputs from my device mapped out..
Still don’t have the LCD working…. I can just use libusbxhid, but this is
bugging me and I wanted to try to figure out what’s going on.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
--
___
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Le 17/08/2019 à 15:00, James Richters a écrit : Function TLibUsbInterface.FindEndpoint(MatchFunc : TLibUsbEndpointMatchMethod) : Plibusb_endpoint_descriptor; MatchFunc(ED) is where the access violation occurs, but I can’t trace any further because I can’t find the function MatchFunc() I just don’t understand where the actual function is. MatchFunc is a parameter (its type is TLibUsbEndpointMatchMethod) of TLibUsbInterface.FindEndpoint. To find which function is actually called, you should trace back where TLibUsbInterface.FindEndpoint is called and what function is provided as parameter MatchFunc. It's likely you'll have to "climb up" through several calls, may be that TLibUsbInterface.FindEndpoint has itself a parameter MatchFunc If you use the debugger, the callstack and a breakpoint just before the offending call to MatchFunc should help you to find from where comes your MatchFunc. I wouldn't be surprised that it resolves somewhere to an overridden method Match of an instance of a class derived from TLibUsbDeviceMatchClass, likely TLibUsbDeviceMatchVidPid.Match, TLibUsbDeviceMatchVidPidSerial.Match or TLibUsbInterfaceMatchNumAlt.Match from unit libusbutil.pas This can sound difficult for you at the beginning if you're not too much accustomed with variables of type procedure and inheritance, but after a few practice it's not that complicated. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I’m trying to figure out why I get an access violation when I try to open my
device with pas-libusb but it works with libusbxhid they both are using
libusb-1.0.dll
I put a bunch of hacks into pas-libusb to try to figure it out… just a lot of
writeln’s so I can try to track down exactly what’s happening. Because if I
try to trace through the program I get “Program received signal SIGSEGV
Segmentation fault” before I get to the problem
I put this in a branch here:
https://github.com/Zaaphod/pas-libusb/tree/Hack/src
I’m using testopendevic_vidpid2.pas to test it with.
Here’s my output:
start
1
2
a05472131
a10CEEB93
b
c
FALSE 8086 10CE A36D EB93
FALSE 8087 10CE 0AAA EB93
FALSE 0424 10CE 2734 EB93
FALSE 1D50 10CE 6015 EB93
FALSE 1B1C 10CE 0C15 EB93
TRUE 10CE 10CE EB93 EB93
FALSE 05E3 10CE 0610 EB93
FALSE 04E8 10CE 61F5 EB93
FALSE 1B1C 10CE 0C10 EB93
FALSE 0424 10CE 274C EB93
FALSE 047D 10CE 1020 EB93
FALSE 1B1C 10CE 1B4F EB93
FALSE 1A40 10CE 0101 EB93
FALSE 0C45 10CE 7403 EB93
FALSE 10C4 10CE EA60 EB93
d
e
H1
I
4
Cousldn't connect to device: Access violation
Here’s as far as I could get….
(**
* Find endpoint according to MatchFunc
*
* @param MatchFunc method to compare a given endpoint descriptor with a
* criterion
*
* @returns endpoint or Nil
*)
Function TLibUsbInterface.FindEndpoint(MatchFunc : TLibUsbEndpointMatchMethod)
: Plibusb_endpoint_descriptor;
Var IEP : Integer;
ED : Plibusb_endpoint_descriptor;
Begin
writeln('H',FInterface^.bNumEndpoints);
For IEP := 0 to FInterface^.bNumEndpoints-1 do
Begin
Writeln('I');
ED:= @(FInterface^.endpoint^[IEP]);
if MatchFunc(ED) then
Begin
Writeln('J');
Exit(ED);
End
else
Writeln('K');
End;
Result := Nil;
End;
MatchFunc(ED) is where the access violation occurs, but I can’t trace any
further because I can’t find the function MatchFunc() I just don’t understand
where the actual function is.
Maybe I made an error in the way I’m trying to open the device? It can’t be
any problem with the device itself or using libusb-1.0.dll because that is all
working with libusbxhid.. in fact I have all inputs from my device mapped out..
Still don’t have the LCD working…. I can just use libusbxhid, but this is
bugging me and I wanted to try to figure out what’s going on.
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 16/08/2019 a las 20:45, James Richters escribió: Jose, Can you tell me which relays work with your project at: https://github.com/JoshyFun/VUSBRelayPascal ? "spam" sent by private. I have inputs from my device working but not outputs, I think it would be helpful for me to learn how to output to anything as a stepping stone... and actually USB relays sound like fun. Hello, In the case of USB relays you must invoke a "GetReport" with ReportID = 0 and you get a bitmasked state in 8 bytes of data. To activate and deactivate the code invoke a "SetReport" in the same way. Without a proper API description it could be really hard to implement you hardware :-( -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Jose, Can you tell me which relays work with your project at: https://github.com/JoshyFun/VUSBRelayPascal ? I have inputs from my device working but not outputs, I think it would be helpful for me to learn how to output to anything as a stepping stone... and actually USB relays sound like fun. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Thank you for adding the timeout! That will work for this project, but I may look into threads in my console program, I could simplify a lot of things where I am maintaining a buffer while something else is being fed by the buffer that would probably be a lot easier if I had threads. I've got the read working and have decoded all the buttons and switches on my device, but I still can't write to the display... well not on purpose.. something wrote a bunch of garbage to it at some point, which it is remembering. The problem I am going to have with the LCD is that this device is not the exact one that I have sample code for.. when I decoded all my buttons and switches I realized that I was getting NOTHING like the sample. The sample is for an HB04 and this is a WHB04B, the W is just for wireless.. but the B is a completely different thing.. unfortunately I can't seem to even buy the original one without the B without waiting for a month for it to get here from China... I ordered one today.. but maybe before it gets here I'll figure out some way to just blast data to this one until something happens on the screen, and then I can figure it out. Thanks for the help with all this!! James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Friday, August 16, 2019 1:30 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices On 8/16/19 11:11 AM, James Richters wrote: >>> Remember that interrupt reads are blocking so the way to deal with >>> them is to put them away from the main thread, in their own thread. >>> The moment something is available from the device, then the main >>> thread of your application is signaled to read a buffer with the >>> device report data. So, I can see some thread programming in your >>> future or, I see I did not finish my sentence. What I had in mind is that you could use a library that already implements (using a thread I assume) a call with a timeout. I checked and it looks like the original libusb call that I used did have a timeout parameter that I hardcoded to 0 (infinite timeout). libusb report a timeout as an error code. That did not sit well with me and I preferred to use threads instead of time-out mechanism. > Is there another way to do a read that has a timeout? yes, it took only a few minutes to add the time-out parameter to the libusbhid_interrupt_read call. Have a look at the github repository for the updated version. > > Can I even do threads in a console program? Sure you can, here is one of the simplest example you can start with should you ever need to have multiple threads in your programs. https://github.com/graemeg/freepascal/blob/master/packages/fcl-base/examples/threads.pp -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
On 8/16/19 11:11 AM, James Richters wrote: Remember that interrupt reads are blocking so the way to deal with them is to put them away from the main thread, in their own thread. The moment something is available from the device, then the main thread of your application is signaled to read a buffer with the device report data. So, I can see some thread programming in your future or, I see I did not finish my sentence. What I had in mind is that you could use a library that already implements (using a thread I assume) a call with a timeout. I checked and it looks like the original libusb call that I used did have a timeout parameter that I hardcoded to 0 (infinite timeout). libusb report a timeout as an error code. That did not sit well with me and I preferred to use threads instead of time-out mechanism. > Is there another way to do a read that has a timeout? yes, it took only a few minutes to add the time-out parameter to the libusbhid_interrupt_read call. Have a look at the github repository for the updated version. Can I even do threads in a console program? Sure you can, here is one of the simplest example you can start with should you ever need to have multiple threads in your programs. https://github.com/graemeg/freepascal/blob/master/packages/fcl-base/examples/threads.pp -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
>>Remember that interrupt reads are blocking so the way to deal with them is >>to put them away from the main thread, in their own thread. The moment >>something is available from the device, then the main thread of your >>application is signaled to read a buffer with the device report data. So, I >>can see some thread programming in your future or, Can I even do threads in a console program? Is there another way to do a read that has a timeout? >You got it. Report type can be input, output or feature, just choose the >appropriate constant. Report number, for me was a lot of guesses, trial >and error combined with other examples of similar devices, etc. >Just make hidOutData[0]=Report_id (i.e., the first byte of your array) >and cross your fingers that the report id is correct. So reportID is the same as the first byte, so then I have to repeat it like this: libusbhid_set_report(device_context, HID_REPORT_TYPE_FEATURE, hidOutData[0] , 7, hidOutData[ 0.. 6] ); ? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
On 8/16/19 6:23 AM, James Richters wrote:
DATA!!
Is there a way I can read data from the device with a timeout instead of just
waiting forever for it? It doesn't send anything unless I push a button, but I
need to do other things like update the LCD if I am not pushing a button. My
python example uses a function called hid.read(size,timeout) so I'm trying to
do something similar. This is going to be a console application when I am
done, do I don't have a way to do anything else, so a timeout would work best.
Remember that interrupt reads are blocking so the way to deal with them
is to put them away from the main thread, in their own thread. The
moment something is available from the device, then the main thread of
your application is signaled to read a buffer with the device report
data. So, I can see some thread programming in your future or,
I'm also trying to figure out how to write to the LCD...
I think there is a bug because 7 bytes would be data[0..6] and it would not
duplicate byte 7 but the 0x06 must tell it to send from bytes 0 to 6... but
anyway, regardless of that, how do I do something like hid.send_feature_report?
I have checked an old example where I use a HID set feature report. I
can see that the first byte of the output data (your hidOutData array)
is always set to the reportNum. So the length of the hidOutData array
send to the device includes the actual report number which prepends one
byte to the data. So the Python example is correct.
For example, in this call where I was trying to set a Wacom graphic
tablet mode, the length of hid_data is 3 bytes (the first being the
report number) but the report length in the call is 2
(WACOM_FEATURE_REPORT_LENGTH).
hid_data[0]:=WACOM_REPORT_NUMBER;
hid_data[1]:=WACOM_TABLET_MODE_FINGER_ENABLED;
hid_data[2]:=0;
libusbhid_set_report(device_context,HID_REPORT_TYPE_FEATURE{=$03},
WACOM_REPORT_NUMBER_ID{=2}, WACOM_FEATURE_REPORT_LENGTH{=2}, hid_data);
I'm guessing that libusbhid_set_report() is maybe something similar? But it has parameters for reportType and reportNum... any clue what to put there? Or is this not even the right
You got it. Report type can be input, output or feature, just choose the
appropriate constant. Report number, for me was a lot of guesses, trial
and error combined with other examples of similar devices, etc.
function? I thought maybe putting HID_REPORT_TYPE_FEATURE would mean
to send a feature report? But reportNum I have no idea... I stuck a 1
in there just to see and tried:
libusbhid_set_report(device_context,HID_REPORT_TYPE_FEATURE,1,7,hidOutData[0..6]);
but then I get:
libusb: warning [_hid_set_report] mismatched report ID (data is FE, parameter
is 01)
control transfer to usb device failed!
$FE is what I have in hidOutData[0], but I'm not sure what it wants for a
report id?
Just make hidOutData[0]=Report_id (i.e., the first byte of your array)
and cross your fingers that the report id is correct.
Can you tell me where to get libusb_1.0_X86.dll ?I had the x64 version
from the sample Jean sent me, but I would like to make my program work on 32bit
machines as well.
I remember that I had to build those from source but I am sure you can
find binaries online.
Happy hacking!
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
DATA!! Running "i:\programming\libusbxhid\libusbhid_test.exe " Found 15 devices attached 8086:A36D, bus: 1, address: 0 8087:0AAA, bus: 1, address: 5 0424:2734, bus: 1, address: 51 1D50:6015, bus: 1, address: 38 1B1C:0C15, bus: 1, address: 7 10CE:EB93, bus: 1, address: 47 Found device with vid:pid 4302:60307 at idx:5! Device instance found: 1 at idx:5! 05E3:0610, bus: 1, address: 3 04E8:61F5, bus: 1, address: 18 1B1C:0C10, bus: 1, address: 4 0424:274C, bus: 1, address: 46 047D:1020, bus: 1, address: 45 1B1C:1B4F, bus: 1, address: 43 1A40:0101, bus: 1, address: 50 0C45:7403, bus: 1, address: 36 10C4:EA60, bus: 1, address: 30 Index of device 4302:60307=5 Device opened. Next I must claim the interface. Freeing device list with 15 devices USB device list freed. good boy! device attempting go clear halt on ep $81 libusb: error [hid_clear_halt] unable to match endpoint to an open interface - cannot clear clear halt failed driver inactive - can claim interface getting configuration active config:1 Claiming interface.fingers crossed... Interface claimed ... yay! received:8 bytes from device 04,7F,. ,. ,0F,12,. ,1A, received:8 bytes from device . ,69,. ,. ,. ,13,. ,08, received:8 bytes from device . ,D3,. ,. ,. ,. ,01,92, received:8 bytes from device . ,8F,. ,. ,. ,. ,00,8A, received:8 bytes from device . ,2B,. ,. ,. ,. ,. ,0A, Interface released. Phew.. Heap dump by heaptrc unit of i:\programming\libusbxhid\libusbhid_test.exe 401 memory blocks allocated : 18362/20440 401 memory blocks freed : 18362/20440 0 unfreed memory blocks : 0 True heap size : 196608 (160 used in System startup) True free heap : 196448 Yay I FINALLY got somewhere with this thing!!! Thanks for the example Stefan! I have a python example of how to decode the meaning of the incoming data, that's how I figured out that it sends 8 bytes at a time. Is there a way I can read data from the device with a timeout instead of just waiting forever for it? It doesn't send anything unless I push a button, but I need to do other things like update the LCD if I am not pushing a button. My python example uses a function called hid.read(size,timeout) so I'm trying to do something similar. This is going to be a console application when I am done, do I don't have a way to do anything else, so a timeout would work best. I'm also trying to figure out how to write to the LCD... Here is the python code the outputs stuff to the device: # send feature report, but breaks it into 7 byte packets def write(self, data): n = 0 n += self.hid.send_feature_report(data[0:7], 0x06) n += self.hid.send_feature_report(data[7:14], 0x06) n += self.hid.send_feature_report(data[14:21], 0x06) n += self.hid.send_feature_report(data[21:28], 0x06) n += self.hid.send_feature_report(data[28:35], 0x06) n += self.hid.send_feature_report(data[35:42], 0x06) return n I think there is a bug because 7 bytes would be data[0..6] and it would not duplicate byte 7 but the 0x06 must tell it to send from bytes 0 to 6... but anyway, regardless of that, how do I do something like hid.send_feature_report? I'm guessing that libusbhid_set_report() is maybe something similar? But it has parameters for reportType and reportNum... any clue what to put there? Or is this not even the right function? I thought maybe putting HID_REPORT_TYPE_FEATURE would mean to send a feature report? But reportNum I have no idea... I stuck a 1 in there just to see and tried: libusbhid_set_report(device_context,HID_REPORT_TYPE_FEATURE,1,7,hidOutData[0..6]); but then I get: libusb: warning [_hid_set_report] mismatched report ID (data is FE, parameter is 01) control transfer to usb device failed! $FE is what I have in hidOutData[0], but I'm not sure what it wants for a report id? I put my attempt on Github here: https://github.com/Zaaphod/libusbxhid Can you tell me where to get libusb_1.0_X86.dll ?I had the x64 version from the sample Jean sent me, but I would like to make my program work on 32bit machines as well. Thanks to everyone for the help with this! I really appreciate it. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Well, I am sure you can find some devices lying around. For once your USB mouse and keyboard are HID devices - but one usually avoids messing with them for obvious reasons, in case an USB interface claimed by a test program is not released. Out of curiosity, just now I opened my keyboard device (046d:c517 Logitech, Inc. LX710 Cordless Desktop Laser) and interrupt data reports came right in as I pressed keys (looks like my keyboard generates 16 bytes of data for every key press). Decoding the data though is another problem altogether. Can't test if this also works in Windows but in Linux appears to work ok. But you should be safer testing with a USB game controller or Wii remote as they are also HID devices. I was amazed that the Wii (being wireless and all actually worked.) I also just checked and realized that my APC UPS is also a HID device (ID 051d:0002 American Power Conversion Uninterruptible Power Supply). In sum, plenty of devices to play around with. Have fun! On 8/15/19 8:28 PM, James Richters wrote: Thanks for posting the examples and the information. I'll have a look... I am thinking maybe I should buy some of those USB relays or something simpler just to get SOMETHNG to work so I can figure out what's supposed to even be happening. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Thursday, August 15, 2019 5:31 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hi James, I remember going through many similar difficulties with HID. A few years ago I was trying to connect to much simpler devices than yours (game controllers, weather station base, graphic tablet, etc). USB programming is confusing and many abstraction layers have been created aiming at simplifying it. Unfortunately this introduces dependencies. I remember trying to port hidapi headers to Pascal and tried to use the hidraw backend (in linux) with mixed results. Also tried the libhid cross-platform library. In the end I went with libusb 1.0 for which a Pascal header already existed (https://forum.lazarus.freepascal.org/index.php?topic=11435.0) and used it to implement on top of it a subset of the HID API calls that suited my needs and kept things simple. I just posted an example on github: https://github.com/svpantazi/libusbxhid Hope it helps. In theory you could use the Windows HID API but, as others have suggested, the solution would not be cross platform, or, to put it another way, Windows HID API would become your dependency. My suggestion is also to go the libusb 1.0 route and use a Pascal HID library that depends only on libusb 1.0. Your device appears to be HID-compliant so no additional drivers should be needed for it. As far as I know, the Zadig generic driver is necessary only for non-HID devices. I remember using it for a rtl-sdr USB device on Windows. Hope you find your solution. Good luck. On 8/15/19 9:11 AM, James Richters wrote: Yes, in device manager I see it listed as "HID-compliant vendor-defined device" also Zadig identifies it as "USB Input Device" and it shows Driver: HidUsb (v10.1.17763.1) Is there a way to use the windows system HID interface with FPC already in place as there is for other windows APIs? James -Original Message- From: fpc-pascal On Behalf Of José Mejuto Sent: Thursday, August 15, 2019 8:34 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices El 14/08/2019 a las 16:29, James Richters escribió: I'll have a look at your project.. maybe it will give me some clues. Can you tell me how to get hid.dll? I find it all very confusing, can I just download the dll somewhere or do I have to get this huge confusing package and built it myself? The sample code that is able to access my device with python on Linux uses hid.dll I would like to at least be able to try the hid.dll... if I can get hid.dll somewhere. Hello, hid.dll is the windows system HID interface, the API provided by Windows. In the other hand, the hardware you are trying to manage is 10CE:EB93 ? Yes, I got a listing of all devices, then I plugged in the new one, and that is the ID that was not there before. If the answer is yes, that device is *not* HID compatible so you can not use hid.dll for native access, you must use WinUSB API set, or the libusb-1.0 abstraction layer. I'm curious how you can tell that by looking at the number of it? No, I just look for the product and try to find its drivers, no one name the HID interface. Do you see the device in windows device manager under the HID section "Human Interface Devices (HID)" ? -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Thanks for posting the examples and the information. I'll have a look... I am thinking maybe I should buy some of those USB relays or something simpler just to get SOMETHNG to work so I can figure out what's supposed to even be happening. James -Original Message- From: fpc-pascal On Behalf Of Stefan V. Pantazi Sent: Thursday, August 15, 2019 5:31 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hi James, I remember going through many similar difficulties with HID. A few years ago I was trying to connect to much simpler devices than yours (game controllers, weather station base, graphic tablet, etc). USB programming is confusing and many abstraction layers have been created aiming at simplifying it. Unfortunately this introduces dependencies. I remember trying to port hidapi headers to Pascal and tried to use the hidraw backend (in linux) with mixed results. Also tried the libhid cross-platform library. In the end I went with libusb 1.0 for which a Pascal header already existed (https://forum.lazarus.freepascal.org/index.php?topic=11435.0) and used it to implement on top of it a subset of the HID API calls that suited my needs and kept things simple. I just posted an example on github: https://github.com/svpantazi/libusbxhid Hope it helps. In theory you could use the Windows HID API but, as others have suggested, the solution would not be cross platform, or, to put it another way, Windows HID API would become your dependency. My suggestion is also to go the libusb 1.0 route and use a Pascal HID library that depends only on libusb 1.0. Your device appears to be HID-compliant so no additional drivers should be needed for it. As far as I know, the Zadig generic driver is necessary only for non-HID devices. I remember using it for a rtl-sdr USB device on Windows. Hope you find your solution. Good luck. On 8/15/19 9:11 AM, James Richters wrote: > Yes, in device manager I see it listed as "HID-compliant > vendor-defined device" also Zadig identifies it as "USB Input Device" > and it shows Driver: HidUsb (v10.1.17763.1) > > Is there a way to use the windows system HID interface with FPC already in > place as there is for other windows APIs? > > James > > -Original Message- > From: fpc-pascal On Behalf > Of José Mejuto > Sent: Thursday, August 15, 2019 8:34 AM > To: fpc-pascal@lists.freepascal.org > Subject: Re: [fpc-pascal] USB Human Interface Devices > > El 14/08/2019 a las 16:29, James Richters escribió: > >> I'll have a look at your project.. maybe it will give me some clues. >> Can you tell me how to get hid.dll? I find it all very confusing, can I >> just download the dll somewhere or do I have to get this huge confusing >> package and built it myself? The sample code that is able to access my >> device with python on Linux uses hid.dll I would like to at least be able >> to try the hid.dll... if I can get hid.dll somewhere. > > Hello, > > hid.dll is the windows system HID interface, the API provided by Windows. > >>> In the other hand, the hardware you are trying to manage is 10CE:EB93 ? >> Yes, I got a listing of all devices, then I plugged in the new one, and that >> is the ID that was not there before. >>> If the answer is yes, that device is *not* HID compatible so you can >>> not use hid.dll for native access, you must use WinUSB API set, or >>> the >>> libusb-1.0 abstraction layer. >> I'm curious how you can tell that by looking at the number of it? > > No, I just look for the product and try to find its drivers, no one name the > HID interface. Do you see the device in windows device manager under the HID > section "Human Interface Devices (HID)" ? > > -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi James, I remember going through many similar difficulties with HID. A few years ago I was trying to connect to much simpler devices than yours (game controllers, weather station base, graphic tablet, etc). USB programming is confusing and many abstraction layers have been created aiming at simplifying it. Unfortunately this introduces dependencies. I remember trying to port hidapi headers to Pascal and tried to use the hidraw backend (in linux) with mixed results. Also tried the libhid cross-platform library. In the end I went with libusb 1.0 for which a Pascal header already existed (https://forum.lazarus.freepascal.org/index.php?topic=11435.0) and used it to implement on top of it a subset of the HID API calls that suited my needs and kept things simple. I just posted an example on github: https://github.com/svpantazi/libusbxhid Hope it helps. In theory you could use the Windows HID API but, as others have suggested, the solution would not be cross platform, or, to put it another way, Windows HID API would become your dependency. My suggestion is also to go the libusb 1.0 route and use a Pascal HID library that depends only on libusb 1.0. Your device appears to be HID-compliant so no additional drivers should be needed for it. As far as I know, the Zadig generic driver is necessary only for non-HID devices. I remember using it for a rtl-sdr USB device on Windows. Hope you find your solution. Good luck. On 8/15/19 9:11 AM, James Richters wrote: Yes, in device manager I see it listed as "HID-compliant vendor-defined device" also Zadig identifies it as "USB Input Device" and it shows Driver: HidUsb (v10.1.17763.1) Is there a way to use the windows system HID interface with FPC already in place as there is for other windows APIs? James -Original Message- From: fpc-pascal On Behalf Of José Mejuto Sent: Thursday, August 15, 2019 8:34 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices El 14/08/2019 a las 16:29, James Richters escribió: I'll have a look at your project.. maybe it will give me some clues. Can you tell me how to get hid.dll? I find it all very confusing, can I just download the dll somewhere or do I have to get this huge confusing package and built it myself? The sample code that is able to access my device with python on Linux uses hid.dll I would like to at least be able to try the hid.dll... if I can get hid.dll somewhere. Hello, hid.dll is the windows system HID interface, the API provided by Windows. In the other hand, the hardware you are trying to manage is 10CE:EB93 ? Yes, I got a listing of all devices, then I plugged in the new one, and that is the ID that was not there before. If the answer is yes, that device is *not* HID compatible so you can not use hid.dll for native access, you must use WinUSB API set, or the libusb-1.0 abstraction layer. I'm curious how you can tell that by looking at the number of it? No, I just look for the product and try to find its drivers, no one name the HID interface. Do you see the device in windows device manager under the HID section "Human Interface Devices (HID)" ? -- ___ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 15/08/2019 a las 15:11, James Richters escribió: Yes, in device manager I see it listed as "HID-compliant vendor-defined device" also Zadig identifies it as "USB Input Device" and it shows Driver: HidUsb (v10.1.17763.1) Is there a way to use the windows system HID interface with FPC already in place as there is for other windows APIs? Hello, You can find a HID interface for windows at: https://libstock.mikroe.com/projects/view/528/usb-hid-dll-for-delphi-and-perhaps-other-languages In the "Basic" package. Anyway, if possible, the use of libusb-1.0 is recommended as it will give you crossplatform support. You can check my project to see how devices are enumerated, based in the libusb-1.0 function calls. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Yes, in device manager I see it listed as "HID-compliant vendor-defined device" also Zadig identifies it as "USB Input Device" and it shows Driver: HidUsb (v10.1.17763.1) Is there a way to use the windows system HID interface with FPC already in place as there is for other windows APIs? James -Original Message- From: fpc-pascal On Behalf Of José Mejuto Sent: Thursday, August 15, 2019 8:34 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices El 14/08/2019 a las 16:29, James Richters escribió: > I'll have a look at your project.. maybe it will give me some clues. > Can you tell me how to get hid.dll? I find it all very confusing, can I > just download the dll somewhere or do I have to get this huge confusing > package and built it myself? The sample code that is able to access my > device with python on Linux uses hid.dll I would like to at least be able to > try the hid.dll... if I can get hid.dll somewhere. Hello, hid.dll is the windows system HID interface, the API provided by Windows. >> In the other hand, the hardware you are trying to manage is 10CE:EB93 ? > Yes, I got a listing of all devices, then I plugged in the new one, and that > is the ID that was not there before. >> If the answer is yes, that device is *not* HID compatible so you can >> not use hid.dll for native access, you must use WinUSB API set, or >> the >> libusb-1.0 abstraction layer. > I'm curious how you can tell that by looking at the number of it? No, I just look for the product and try to find its drivers, no one name the HID interface. Do you see the device in windows device manager under the HID section "Human Interface Devices (HID)" ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 14/08/2019 a las 16:29, James Richters escribió: I'll have a look at your project.. maybe it will give me some clues. Can you tell me how to get hid.dll? I find it all very confusing, can I just download the dll somewhere or do I have to get this huge confusing package and built it myself? The sample code that is able to access my device with python on Linux uses hid.dll I would like to at least be able to try the hid.dll... if I can get hid.dll somewhere. Hello, hid.dll is the windows system HID interface, the API provided by Windows. In the other hand, the hardware you are trying to manage is 10CE:EB93 ? Yes, I got a listing of all devices, then I plugged in the new one, and that is the ID that was not there before. If the answer is yes, that device is *not* HID compatible so you can not use hid.dll for native access, you must use WinUSB API set, or the libusb-1.0 abstraction layer. I'm curious how you can tell that by looking at the number of it? No, I just look for the product and try to find its drivers, no one name the HID interface. Do you see the device in windows device manager under the HID section "Human Interface Devices (HID)" ? -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
>My code to manage HID USB relays uses hid.dll (32 & 64 bits) or >libusb-1.0 (32 bits only tested) on Windows, and libusb-1.0 or >libusb-0.1 in Linux. I'll have a look at your project.. maybe it will give me some clues. Can you tell me how to get hid.dll? I find it all very confusing, can I just download the dll somewhere or do I have to get this huge confusing package and built it myself? The sample code that is able to access my device with python on Linux uses hid.dll I would like to at least be able to try the hid.dll... if I can get hid.dll somewhere. >Of course, functions on hid.dll and libusb are no the same, they work in >different way, but the libusb-1.0 works the same way in both platforms. The hid.dll way seems to have the functions I am trying to duplicate. >Implementation of hid.dll, libusb, etc, in my code only have relevant >functions used in USB relays, so they can not used as a complete >implementation. Maybe it will at least be able to get me started with some basic access.. at this point I would be happy to make it just open and close the device without an error. >In the other hand, the hardware you are trying to manage is 10CE:EB93 ? Yes, I got a listing of all devices, then I plugged in the new one, and that is the ID that was not there before. >If the answer is yes, that device is *not* HID compatible so you can not use >hid.dll for native access, you must use WinUSB API set, or the >libusb-1.0 abstraction layer. I'm curious how you can tell that by looking at the number of it? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
El 14/08/2019 a las 1:41, James Richters escribió: I wonder if HID devices will work at all on Windows the same as they do on Linux. I have not been able to get the HID part of the python code to work on windows yet either because the instructions given to install the packages needed Hello, HID devices works in the same way, you need a device driver for the hardware that exposes a HID interface and you can manage that HID interface using native hid.dll or use an abstraction layer like libusb-1.0. https://github.com/JoshyFun/VUSBRelayPascal My code to manage HID USB relays uses hid.dll (32 & 64 bits) or libusb-1.0 (32 bits only tested) on Windows, and libusb-1.0 or libusb-0.1 in Linux. Of course, functions on hid.dll and libusb are no the same, they work in different way, but the libusb-1.0 works the same way in both platforms. Implementation of hid.dll, libusb, etc, in my code only have relevant functions used in USB relays, so they can not used as a complete implementation. In the other hand, the hardware you are trying to manage is 10CE:EB93 ? If the answer is yes, that device is *not* HID compatible so you can not use hid.dll for native access, you must use WinUSB API set, or the libusb-1.0 abstraction layer. -- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I wonder if HID devices will work at all on Windows the same as they do on Linux. I have not been able to get the HID part of the python code to work on windows yet either because the instructions given to install the packages needed only apply to Linux... I also wonder if fundamental differences in operating systems is why FPC doesn't already have built in support for HID devices... maybe it's just not possible to make it cross platform. I did a little searching... I came across this: https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts it seems maybe you are right and even though I did not install a driver into windows for this device, maybe windows just detected it was an HID device and attached it, and what I really need to do is access it through windows, not directly.. I had to do this with parallel ports.. I can't just read and write directly to the parallel port like I used to be able to with DOS, I have to go through windows somehow.. I am using http://www.highrez.co.uk/Downloads/InpOut32/ to work with parallel ports with Windows. I think it's a DLL written in C, so I had to write a unit to get it to work with FPC... but it does work reliably even though windows shows the ports in device manager. Microsoft seems to be completely against users accessing hardware directly as we used to be able to with DOS. I wonder if the only way to get FPC to work with HID devices on Windows is to do something similar with the windows HID API, and go through windows the only way windows will allow me to access these devices. I've been searching trying to find information on this.. I came across the project at: https://github.com/signal11/hidapi it states in the readme: HIDAPI has four back-ends: * Windows (using hid.dll) * Linux/hidraw (using the Kernel's hidraw driver) * Linux/libusb (using libusb-1.0) * FreeBSD (using libusb-1.0) * Mac (using IOHidManager) This seems to indicate the libusb-1.0 is what you use for Linux and FreeBSD, but not for windows, because if it worked for Windows or Mac, then why bother doing it differently for them. Of course this project is for C, not pascal So then I was looking for a Pascal way to use hid.dll, and came across this: https://github.com/prof7bit/HIDAPI.pas/blob/master/hidapi.pas that looked promising because it has functions like Open(), Close(), Write(), Read(), SendFeatureReport() etc... but that isn't working under windows... uggg. It seems that using this HID device with FPC under windows is going to be anything but easy... u maybe I can solve it with hardware.. I can get a raspberry pi, teach my self python, hack the python code to interface with the HID device on the Rpi and communicate with my windows 10 FPC program over an ethernet port or something stupid like that and hope it's fast enough... boy is sure seems stupid to use another complete computer to interface this once device to windows... I guess I'll keep trying to come up with a solution. Anyone have any thoughts on all this? James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi James!
Am Montag, den 12.08.2019, 20:20 -0400 schrieb James Richters:
> > > Ah, I see. You declared EP as Plibusb_endpoint_descriptor (i.e.,
> > > the pointer to an endpoint descriptor record), while in the
> > > original code it is a USBEndpointDescriptor (i.e., the record
> > > itself).
> > > Your version is more memory efficient but uses "ugly pointer-
> > > arithmetic" by taking the address of an array element. However,
> > > just keep it as you implemented it.
>
> Well that wasn’t my idea, I was trying to get it to compile and I
> saw the existing function:
> // helper function for method below, this can't be a local function
> Function
> MyEndpointMatch(EP:Plibusb_endpoint_descriptor;Data:Pointer):Boolean;
> Var bEndpointAddress : Byte;
> Begin
> bEndpointAddress := (PtrUInt(Data) shr 0) and $FF;
> Result := (EP^.bEndpointAddress = bEndpointAddress);
> End;
>
> It compiled and had the pointer, so I stuck a pointer in the
> one I was having a problem with and it compiled it was just a
> guess at how to get it to compile honestly. I figured that the other
> code had it so maybe something to do with the way things are defined
> now require it to be a pointer.. without the pointer it gives errors.
Yes, yes, no worries! That was no criticism, just a (hopefully)
objective description of what I saw in the code. :-)
> > > While reviewing your changes, I found a few small things.
> > > Could you please keep the indenting and coding style as the
> > > existing code? This is especially for the constant and type
> > > declarations around TLibUsbPseudoHIDInterface (IIRC the
> > > >>keywords Type and Const should start at character 1, therefore
> > > you also should un-indent the 6+3 constants and the P/THIDReport
> > > record (except its final "End;" by 2 spaces.
>
> Yes, I will keep the indenting and coding style the same, No
> problem, I adjusted this as you requested. I'll go through later and
> see if there are any other things I missed.. most of what I've done
> is cutting and pasting, but I'll keep it consistent.
Great, thanks! And there is no hurry.
> > > Secondly, in your improved TLibUsbInterface.FindEndpoint, please
> > > revert the capitalization and indenting changes (i.e., capital
> > > "Function", "For", ..., and "do" and "then" in the same line, ...
> > > IMHO the only changed lines in comparison to the original code
> > > should be the extra variable EP, its assignment without range
> > > checks, and its use in MatchFunc and Exit.
> That was code the Jean sent me to get it to work under windows, but I
> wend an retrieved the original function and re-did the modifications
> to match the formatting. It compiles fine without turning off range
> check, but I think there was some reason why Jean had to put them in
> there.. I'll leave it out for now unless we figure out why they were
> needed.
You can just keep in the range checking. I think I should have done
this from the beginning, but never used range checking, therefore never
thought of it.
> > > And thirdly, you introduced a class type
> > > TLibUsbInterruptInEndpoint, which is IMHO unused. If its so,
> > > please remove it. I like to avoid clutter. :-)
> I guess you are talking about line
> 128: TLibUsbInterruptInEndpoint = class; ?
> When I copied over { TUSBPseudoHIDInterface } and then
> renamed everything I needed it to be able to compile
> Line 211:FIntrEndpoint : TLibUsbInterruptInEndpoint;
> Without it I was getting libusboop.pas(212,21) Error:
> Identifier not found "TLibUsbInterruptInEndpoint"
> So I went back to usb.pas and copied that line over to
> prevent this error... perhaps I have it in the wrong place??
Let me have a closer look. :-)
Ah, sorry, it was my fault. I should have looked at the complete file,
not just the diff. :-)
Please keep the forward declaration in.
> > > Apart form these cosmetic things, thank you very much for your
> > > effort!
> No problem, please let me know if I missed anything, I'm
> happy to make it conform to the coding standards. I’m a little
> confused by the capitalization, for example sometimes it's
> LibUsb, sometimes it's Libusb.. I'm trying to figure out when the U
> is capitated and when it is not maybe it should always be one way
> or the other? Please continue to correct me on anything you see.
That's probably my own lazyness. However, at least in libusboop.pas,
all declarations use LibUsb (capital 'U') everywhere. And in libusb.pas
its "libusb" (all small letters) except the unit name itself.
> > > I'm looking forward hearing from you your success when accessing
> > > a HID device (or call for help :-) ).
>
> Well. since you asked... I'm having a real challenge trying
> to figure out how I can use all this to access my device... I'm just
> not familiar with this kind of programming... constructors,
> destructors, and all this inherited stuff, it's not what I am used
> t
Re: [fpc-pascal] USB Human Interface Devices
>>Ah, I see. You declared EP as Plibusb_endpoint_descriptor (i.e., the pointer
>>to an endpoint descriptor record), while in the original code it is a
>>USBEndpointDescriptor (i.e., the record itself).
>>Your version is more memory efficient but uses "ugly pointer- arithmetic" by
>>taking the address of an array element. However, just keep it as you
>>implemented it.
Well that wasn’t my idea, I was trying to get it to compile and I saw the
existing function:
// helper function for method below, this can't be a local function
Function MyEndpointMatch(EP:Plibusb_endpoint_descriptor;Data:Pointer):Boolean;
Var bEndpointAddress : Byte;
Begin
bEndpointAddress := (PtrUInt(Data) shr 0) and $FF;
Result := (EP^.bEndpointAddress = bEndpointAddress);
End;
It compiled and had the pointer, so I stuck a pointer in the one I was
having a problem with and it compiled it was just a guess at how to get it
to compile honestly. I figured that the other code had it so maybe something to
do with the way things are defined now require it to be a pointer.. without the
pointer it gives errors.
>>While reviewing your changes, I found a few small things.
>>Could you please keep the indenting and coding style as the existing code?
>>This is especially for the constant and type declarations around
>>TLibUsbPseudoHIDInterface (IIRC the >>keywords Type and Const should start at
>>character 1, therefore you also should un-indent the 6+3 constants and the
>>P/THIDReport record (except its final "End;" by 2 spaces.
Yes, I will keep the indenting and coding style the same, No problem, I
adjusted this as you requested. I'll go through later and see if there are any
other things I missed.. most of what I've done is cutting and pasting, but I'll
keep it consistent.
>>Secondly, in your improved TLibUsbInterface.FindEndpoint, please revert the
>>capitalization and indenting changes (i.e., capital "Function", "For", ...,
>>and "do" and "then" in the same line, ... IMHO the only changed lines in
>>comparison to the original code should be the extra variable EP, its
>>assignment without range checks, and its use in MatchFunc and Exit.
That was code the Jean sent me to get it to work under windows, but I
wend an retrieved the original function and re-did the modifications to match
the formatting. It compiles fine without turning off range check, but I think
there was some reason why Jean had to put them in there.. I'll leave it out for
now unless we figure out why they were needed.
>>And thirdly, you introduced a class type TLibUsbInterruptInEndpoint, which is
>>IMHO unused. If its so, please remove it. I like to avoid clutter. :-)
I guess you are talking about line 128: TLibUsbInterruptInEndpoint
= class; ?
When I copied over { TUSBPseudoHIDInterface } and then renamed
everything I needed it to be able to compile
Line 211:FIntrEndpoint : TLibUsbInterruptInEndpoint;
Without it I was getting libusboop.pas(212,21) Error: Identifier
not found "TLibUsbInterruptInEndpoint"
So I went back to usb.pas and copied that line over to prevent
this error... perhaps I have it in the wrong place??
>>Apart form these cosmetic things, thank you very much for your effort!
No problem, please let me know if I missed anything, I'm happy to
make it conform to the coding standards. I’m a little confused by the
capitalization, for example sometimes it's LibUsb, sometimes it's Libusb.. I'm
trying to figure out when the U is capitated and when it is not maybe it
should always be one way or the other? Please continue to correct me on
anything you see.
>>I'm looking forward hearing from you your success when accessing a HID device
>>(or call for help :-) ).
Well. since you asked... I'm having a real challenge trying to
figure out how I can use all this to access my device... I'm just not familiar
with this kind of programming... constructors, destructors, and all this
inherited stuff, it's not what I am used to, I never have anything like that..
I know how to program in Turbo Pascal for DOS pretty much and normal in-line
console style programming, but very little of anything past that, so a lot of
this just goes over my head.
On top of that, I really don't understand USB communications at all, I
have written programs with all kinds of features, programs that send e-mails,
communicate over ethernet and serial connections, Modbus, etc... but this USB
stuff is just not making any sense to me... and it seems like the python code I
have as an example is so simple... you open the device, send and receive some
stuff and close it... but I don't really know python either, so I really don't
understand everything going on there...
I still don't really see how to open and close the device or how to
send or receive anything from it... I'm struggling to see how the somewhat
simple loo
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Sonntag, den 11.08.2019, 19:13 -0400 schrieb James Richters: > Thank you for the help. I made most of the changes you recommend and > I was able to get it to compile, the only one I had trouble with was > If I take out the ^ from: >if (EP^.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = > LIBUSB_TRANSFER_TYPE_INTERRUPT) and > (EP^.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) > then > > So it looks like this: >if (EP.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = > LIBUSB_TRANSFER_TYPE_INTERRUPT) and > (EP.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) > then > > I get a compiler error: > libusboop.pas(1168,14) Error: Illegal qualifier > libusboop.pas(1168,14) Fatal: Syntax error, ")" expected but > "identifier BMATTRIBUTES" found > libusboop.pas(0) Fatal: Compilation aborted > > With the ^ in it compiles anyway... I don't know how to adjust the > format to not have the ^ > > I have not tried to do anything with TLibUsbPseudoHIDInterface yet, I > was just trying to get libusboop.pas to compile, and be able to still > run the previous examples. > > I've updated my repository at > https://github.com/Zaaphod/pas-libusb/tree/Test > > Let me know if I should do something different with the ^ above, or > if you see anything else I missed. Ah, I see. You declared EP as Plibusb_endpoint_descriptor (i.e., the pointer to an endpoint descriptor record), while in the original code it is a USBEndpointDescriptor (i.e., the record itself). Your version is more memory efficient but uses "ugly pointer- arithmetic" by taking the address of an array element. However, just keep it as you implemented it. While reviewing your changes, I found a few small things. Could you please keep the indenting and coding style as the existing code? This is especially for the constant and type declarations around TLibUsbPseudoHIDInterface (IIRC the keywords Type and Const should start at character 1, therefore you also should un-indent the 6+3 constants and the P/THIDReport record (except its final "End;" by 2 spaces. Secondly, in your improved TLibUsbInterface.FindEndpoint, please revert the capitalization and indenting changes (i.e., capital "Function", "For", ..., and "do" and "then" in the same line, ... IMHO the only changed lines in comparison to the original code should be the extra variable EP, its assignment without range checks, and its use in MatchFunc and Exit. And thirdly, you introduced a class type TLibUsbInterruptInEndpoint, which is IMHO unused. If its so, please remove it. I like to avoid clutter. :-) Apart form these cosmetic things, thank you very much for your effort! I'm looking forward hearing from you your success when accessing a HID device (or call for help :-) ). Thanks Hansi > -----Original Message- > From: fpc-pascal On Behalf > Of Johann Glaser > Sent: Sunday, August 11, 2019 4:16 PM > To: fpc-pascal@lists.freepascal.org > Subject: Re: [fpc-pascal] USB Human Interface Devices > > Hi! > > Am Samstag, den 10.08.2019, 17:50 -0400 schrieb James Richters: > > I'm making an attempt to copy TUSBPseudoHIDInterface into > > libusboop.pas. I've made the recomended name changes and then > > tried > > to compile it. Some things I found like the names changing from > > things like > > > > PUSBInterfaceDescriptop to Plibusb_interface_descriptor > > OK, there are two things. Names directly from libusb-1.0 (as used in > libusb.pas) should be identical to the original C code, i.e., > Plibusb_interface_descriptor as you've written. > > The second thing are the classes in the OOP wrapper in libusboop.pas. > Please use CamelCase for them, e.g., TLibusbPseudoHIDInterface. > > > are pretty obvious, but just taking a guess on other things like: > > > > changing: > > if (EP.bmAttributes and USB_ENDPOINT_TYPE_MASK = > > USB_ENDPOINT_TYPE_INTERRUPT) and > > (EP.bEndpointAddress and USB_ENDPOINT_DIR_MASK <> 0) then > > > > To: > > if (EP^.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = > > LIBUSB_TRANSFER_TYPE_INTERRUPT) and > > (EP^.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) > > then > > Yes, very good, thanks! > > Whether EP is a pointer (--> EP^.bmAttributes) or a record > (EP.bmAttributs) just depends on the usage in the code. As I see in > usb.pas in line 846, in TUSBPseudoHIDInterface.Create, it is actually > the record, so you should stay without the '^'. > > > Based on looking at something similar in libusbutil... but I'm not > > sure it's right at all I'm not sur
Re: [fpc-pascal] USB Human Interface Devices
Thank you for the help. I made most of the changes you recommend and I was able to get it to compile, the only one I had trouble with was If I take out the ^ from: if (EP^.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = LIBUSB_TRANSFER_TYPE_INTERRUPT) and (EP^.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) then So it looks like this: if (EP.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = LIBUSB_TRANSFER_TYPE_INTERRUPT) and (EP.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) then I get a compiler error: libusboop.pas(1168,14) Error: Illegal qualifier libusboop.pas(1168,14) Fatal: Syntax error, ")" expected but "identifier BMATTRIBUTES" found libusboop.pas(0) Fatal: Compilation aborted With the ^ in it compiles anyway... I don't know how to adjust the format to not have the ^ I have not tried to do anything with TLibUsbPseudoHIDInterface yet, I was just trying to get libusboop.pas to compile, and be able to still run the previous examples. I've updated my repository at https://github.com/Zaaphod/pas-libusb/tree/Test Let me know if I should do something different with the ^ above, or if you see anything else I missed. James -Original Message- From: fpc-pascal On Behalf Of Johann Glaser Sent: Sunday, August 11, 2019 4:16 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hi! Am Samstag, den 10.08.2019, 17:50 -0400 schrieb James Richters: > I'm making an attempt to copy TUSBPseudoHIDInterface into > libusboop.pas. I've made the recomended name changes and then tried > to compile it. Some things I found like the names changing from > things like > > PUSBInterfaceDescriptop to Plibusb_interface_descriptor OK, there are two things. Names directly from libusb-1.0 (as used in libusb.pas) should be identical to the original C code, i.e., Plibusb_interface_descriptor as you've written. The second thing are the classes in the OOP wrapper in libusboop.pas. Please use CamelCase for them, e.g., TLibusbPseudoHIDInterface. > are pretty obvious, but just taking a guess on other things like: > > changing: > if (EP.bmAttributes and USB_ENDPOINT_TYPE_MASK = > USB_ENDPOINT_TYPE_INTERRUPT) and > (EP.bEndpointAddress and USB_ENDPOINT_DIR_MASK <> 0) then > > To: > if (EP^.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = > LIBUSB_TRANSFER_TYPE_INTERRUPT) and > (EP^.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) then Yes, very good, thanks! Whether EP is a pointer (--> EP^.bmAttributes) or a record (EP.bmAttributs) just depends on the usage in the code. As I see in usb.pas in line 846, in TUSBPseudoHIDInterface.Create, it is actually the record, so you should stay without the '^'. > Based on looking at something similar in libusbutil... but I'm not > sure it's right at all I'm not sure if USB_ENDPOINT_TYPE_MASK was > really changed to LIBUSB_TRANSFER_TYPE_MASK or if something else > happened. But at least it compiles... You translated it correctly. > but now I've hit a few items that I just don't know what to do > with.I can't find anything similar to get a reference from: > > libusboop.pas(1198,28) Error: Identifier not found "USB_TYPE_CLASS" Use LIBUSB_REQUEST_TYPE_CLASS. > libusboop.pas(1199,5) Error: Identifier not found > "USB_REQ_HID_SET_REPORT" > libusboop.pas(1216,27) Error: Identifier not found "USB_TYPE_CLASS" > libusboop.pas(1217,5) Error: Identifier not found > "USB_REQ_HID_GET_REPORT" > libusboop.pas(1227,23) Error: Identifier not found > "HID_REPORT_TYPE_OUTPUT" Please copy the constants USB_REQ_HID_* and HID_REPORT_* from libusb.pas (branch master) lines 248-257 to the interface section of libusboop.pas (branch libusb-1.0) directly above the class declaration of TLibusbPseudoHIDInterface. Then please rename USB_REQ_HID_* to LIBUSB_REQUEST_HID_* and HID_REPORT_* to LIBUSB_HID_REPORT_*. > I've tried things that seem to be in line with other changes, like > changing USB_Type_Class to LIBUSB_TYPE_CLASS or spelling out REQUEST > instead of REQ which also seems to be done in other places, but still > the identifiers are not found... the problem is I have no idea where > these identifiers were/are defined. > > I made a fork in github and a branch called "test" here: > https://github.com/Zaaphod/pas-libusb/tree/Test Great approach, thanks, then we can use pull requests. Thanks Hansi > > Actually you could copy the class TUSBPseudoHIDInterface (plus the > > types THIDReport and TIntrReportFunc) from usb.pas to libusboop.pas > > and change everything necessary. > > At least one difference is that all names change from T
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Samstag, den 10.08.2019, 17:50 -0400 schrieb James Richters: > I'm making an attempt to copy TUSBPseudoHIDInterface into > libusboop.pas. I've made the recomended name changes and then tried > to compile it. Some things I found like the names changing from > things like > > PUSBInterfaceDescriptop to Plibusb_interface_descriptor OK, there are two things. Names directly from libusb-1.0 (as used in libusb.pas) should be identical to the original C code, i.e., Plibusb_interface_descriptor as you've written. The second thing are the classes in the OOP wrapper in libusboop.pas. Please use CamelCase for them, e.g., TLibusbPseudoHIDInterface. > are pretty obvious, but just taking a guess on other things like: > > changing: > if (EP.bmAttributes and USB_ENDPOINT_TYPE_MASK = > USB_ENDPOINT_TYPE_INTERRUPT) and > (EP.bEndpointAddress and USB_ENDPOINT_DIR_MASK <> 0) then > > To: > if (EP^.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = > LIBUSB_TRANSFER_TYPE_INTERRUPT) and > (EP^.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) > then Yes, very good, thanks! Whether EP is a pointer (--> EP^.bmAttributes) or a record (EP.bmAttributs) just depends on the usage in the code. As I see in usb.pas in line 846, in TUSBPseudoHIDInterface.Create, it is actually the record, so you should stay without the '^'. > Based on looking at something similar in libusbutil... but I'm not > sure it's right at all I'm not sure if USB_ENDPOINT_TYPE_MASK was > really changed to LIBUSB_TRANSFER_TYPE_MASK or if something else > happened. But at least it compiles... You translated it correctly. > but now I've hit a few items that I just don't know what to do > with.I can't find anything similar to get a reference from: > > libusboop.pas(1198,28) Error: Identifier not found "USB_TYPE_CLASS" Use LIBUSB_REQUEST_TYPE_CLASS. > libusboop.pas(1199,5) Error: Identifier not found > "USB_REQ_HID_SET_REPORT" > libusboop.pas(1216,27) Error: Identifier not found "USB_TYPE_CLASS" > libusboop.pas(1217,5) Error: Identifier not found > "USB_REQ_HID_GET_REPORT" > libusboop.pas(1227,23) Error: Identifier not found > "HID_REPORT_TYPE_OUTPUT" Please copy the constants USB_REQ_HID_* and HID_REPORT_* from libusb.pas (branch master) lines 248-257 to the interface section of libusboop.pas (branch libusb-1.0) directly above the class declaration of TLibusbPseudoHIDInterface. Then please rename USB_REQ_HID_* to LIBUSB_REQUEST_HID_* and HID_REPORT_* to LIBUSB_HID_REPORT_*. > I've tried things that seem to be in line with other changes, like > changing USB_Type_Class to LIBUSB_TYPE_CLASS or spelling out REQUEST > instead of REQ which also seems to be done in other places, but still > the identifiers are not found... the problem is I have no idea where > these identifiers were/are defined. > > I made a fork in github and a branch called "test" here: > https://github.com/Zaaphod/pas-libusb/tree/Test Great approach, thanks, then we can use pull requests. Thanks Hansi > > Actually you could copy the class TUSBPseudoHIDInterface (plus the > > types THIDReport and TIntrReportFunc) from usb.pas to libusboop.pas > > and change everything necessary. > > At least one difference is that all names change from TUSB* to > > TLibUsb*. I'm sure there are more, but I don't know by heart. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I'm making an attempt to copy TUSBPseudoHIDInterface into libusboop.pas. I've made the recomended name changes and then tried to compile it. Some things I found like the names changing from things like PUSBInterfaceDescriptop to Plibusb_interface_descriptor are pretty obvious, but just taking a guess on other things like: changing: if (EP.bmAttributes and USB_ENDPOINT_TYPE_MASK = USB_ENDPOINT_TYPE_INTERRUPT) and (EP.bEndpointAddress and USB_ENDPOINT_DIR_MASK <> 0) then To: if (EP^.bmAttributes and LIBUSB_TRANSFER_TYPE_MASK = LIBUSB_TRANSFER_TYPE_INTERRUPT) and (EP^.bEndpointAddress and LIBUSB_ENDPOINT_DIR_MASK <> 0) then Based on looking at something similar in libusbutil... but I'm not sure it's right at all I'm not sure if USB_ENDPOINT_TYPE_MASK was really changed to LIBUSB_TRANSFER_TYPE_MASK or if something else happened. But at least it compiles... but now I've hit a few items that I just don't know what to do with.I can't find anything similar to get a reference from: libusboop.pas(1198,28) Error: Identifier not found "USB_TYPE_CLASS" libusboop.pas(1199,5) Error: Identifier not found "USB_REQ_HID_SET_REPORT" libusboop.pas(1216,27) Error: Identifier not found "USB_TYPE_CLASS" libusboop.pas(1217,5) Error: Identifier not found "USB_REQ_HID_GET_REPORT" libusboop.pas(1227,23) Error: Identifier not found "HID_REPORT_TYPE_OUTPUT" I've tried things that seem to be in line with other changes, like changing USB_Type_Class to LIBUSB_TYPE_CLASS or spelling out REQUEST instead of REQ which also seems to be done in other places, but still the identifiers are not found... the problem is I have no idea where these identifiers were/are defined. I made a fork in github and a branch called "test" here: https://github.com/Zaaphod/pas-libusb/tree/Test Any advice is greatly appreciated James > Actually you could copy the class TUSBPseudoHIDInterface (plus the types > THIDReport and TIntrReportFunc) from usb.pas to libusboop.pas and change > everything necessary. > At least one difference is that all names change from TUSB* to TLibUsb*. I'm > sure there are more, but I don't know by heart. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi Hansi, Thanks for the sample programs and information. I'm going to try to do as you suggest and try to translate to the new libusb-1.0.. I'm not sure I'll understand it enough but it seems like it's heading in the right directions so would be worth a try. James -Original Message- From: fpc-pascal On Behalf Of Johann Glaser Sent: Friday, August 9, 2019 7:33 PM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hi! Am Freitag, den 09.08.2019, 08:08 -0400 schrieb James Richters: > Hi Hansi, > Thanks for the explanation. > > Here's the python code I’m trying to port over to FPC: > https://github.com/wolfmanjm/kivy-smoothie-host/blob/master/modules/hb > 04.py > > it uses functions like hid.open, hid.close, hid.read, hid.write, and > hid.send_feature_report I'm trying to figure out how to somehow get > similar functions to those in FPC. Some example of how to perform > those kinds of functions would be extremely helpful! These hid.open, hid.close, ... functions are all methods of the object "hid", which was previously assigned to from devices[0] (line 68), which itself was returned from en.find(), where en is an object of Enumeration() from the package easyhid. To communicate with USB HID devices, please peek into the outdated branch “master” of pas-libust (for legacy libusb-0.1) and open file src/usb.pas. This is the old analogous to the new libusboop.pas. It has the class TUSBPseudoHIDInterface which implements basic communication with USB HID devices. I've used that for a project with a barcode scanner. Please find attached the two files snapi.pas (implementing the "standard" SNAPI for barcode scanners, which is based on USB HID), and barcodescannersymbolms4407.pas (implementing a few more specific methods for a Symbol MS4407 barcode scanner). The latter file uses several units of my project, therefore it will not compile on your host. It is just to see how to use the SNAPI devices. I release these files with the same license as libusboop.pas. Please excuse that these files are still based on the outdated pas- libusb for the old libusb-0.1. Therefore they would need translation for the newer libusb-1.0 stuff. Unfortunately I've never head time to transition the project. Actually you could copy the class TUSBPseudoHIDInterface (plus the types THIDReport and TIntrReportFunc) from usb.pas to libusboop.pas and change everything necessary. At least one difference is that all names change from TUSB* to TLibUsb*. I'm sure there are more, but I don't know by heart. Please also excuse that I can’t recall why its just “PseudoHID” and not a fully-fledged HID. Probably I didn’t implement all HID functions, or the SNAPI HID interface just isn't registered with descriptor type $21. This brings me to the second topic, where you got the message Unknown descriptor type $21 with length 9 from test2controlsync. That's a HID descriptor (see LIBUSB_DT_HID). It is just not decoded in test2controlsync. And finally, the third point regarding the bug with PortPath index. I've fixed that now and pushed to Github. Thanks for pointing this out! Thanks Hansi > -Original Message- > From: fpc-pascal On Behalf > Of Johann Glaser > Sent: Friday, August 9, 2019 7:17 AM > To: fpc-pascal@lists.freepascal.org > Subject: Re: [fpc-pascal] USB Human Interface Devices > > Hi! > > Just a quick reply while at work, I'll reply to all EMails in the > evening. > > First of all: Thanks for finding the bug with the index variable I vs. > J. I'll fix that in the evening. > > Secondly: You are correct, the "EZ-USB" is a specific chip family by > Cypress, e.g., AN2131, without Flash/ROM but with SRAM for the > firmware. I built a few devices with that chip, therefore I also > implemented the Pascal "driver" to download the firmware into the > "naked" device. There are also many (old) devices on the marked which > use that chip, e.g., the Keil uLink (1st generation). > > To understand how USB actually works (endpoints, in and out transfers, > control/bulk/interrupt/isochronous transfers, ...), I have learned a > lot from the Technical Reference Manual (TRM) of the EZ- USB. Just > search for it, there are plenty of sources. Chapter 1 is the > interesting one. If you directly search at the Cypress page, they will > redirect you to the successor product FX2, but its chapter 1 is nearly > identical to that of EZ-USB. > > The EZ-USB firmware download is performed with control transfers to > EP0. So you can find examples for control transfers in ezusb.pas. > > You can find example code for bulk and interrupt endpoints e.g., in > https://github.com/hansiglaser/pas-gpib/blob/mas
Re: [fpc-pascal] USB Human Interface Devices
Hi! Am Freitag, den 09.08.2019, 08:08 -0400 schrieb James Richters: > Hi Hansi, > Thanks for the explanation. > > Here's the python code I’m trying to port over to FPC: > https://github.com/wolfmanjm/kivy-smoothie-host/blob/master/modules/hb04.py > > it uses functions like hid.open, hid.close, hid.read, hid.write, and > hid.send_feature_report I'm trying to figure out how to somehow get > similar functions to those in FPC. Some example of how to perform > those kinds of functions would be extremely helpful! These hid.open, hid.close, ... functions are all methods of the object "hid", which was previously assigned to from devices[0] (line 68), which itself was returned from en.find(), where en is an object of Enumeration() from the package easyhid. To communicate with USB HID devices, please peek into the outdated branch “master” of pas-libust (for legacy libusb-0.1) and open file src/usb.pas. This is the old analogous to the new libusboop.pas. It has the class TUSBPseudoHIDInterface which implements basic communication with USB HID devices. I've used that for a project with a barcode scanner. Please find attached the two files snapi.pas (implementing the "standard" SNAPI for barcode scanners, which is based on USB HID), and barcodescannersymbolms4407.pas (implementing a few more specific methods for a Symbol MS4407 barcode scanner). The latter file uses several units of my project, therefore it will not compile on your host. It is just to see how to use the SNAPI devices. I release these files with the same license as libusboop.pas. Please excuse that these files are still based on the outdated pas- libusb for the old libusb-0.1. Therefore they would need translation for the newer libusb-1.0 stuff. Unfortunately I've never head time to transition the project. Actually you could copy the class TUSBPseudoHIDInterface (plus the types THIDReport and TIntrReportFunc) from usb.pas to libusboop.pas and change everything necessary. At least one difference is that all names change from TUSB* to TLibUsb*. I'm sure there are more, but I don't know by heart. Please also excuse that I can’t recall why its just “PseudoHID” and not a fully-fledged HID. Probably I didn’t implement all HID functions, or the SNAPI HID interface just isn't registered with descriptor type $21. This brings me to the second topic, where you got the message Unknown descriptor type $21 with length 9 from test2controlsync. That's a HID descriptor (see LIBUSB_DT_HID). It is just not decoded in test2controlsync. And finally, the third point regarding the bug with PortPath index. I've fixed that now and pushed to Github. Thanks for pointing this out! Thanks Hansi > -Original Message- > From: fpc-pascal On Behalf > Of Johann Glaser > Sent: Friday, August 9, 2019 7:17 AM > To: fpc-pascal@lists.freepascal.org > Subject: Re: [fpc-pascal] USB Human Interface Devices > > Hi! > > Just a quick reply while at work, I'll reply to all EMails in the > evening. > > First of all: Thanks for finding the bug with the index variable I > vs. J. I'll fix that in the evening. > > Secondly: You are correct, the "EZ-USB" is a specific chip family by > Cypress, e.g., AN2131, without Flash/ROM but with SRAM for the > firmware. I built a few devices with that chip, therefore I also > implemented the Pascal "driver" to download the firmware into the > "naked" device. There are also many (old) devices on the marked which > use that chip, e.g., the Keil uLink (1st generation). > > To understand how USB actually works (endpoints, in and out > transfers, control/bulk/interrupt/isochronous transfers, ...), I have > learned a lot from the Technical Reference Manual (TRM) of the EZ- > USB. Just search for it, there are plenty of sources. Chapter 1 is > the interesting one. If you directly search at the Cypress page, they > will redirect you to the successor product FX2, but its chapter 1 is > nearly identical to that of EZ-USB. > > The EZ-USB firmware download is performed with control transfers to > EP0. So you can find examples for control transfers in ezusb.pas. > > You can find example code for bulk and interrupt endpoints e.g., in > https://github.com/hansiglaser/pas-gpib/blob/master/usb/usbtmc.pas. > > I can provide more examples in the evening. > > Bye > Hansi > > > Gesendet: Freitag, 09. August 2019 um 12:09 Uhr > > Von: "James Richters" > > An: "'FPC-Pascal users discussions'" < > > fpc-pascal@lists.freepascal.org> > > Betreff: Re: [fpc-pascal] USB Human Interface Devices > > > > Maybe I am going down the wrong path trying to get > > test_arduino_with_bmp280.pas to work with my device... I think I >
Re: [fpc-pascal] USB Human Interface Devices
Hi Hansi, Thanks for the explanation. Here's the python code I’m trying to port over to FPC: https://github.com/wolfmanjm/kivy-smoothie-host/blob/master/modules/hb04.py it uses functions like hid.open, hid.close, hid.read, hid.write, and hid.send_feature_report I'm trying to figure out how to somehow get similar functions to those in FPC. Some example of how to perform those kinds of functions would be extremely helpful! Thank you for your help with this James -Original Message- From: fpc-pascal On Behalf Of Johann Glaser Sent: Friday, August 9, 2019 7:17 AM To: fpc-pascal@lists.freepascal.org Subject: Re: [fpc-pascal] USB Human Interface Devices Hi! Just a quick reply while at work, I'll reply to all EMails in the evening. First of all: Thanks for finding the bug with the index variable I vs. J. I'll fix that in the evening. Secondly: You are correct, the "EZ-USB" is a specific chip family by Cypress, e.g., AN2131, without Flash/ROM but with SRAM for the firmware. I built a few devices with that chip, therefore I also implemented the Pascal "driver" to download the firmware into the "naked" device. There are also many (old) devices on the marked which use that chip, e.g., the Keil uLink (1st generation). To understand how USB actually works (endpoints, in and out transfers, control/bulk/interrupt/isochronous transfers, ...), I have learned a lot from the Technical Reference Manual (TRM) of the EZ-USB. Just search for it, there are plenty of sources. Chapter 1 is the interesting one. If you directly search at the Cypress page, they will redirect you to the successor product FX2, but its chapter 1 is nearly identical to that of EZ-USB. The EZ-USB firmware download is performed with control transfers to EP0. So you can find examples for control transfers in ezusb.pas. You can find example code for bulk and interrupt endpoints e.g., in https://github.com/hansiglaser/pas-gpib/blob/master/usb/usbtmc.pas. I can provide more examples in the evening. Bye Hansi > Gesendet: Freitag, 09. August 2019 um 12:09 Uhr > Von: "James Richters" > An: "'FPC-Pascal users discussions'" > Betreff: Re: [fpc-pascal] USB Human Interface Devices > > Maybe I am going down the wrong path trying to get > test_arduino_with_bmp280.pas to work with my device... I think I am > confusing easyusb with easyhid which is what is used to communicate with the > device in the python code I am trying to use. It looks like easyusb is to > send firmware to a specific usb device that has no rom in it... and that's > not exactly what I'm trying to do... > > I'm trying to figure out how to open the device and read data and write data > to this device. Is there an example of how to do that with pas-libusb? > > Sorry I am so confused by all this. I feel like I'm almost to where I will > understand things again but I'm just missing something. > > James > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Hi! Just a quick reply while at work, I'll reply to all EMails in the evening. First of all: Thanks for finding the bug with the index variable I vs. J. I'll fix that in the evening. Secondly: You are correct, the "EZ-USB" is a specific chip family by Cypress, e.g., AN2131, without Flash/ROM but with SRAM for the firmware. I built a few devices with that chip, therefore I also implemented the Pascal "driver" to download the firmware into the "naked" device. There are also many (old) devices on the marked which use that chip, e.g., the Keil uLink (1st generation). To understand how USB actually works (endpoints, in and out transfers, control/bulk/interrupt/isochronous transfers, ...), I have learned a lot from the Technical Reference Manual (TRM) of the EZ-USB. Just search for it, there are plenty of sources. Chapter 1 is the interesting one. If you directly search at the Cypress page, they will redirect you to the successor product FX2, but its chapter 1 is nearly identical to that of EZ-USB. The EZ-USB firmware download is performed with control transfers to EP0. So you can find examples for control transfers in ezusb.pas. You can find example code for bulk and interrupt endpoints e.g., in https://github.com/hansiglaser/pas-gpib/blob/master/usb/usbtmc.pas. I can provide more examples in the evening. Bye Hansi > Gesendet: Freitag, 09. August 2019 um 12:09 Uhr > Von: "James Richters" > An: "'FPC-Pascal users discussions'" > Betreff: Re: [fpc-pascal] USB Human Interface Devices > > Maybe I am going down the wrong path trying to get > test_arduino_with_bmp280.pas to work with my device... I think I am > confusing easyusb with easyhid which is what is used to communicate with the > device in the python code I am trying to use. It looks like easyusb is to > send firmware to a specific usb device that has no rom in it... and that's > not exactly what I'm trying to do... > > I'm trying to figure out how to open the device and read data and write data > to this device. Is there an example of how to do that with pas-libusb? > > Sorry I am so confused by all this. I feel like I'm almost to where I will > understand things again but I'm just missing something. > > James > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
Maybe I am going down the wrong path trying to get test_arduino_with_bmp280.pas to work with my device... I think I am confusing easyusb with easyhid which is what is used to communicate with the device in the python code I am trying to use. It looks like easyusb is to send firmware to a specific usb device that has no rom in it... and that's not exactly what I'm trying to do... I'm trying to figure out how to open the device and read data and write data to this device. Is there an example of how to do that with pas-libusb? Sorry I am so confused by all this. I feel like I'm almost to where I will understand things again but I'm just missing something. James ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] USB Human Interface Devices
I had "Use STATIC in objects" turned on in compiler setings.. once I turned
that off I was able to compile libusbutil.pas successfully.
Now when I try to run it though, I am getting :Couldn't connect to device:
Access violation
I don't know why.
I don't really know what I am doing.. but here is what I did so far...
I ran test1library (which also has the line Write('->',PortPath[J]); in it... I
changed the J to an I again)
I got the list of devices, then I plugged in the one I am trying to access and
ran Test1library once again... then I saw the new device in the list, which was
this one:
Bus 2 Device 62: ID 10CE:EB93, port: 2, port path from HCD: 0->1,
Speed: 12 Mbit/s (USB FullSpeed)
So I changed the lines in testcontrolsync.pas as follow:
Const
WHB04B_VID= $10CE;
WHB04B_PID= $EB93;
Const DevVID = WHB04B_VID;
DevPID = WHB04B_PID;
Then I get this output:
Running "i:\programming\pas-libusb_test_dll\src\examples\test2controlsync.exe "
Bus 002 Device 062: ID 10CE:EB93
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor$10CE
idProduct $EB93
bcdDevice1.00
iManufacturer 1 KTURT.LTD
iProduct0
iSerialNumber 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 27
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes $80
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 3
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Unknown descriptor type $21 with length 9
So that looks promising... I don't know about the unknown descriptor, but at
least I have some information that seems reasonable.
With the same modifications to test3controlasync.pas I get this:
Running "i:\programming\pas-libusb_test_dll\src\examples\test3controlasync.exe "
Submitting control transfer
Finished Transfer, Data = 38, Status = 0, ActualLength = 18
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor$10CE
idProduct $EB93
bcdDevice1.00
iManufacturer 1
iProduct0
iSerialNumber 0
bNumConfigurations 1
Done.
So I again put my device VID and PID into test_arduino_with_bmp280.pas and got
this:
Running
"i:\programming\pas-libusb_test_dll\src\examples\test_arduino_with_bmp280.exe "
No unconfigured devices found.
Couldn't connect to device: No configured devices found.
I suspect it has something to do with the firmware.ihx file mentioned in the
comments, but I do not understand how to get that file. It says to compile
EZ-USB, but I don't know what to do with it.. When I say I compiled it, I am
referring to EZUSB.PAS that is included in pas-libusb... but that is just a
unit, and I don't know how I could use that to create this firmware.ihx file.
What is the correct procedure to obtain firmware.ihx?Is there something
else I need besides the EZUSB unit that would use that unit to create this file?
James
-Original Message-
From: fpc-pascal On Behalf Of James
Richters
Sent: Thursday, August 8, 2019 9:37 PM
To: 'FPC-Pascal users discussions'
Subject: Re: [fpc-pascal] USB Human Interface Devices
I changed the VID and PID to match the device I am trying to use and I was able
to successfully compile and run test2controlsync.pas and test3controlasync.pas,
but when I tried to use my VID and PID in test_arduino_with_bmp280.pas I can't
even compile it.. using the x86_64-win64 Text IDE I get the following:
Warning: PIC directive or switch ignored
Hint: End of reading config file
I:\Programming\FPC\W64_Trunk\Bin\x86_64-win64\fp.cfg
libusbutil.pas(35,63) Error: Constructor name must be INIT
libusbutil.pas(45,78) Error: Constructor name must be INIT
libusbutil.pas(58,50) Error: Constructor name must be INIT
libusbutil.pas(73,108) Error: Constructor name must be INIT
libusbutil.pas(76,1) Fatal: There were 4 errors compiling module, stopping
libusbutil.pas(0) Fatal: Compilation aborted
