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
e 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
> *
. 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
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
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
: 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
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
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
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
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
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
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
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
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
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
(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
.
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
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:
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
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...
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
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:
eed 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 Interfa
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.
>
] 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
: 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
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
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
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
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,
>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
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
.
James
-Original Message-
From: fpc-pascal On Behalf Of Stefan
V. Pantazi
Sent: Wednesday, August 21, 2019 10:20 PM
To: fpc-pascal@lists.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
On 8/21/19 6:35 PM, James Richters wrote:
> I had them separated, but whene
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
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
: 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
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
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
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
-
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
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
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,
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
160
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
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
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
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
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
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
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
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
@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
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
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
>>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
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
essor 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 Interfa
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
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
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
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
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
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
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
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
all 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 c
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
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
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
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
Le 17/08/2019 à 15:00, James Richters a
écrit :
Function
TLibUsbInterface.FindEndpoint(MatchFunc :
TLibUsbEndpointMatchMethod) : Plibusb_endpoint_descriptor;
MatchFunc(ED) is where the access
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
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
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
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:
>>>
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
>>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.
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.
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
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
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
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
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
r 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
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
>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
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,
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
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).
> >
>>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
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 Mess
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:
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
>
>
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
-
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.
>
hub. 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
-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
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 communicat
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
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: R
1 - 100 of 156 matches
Mail list logo
