Re: [fpc-pascal] USB Human Interface Devices

2019-08-10 Thread 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 

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

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... 
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"
libusboop.pas(1199,5) Error: Identifier not found "USB_REQ_HID_SET_REPORT"
libusboop.pas(1216,27) Error: Identifier not found "USB_TYPE_CLASS"
libusboop.pas(1217,5) Error: Identifier not found "USB_REQ_HID_GET_REPORT"
libusboop.pas(1227,23) Error: Identifier not found "HID_REPORT_TYPE_OUTPUT"

I've tried things that seem to be in line with other changes, like changing 
USB_Type_Class to LIBUSB_TYPE_CLASS or spelling out REQUEST instead of REQ 
which also seems to be done in other places, but still the identifiers are not 
found... the problem is I have no idea where these identifiers were/are defined.

I made a fork in github and a branch called "test"  here:
https://github.com/Zaaphod/pas-libusb/tree/Test

Any advice is greatly appreciated

James



> Actually you could copy the class TUSBPseudoHIDInterface (plus the types 
> THIDReport and TIntrReportFunc) from usb.pas to libusboop.pas and change 
> everything necessary.

> At least one difference is that all names change from TUSB* to TLibUsb*. I'm 
> sure there are more, but I don't know by heart.

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


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

2019-08-10 Thread Mgr. Janusz Chmiel


I Am very sad, that I do not know, how to correctly call The following 
function from bass.so when running apps produced by FPCJVM Android 
target mode.
    class function BASS_StreamCreateURL(para1: JLString; para2: jint; 
para3: jint; para4: CUBBASS.InnerDOWNLOADPROC; para5: JLObject): jint; 
static; overload;
Because build in Android Mediaplayer API are very slow when opening 128 
KB/S MP3 live streams even on fast WIFI sites.
So it is really necessary to use bass.so, since it load data very fast 
and allocates much more less RAM.
But problem is, that there is no easy solution to call bass.so library 
and native libraryes in general. Believe Me, simply using external 
keyword or other command to load library is not enough.
It is necessary to pack .so library inside .jar archive. And this 
archive must also contain compiled Java classes.


My issue is, that I do not know, how to call this function correctly. 
Sure, I must initialise bass library first by The following line.

bass.BASS_Init(-1, 44100, 0);
bass.BASS_StreamCreateURL('http://icecast8.play.cz/cro1-128.mp3', 
0,0,sta,h);


But powerful Dex creator do not like my approach with JLobject. I have 
simply declared h as JLobject by using var command.
And this is very probably non sense for DEX creator. COmpiler do not 
assigned my wrong behaviour as bug, but DEX converter yes.

And this is significant warning, that I AM doing something wrong.
Here is The complete source code.
I Am working with Pandroid from MR  Cvijanovic. He is really 
professional and without his support, I could never know PPCJVM and 
Android API functions so much.

unit Test1;


{$mode objfpc}{$H+}
{$modeswitch unicodestrings}
{$namespace zeljus.com.test1}

interface

uses androidr15, Rjava, AActivity, StdCtrls, ZCBass;



type
  MainActivity = class(Activity)
  public
    procedure onCreate(savedInstanceState: AOBundle); override;
  public
    bass: CUBBASS;
sta: CUBBASS.InnerDOWNLOADPROC;
  end;

implementation


procedure MainActivity.onCreate(savedInstanceState: AOBundle);
var
  layout : AWLinearLayout;
h : JLObject;

begin
  inherited onCreate(savedInstanceState);
  layout:= AWLinearLayout.Create(Self);
  layout.setOrientation(AWLinearLayout.VERTICAL);

  bass:= CUBBASS.create();
bass.BASS_Init(-1, 44100, 0);
bass.BASS_StreamCreateURL('http://icecast8.play.cz/cro1-128.mp3', 
0,0,sta,h);

  setContentView(layout);

end;

end.


___
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

2019-08-10 Thread James Richters
Hi Hansi, 

Thanks for the sample programs and information.   I'm going to try to do as you 
suggest and try to translate to the new libusb-1.0.. I'm not sure I'll 
understand it enough but it seems like it's heading in the right directions so 
would be worth a try.

James

-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 the explanation.
>
> Here's the python code I’m trying to port over to FPC:
> https://github.com/wolfmanjm/kivy-smoothie-host/blob/master/modules/hb
> 04.py
>
> it uses functions like hid.open, hid.close, hid.read, hid.write, and
> hid.send_feature_report   I'm trying to figure out how to somehow get
> similar functions to those in FPC.   Some example of how to perform
> those kinds of functions would be extremely helpful!

These hid.open, hid.close, ... functions are all methods of the object "hid", 
which was previously assigned to from devices[0] (line 68), which itself was 
returned from en.find(), where en is an object of
Enumeration() from the package easyhid.

To communicate with USB HID devices, please peek into the outdated branch 
“master” of pas-libust (for legacy libusb-0.1) and open file src/usb.pas. This 
is the old analogous to the new libusboop.pas.

It has the class TUSBPseudoHIDInterface which implements basic communication 
with USB HID devices.

I've used that for a project with a barcode scanner. Please find attached the 
two files snapi.pas (implementing the "standard" SNAPI for barcode scanners, 
which is based on USB HID), and barcodescannersymbolms4407.pas (implementing a 
few more specific methods for a Symbol MS4407 barcode scanner). The latter file 
uses several units of my project, therefore it will not compile on your host. 
It is just to see how to use the SNAPI devices. I release these files with the 
same license as libusboop.pas.

Please excuse that these files are still based on the outdated pas- libusb for 
the old libusb-0.1. Therefore they would need translation for the newer 
libusb-1.0 stuff. Unfortunately I've never head time to transition the project. 
Actually you could copy the class TUSBPseudoHIDInterface (plus the types 
THIDReport and TIntrReportFunc) from usb.pas to libusboop.pas and change 
everything necessary.

At least one difference is that all names change from TUSB* to TLibUsb*. I'm 
sure there are more, but I don't know by heart.

Please also excuse that I can’t recall why its just “PseudoHID” and not a 
fully-fledged HID. Probably I didn’t implement all HID functions, or the SNAPI 
HID interface just isn't registered with descriptor type $21.

This brings me to the second topic, where you got the message
  Unknown descriptor type $21 with length 9 from test2controlsync. That's a HID 
descriptor (see LIBUSB_DT_HID). It is just not decoded in test2controlsync.

And finally, the third point regarding the bug with PortPath index.
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 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, the "EZ-USB" is a specific chip family by 
> Cypress, e.g., AN2131, without Flash/ROM but with SRAM for the 
> firmware. I built a few devices with that chip, therefore I also 
> implemented the Pascal "driver" to download the firmware into the 
> "naked" device. There are also many (old) devices on the marked which 
> use that chip, e.g., the Keil uLink (1st generation).
>
> To understand how USB actually works (endpoints, in and out transfers, 
> control/bulk/interrupt/isochronous transfers, ...), I have learned a 
> lot from the Technical Reference Manual (TRM) of the EZ- USB. Just 
> search for it, there are plenty of sources. Chapter 1 is the 
> interesting one. If you directly search at the Cypress page, they will 
> redirect you to the successor product FX2, but its chapter 1 is nearly 
> identical to that of EZ-USB.
>
> The EZ-USB firmware download is performed with control transfers to 
> EP0. So you can find examples for control transfers in ezusb.pas.
>
> You can find example code for bulk and interrupt endpoints e.g., in 
> https://github.com/hansiglaser/pas-gpib/blob/master/usb/usbtmc.pas.
>
> I can provide more examples in the evening.
>
> Bye
>   Hansi
>
> > Gesendet: Freitag, 09. August 2019 um 12:09 Uhr
> > Von: "James Richters" 
> > An: "'FPC-Pascal users discussions'" < 
> > fpc-pascal@lists.freepascal.org>
> > Betreff: Re: [fpc

Re: [fpc-pascal] Challenge accepted

2019-08-10 Thread Michael Van Canneyt



On Sat, 10 Aug 2019, Marco van de Voort wrote:



Op 2019-08-10 om 17:30 schreef Joost van der Sluis:



And who else wanna help?


Why not simply port superobject?


2 reasons:
1. Interface based. Really bad idea.
2. JSON only.

And if you need more reasons: the jsonrtti has just this. 
I still need to add some functionality to it from the restbase unit (dynamic

arrays) but other than that I've been using it since ages.

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


Re: [fpc-pascal] Challenge accepted

2019-08-10 Thread Marco van de Voort


Op 2019-08-10 om 17:30 schreef Joost van der Sluis:



And who else wanna help?


Why not simply port superobject?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


[fpc-pascal] Challenge accepted

2019-08-10 Thread Joost van der Sluis

Hi all,

Few months ago I read somewhere on the fpc-mailinglists that someone 
stated that FPC is fine, but it could use more additional stuff.


I really searched, but I can not find the original mail anymore. But I 
want to accept that challenge.


One of the thinks I think the Pascal-world is still missing is a good 
streaming library. Or, in fact I mean more something for 
(de-)serializing objects.


Normally I just start coding on such a project, but maybe we can make it 
more of a group-project.


First of all, we have to get some functional specifications. Let me start:

At least it should be able to:
- stream to XML, Json and binary formats
- Selecting the format should be done by some sort of dependency-injection
- It should be possible to omit fields based on the whole class, but 
also based on a single instance of the class

- It should be possible to stream to/from *all* classes
- Classes can modify how they are streamed by implementing some 
interfaces. (Maybe later also based on attributes)
- It should also be possible to let the 'outer world' decide how a class 
should be streamed.

- It must be possible to change how properties are 'formatted'

I can go on, but these are the most important I can think of now.

At the moment I'm thinking about a design in which there is some class 
which defines how the class has to be mapped to the stream. Then this 
'map' and the instance of the class are given to some other class that 
does the streaming, using the right (injected) stream-format.


Normally I would submit such code to fpcprojects (svn) but maybe Michael 
can help setting up a git-repository in the new fpc git-environment we 
are currently testing with?


And who else wanna help?

Regards.

Joost.


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