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] += property bug?
On 13/08/2019 14:44, Martok wrote: > Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal: >> The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so >> except for using a temp to avoid duplicate calculation of "a" in how far is >> this >> not the long form? > > No, I meant it doesn't re-parse as its long form, which is why it has some > limitations. In this case for example handle_propertysym does not know it is > actually seeing an assignment. If the compiler would do that, the behaviour could change from what you would expect from glancing over the code, because the left-hand side would be evaluated twice instead of once. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Martok schrieb am Di., 13. Aug. 2019, 14:44: > Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal: > > The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", > so > > except for using a temp to avoid duplicate calculation of "a" in how far > is this > > not the long form? > > No, I meant it doesn't re-parse as its long form, which is why it has some > limitations. In this case for example handle_propertysym does not know it > is > actually seeing an assignment. > > I don't think the compiler can do this? Macros are expanded on the scanner > level, token stream injection is not a thing in FPC, AFAICS? > It could be done, but property support for the C operators is not *desired*. See the entry of the function you posted: properties are explicitly rejected. In general the C operators are not desired. They where added way in the past in a weak moment and I don't think they'd be added today if FPC wouldn't have them already. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] += property bug?
Am 12.08.2019 um 11:31 schrieb Sven Barth via fpc-pascal: > The code you linked converts "a += b" to "tmp := @a; tmp^ := tmp^ + b", so > except for using a temp to avoid duplicate calculation of "a" in how far is > this > not the long form? No, I meant it doesn't re-parse as its long form, which is why it has some limitations. In this case for example handle_propertysym does not know it is actually seeing an assignment. I don't think the compiler can do this? Macros are expanded on the scanner level, token stream injection is not a thing in FPC, AFAICS? -- Regards, Martok ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
