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
http://libusb.sourceforge.net/api-1.0/group__lib.html#ga5f8376b
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 ch
: 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 be
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
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 dat
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 in
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 bu
l.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 connecti
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
whi
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
n 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 abou
04 (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
eck
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 ini
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.so
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...
Maybe
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
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/initcritic
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] US
t 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 speci
ascal] 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
l@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_h
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__
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
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 ti
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, so
>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 y
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
_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.freepascal.org
Subject: Re: [fpc-pascal] USB Human Interface Devices
On 8/21/19 6:35 PM, James Richt
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 w
es
-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 w
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
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 bac
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 th
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
m?
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 tryi
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, an
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
160inhe
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 d
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#
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-en
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 a
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 manufact
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 gu
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 fi
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
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
>>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 kn
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 othe
d 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.freepasc
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
LCD
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 Cr
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 c
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 stil
ow 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 e
d 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
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 stdc
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
Le 17/08/2019 à 15:00, James Richters a
écrit :
Function
TLibUsbInterface.FindEndpoint(MatchFunc :
TLibUsbEndpointMatchMethod) : Plibusb_endpoint_descriptor;
MatchFunc(ED) is where the access
vi
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
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 fun
t.
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 wrot
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. So
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
e 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'l
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 mu
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 loo
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
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
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
>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
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 differ
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 a
Endpoint,
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
> ---
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
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
>
> PUSBInterfaceD
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 takin
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 t
x.
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 Int
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:
quot;'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 i
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 speci
re.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
T
1 - 100 of 156 matches
Mail list logo
