Re: [fpc-pascal] USB Human Interface Devices

2019-08-12 Thread 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.

>>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

2019-08-12 Thread Johann Glaser
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 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: I

Re: [fpc-pascal] PPCJVM Android target and bass library function call issue

2019-08-12 Thread Mgr. Janusz Chmiel
Yes, Raspberry Pi  is very interesting device. It is possible to run 
Linux distributions by using it, it have several USB ports, BLuetooth. 
In fact, here is a solution for Android, but it is interpreter language. 
RFO Basic. If user uses Gw library, which uses Basic commands in 
conjunction with Javascript, Webview Android system app, which is 
responsible to interpret WEB content can play live radio, video and it 
is even possible to create GUI without using numbers.

But.
Webview must create his own little GUi, his own player, to user must 
press button for twice. For one time from main app GUI, for second time 
when WEBview opens player.
I have found out, that if I would like to develop GUI by using Pascal 
language for Android, The best solution is really Pandroid. Because 
objects can be created. Sure. Every button, or other object must be 
declared at The begin, then some lines of code must be added at The 
other part of .pas source or .lpr source code.

Thank you very much for yours advice and for yours time.
.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] PPCJVM Android target and bass library function call issue

2019-08-12 Thread Jean SUZINEAU

Le 11/08/2019 à 11:43, Mgr. Janusz Chmiel a écrit :
Thank you very much for yours patience. The reason why I want to use 
my own little Internet radio player is The fact, that GUI is simple, 
many other radio apps are full of functions and of many buttons. I 
want to simple pause, play or stop.
I were wondering if a Raspberry Pi could be useful for you. Sure, the 
hardware part would be more difficult for you, and you may need an 
external battery, but it's easier to program than Android. Freepascal 
and Lazarus  can run  directly on it. I think that you can even make 
buttons with a single wire, it's called something like capacitive 
sensor. I made an electronic bagpipe with an arduino with split pins 
(attaches parisiennes) as keys. Each split pin is connected to the 
arduino through a single wire. when you touch the split pin, it changes 
its capacitance, and this can be detected by program.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] += property bug?

2019-08-12 Thread Sven Barth via fpc-pascal
Martok  schrieb am Mo., 12. Aug. 2019, 10:18:

> Am 12.08.2019 um 09:40 schrieb Michael Van Canneyt:
> >
> > This question pops up from time to time since 15 years if not more.
>
> Fun fact: questions asking why this doesn't work have a higher Google
> ranking
> than the manual for "COPERATORS" ;-)
>
> @Ryan: as with all things FPC, ignore the manual, read the parser:
> <
> https://github.com/graemeg/freepascal/blob/4e6c609/compiler/pexpr.pas#L221
> >
>
> Turns out c-operators do not actually translate to their long form but
> instead
> have special, duplicated handling. Because of course they do.
>

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?

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?

2019-08-12 Thread Martok
Am 12.08.2019 um 09:40 schrieb Michael Van Canneyt:
> 
> This question pops up from time to time since 15 years if not more.

Fun fact: questions asking why this doesn't work have a higher Google ranking
than the manual for "COPERATORS" ;-)

@Ryan: as with all things FPC, ignore the manual, read the parser:


Turns out c-operators do not actually translate to their long form but instead
have special, duplicated handling. Because of course they do.


-- 
Regards,
Martok


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] += property bug?

2019-08-12 Thread Michael Van Canneyt



On Sun, 11 Aug 2019, Ryan Joseph wrote:





On Aug 11, 2019, at 3:59 PM, Alexander Grotewohl  wrote:

d.x += 10; // makes even more sense



rect.axisX += 10 is a compound statement. See it makes perfect sense. :) I 
still don’t understand why the compiler and Delphi apparently thinks this is 
such a crazy idea. It's just normal stuff imo.


This question pops up from time to time since 15 years if not more.

Some operators need actual variable addresses. A property does not have an 
address.
It also becomes difficult if you have interfaces & classes or other
overloaded things.

The compiler people can give a more detailed answer.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal