[fpc-pascal] USB Human Interface Devices

[James Richters]

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 "<address of procedure(Plibusb_transfer);StdCall>" expected "<procedure variable type of procedure(Plibusb_transfer);CDecl>"
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 <fpc-pascal-bounces at lists.freepascal.org> On Behalf Of Stefan V. Pantazi
Sent: Saturday, August 17, 2019 12:11 PM
To: fpc-pascal at 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 at lists.freepascal.org 
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

--
_______________________________________________________
_______________________________________________
fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal