Win32::API und LibUSB-Win32 (gelöst) (Fragen zu Perl-Modulen)

[thread]20232[/thread]

Win32::API und LibUSB-Win32 [gelöst]

Tags: perl5 Ähnliche Threads

Leser: 12

Articles: hide open all | hide show old branches

+37 replies
rosti

2017-02-03 11:40
User since
2011-03-19
3492 Artikel
BenutzerIn
Code (perl): (dl )

1 2 3 4 5 6

Win32::API->new( "libusb0", "usb_init" ) or die $^E; => Win32::API::parse_prototype: bad prototype 'usb_init' at C:/Perl/lib/Win32/API.pm line 541.
Verstehe ich nicht. Die Funktion ist auf jeden Fall drin, das sagt die Doku und außerdem hab ich vorn paar Tagen damit einen Treiber in c programmiert.

Warum verweigert sich hier Perl???

Danke für Hinweise.
- +3 replies
- FIFO
  
  2017-02-03 15:03
  User since
  2005-06-01
  469 Artikel
  BenutzerIn
  Gib mal den Prototyp komplett an
  
  Code (perl): (dl )
  
  1 2 3
  
  Win32::API->new( "libusb0", "void usb_init()" ) or die $^E;
  
  Alternativ wäre über die Parameterliste mit "V"
  
  Edit/Ergänzung: Bei Functions,die Parameter erwarten, muss man auch auf die Calling Convention achten! Win32::API setzt __stdcall als Default! Das hat mich mal unnötig viel Zeit gekostet ... Bei Nicht-System-DLLs sind die Functions oft __cdecl (und immer bei variadic functions). Will man die calling convention angeben, so muss man den Konstruktor mit der "alten" Variante (Parametertypen und Rückgabetyp als Strings) zurückgreifen, vgl. Win32::API-Doku ...
  
  Gruß FIFO
  Last edited: 2017-02-03 16:30:44 +0100 (CET)
  Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
  - rosti
    
    2017-02-03 17:23
    User since
    2011-03-19
    3492 Artikel
    BenutzerIn
    
    Gibts doch gar nicht ;)
    
    Mit
    
    Code (perl): (dl )
    
    my $init = Win32::API->new("libusb0", "void usb_init()" ) or die $^E;
    
    Geht das durch. Mit void usb_init(void) hingegen nicht.
    
    Vielen Dank!!!
    
    Ein Grund mehr, hier mal weiterzumachen ;)
    
    --rosti
    
    PS: Hier jedoch komme ich auch nicht weiter
    
    Code: (dl )
    
    struct usb_bus *usb_get_busses(void);
    
    WARNING unknown output parameter type 'struct'... Idee?
    Last edited: 2017-02-03 18:04:39 +0100 (CET)
  - rosti
    
    2017-02-03 22:27
    
    User since
    2011-03-19
    3492 Artikel
    BenutzerIn
    
    Hi, nochmal Danke.
    
    Wie ein Pointer auf ein struct übergeben wird, ist mir klar, aber:
    
    Wenn die dll-Funktion selbst ein struct zurückgibt -- wie wird das denn in Win32::API deklariert und wie gehts damit weiter?
    
    Bitte um Hinweise und danke im Vorab.
    
    MfG
- +10 replies
- rosti
  
  2017-02-04 07:42
  User since
  2011-03-19
  3492 Artikel
  BenutzerIn
  Code (perl): (dl )
  
  1 2 3
  
  my $usb_get_busses = Win32::API->new("libusb0", "usb_get_busses()", "V", "T") or die $^E; => Win32::API invalid return type, structs and callbacks as return types not supported at C:/Perl/lib/Win32/API.pm line 309.
  
  Das wars dann wohl. Schade, ich hätte gerne ein OpenSource Perl-Modul für LibUSB_Win32 geschrieben.
  
  Edit: Deklariere ich den ReturnValue als Integer, bekomme ich einen Solchen der offensichtlich wie eine Speicheradresse aussieht -- wo meine heißbegehrten Daten liegen könnten.
  
  https://sourceforge.net/p/libusb-win32/wiki/Docume...
  
  MfG
  Last edited: 2017-02-04 08:07:38 +0100 (CET)
  - +3 replies
  - FIFO
    
    2017-02-04 08:31
    
    User since
    2005-06-01
    469 Artikel
    BenutzerIn
    
    Ein struct pointer als Rückgabetyp ist ein 'P' (oder 'N', vgl. Empfehlung in der Doku). Wenn man das struct selbst nachbaut (pack), muss man die tatsächlichen Bytegrößen kennen, incl. vielleicht nicht-Standard-alignement. Oder schau Dir mal Win32::API::Struct und diesen Abschnitt an. Das Arbeiten mit C-structs unter Win32::API ist kein wirkliches Vergnügen außer in simplen Fällen, Unicode (bzw. UTF16-LE)-Strings funktionieren z.B. nicht richtig ...
    
    Device::USB ist leider nur Linux-tauglich.
    Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
    - +2 replies
    - rosti
      
      2017-02-04 09:58
      
      User since
      2011-03-19
      3492 Artikel
      BenutzerIn
      
      2017-02-04T07:31:08 FIFO
      Ein struct pointer als Rückgabetyp ist ein 'P' (oder 'N', vgl. Empfehlung in der Doku). Wenn man das struct selbst nachbaut (pack), muss man die tatsächlichen Bytegrößen kennen, incl. vielleicht nicht-Standard-alignement. Oder schau Dir mal Win32::API::Struct und diesen Abschnitt an. Das Arbeiten mit C-structs unter Win32::API ist kein wirkliches Vergnügen außer in simplen Fällen, Unicode (bzw. UTF16-LE)-Strings funktionieren z.B. nicht richtig ...
      
      Device::USB ist leider nur Linux-tauglich.
      
      P oder N hab ich auch durch:
      
      Code (perl): (dl )
      
      1 2
      
      my $usb_get_busses = Win32::API->new("libusb0", "usb_get_busses()","V","N") or die $^E; => Die angegebene Prozedur wurde nicht gefunden
      
      Aber so schnell geb ich nicht auf ;)
      
      Ich WILL dass dass da unten auch in Perl geht:
      
      Code: (dl )
      
      1 2 3 4 5 6
      
      D:\>pxhex.exe 1A 1A F0 DB 20 0A 00 18 success: device FFFF:1122 opened success: set configuration #1 success: claim_interface #0 success: bulk write 8 bytes Done.
      
      Da hängt nämlich meine Heizung dran ;)
      - FIFO
        
        2017-02-04 11:46
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        2017-02-04T08:58:39 rosti
        
        Code (perl): (dl )
        
        1 2
        
        my $usb_get_busses = Win32::API->new("libusb0", "usb_get_busses()","V","N") or die $^E; => Die angegebene Prozedur wurde nicht gefunden
        
        Kann auch nicht gefunden werden: In der Nicht-Prototyp-Variante von new() lässt Du die Klammern nach usb_get_busses weg.
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
  - +6 replies
  - FIFO
    
    2017-02-04 08:35
    User since
    2005-06-01
    469 Artikel
    BenutzerIn
    
    2017-02-04T06:42:51 rosti
    Edit: Deklariere ich den ReturnValue als Integer, bekomme ich einen Solchen der offensichtlich wie eine Speicheradresse aussieht -- wo meine heißbegehrten Daten liegen könnten.
    
    Code (perl): (dl )
    
    $copy_of_memblock = ReadMemory($SourcePtr, $length);
    
    ... und dann unpack(). Aber wie gesagt, Du musst die Bytegrößen der struct members kennen, mit Beachtung eines evtl. veränderten alignment ...
    Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
    - +5 replies
    - rosti
      
      2017-02-04 10:11
      
      User since
      2011-03-19
      3492 Artikel
      BenutzerIn
      
      2017-02-04T07:35:54 FIFO
      2017-02-04T06:42:51 rosti
      Edit: Deklariere ich den ReturnValue als Integer, bekomme ich einen Solchen der offensichtlich wie eine Speicheradresse aussieht -- wo meine heißbegehrten Daten liegen könnten.
      
      Code (perl): (dl )
      
      $copy_of_memblock = ReadMemory($SourcePtr, $length);
      
      ... und dann unpack(). Aber wie gesagt, Du musst die Bytegrößen der struct members kennen, mit Beachtung eines evtl. veränderten alignment ...
      
      ReadMemory mit einer angenommen $length = 14 bringt mir viele binäre Nullen und dazwischen lesbar "bus-0".
      
      Code (perl): (dl )
      
      1 2 3 4
      
      my $usb_get_busses = Win32::API->new("libusb0", "int usb_get_busses()") or die $^E; my $pt = $usb_get_busses->Call; print Dumper ReadMemory($pt, 14);
      
      Ich guck mal, ob ich über das Struct weiterkomme. Es sollte dann die usb_devices liefern womit mein Stick nach Vendor-id und Product-id rausgefischt werden kann.
      
      Weitermachen ;)
      - +4 replies
      - FIFO
        
        2017-02-04 10:59
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        2017-02-04T09:11:19 rosti
        ReadMemory mit einer angenommen $length = 14 bringt mir viele binäre Nullen und dazwischen lesbar "bus-0".
        
        Wieso 14? Hast Du die struct-Definition, dann zeig doch mal ...
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +3 replies
        
        rosti
        
        2017-02-04 16:19
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Aus der Doku rauskopiert:
        
        Code (perl): (dl )
        
        1 2 3
        
        my $Point = Win32::API::Struct->new( 'POINT' ); => Unknown Win32::API::Struct 'POINT'
        
        Ja, was denn nun? Ich brauche einen Pointer auf ein Struct was ich übergeben muss.
        
        Hier weiß ich nun wirklich nicht mehr weiter. Bitte um einen Impuls ;)
        
        PS/Edit: Ich glaub ich habs jetzt kapiert. Mit untenstehenden Eigenschaften muss ich zunächst alle Structs erstellen entsprechend der usb.h
        
        Sieht z.B. so aus:
        
        Code (perl): (dl )
        
        1 2 3 4 5
        
        Win32::API::Struct->typedef('usb_device'); my $dev = Win32::API::Struct->new( 'usb_device' ); $dev->{filename} = ''; # char filename[LIBUSB_PATH_MAX]; $dev->{devnum} = 1; # unsigned char devnum;
        
        Die Frage ist noch, wie setze ich ein struct usb_device *next, *prev; in das Struct?
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
        
        DLL version: 1.2.6.0 Driver version: 1.2.6.0 bus/device idVendor/idProduct bus-0/\\.\libusb0-0001--0xffff-0x1122 FFFF/1122 - Manufacturer : HANSON - Product : USB Remote bLength: 18 bDescriptorType: 01h bcdUSB: 0110h bDeviceClass: 00h bDeviceSubClass: 00h bDeviceProtocol: 00h bMaxPacketSize0: 08h idVendor: FFFFh idProduct: 1122h bcdDevice: 0001h iManufacturer: 1 iProduct: 2 iSerialNumber: 0 bNumConfigurations: 1 wTotalLength: 34 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: a0h MaxPower: 50 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 3 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 02h bmAttributes: 03h wMaxPacketSize: 8 bInterval: 10 bRefresh: 0 bSynchAddress: 0
        
        Last edited: 2017-02-04 17:03:13 +0100 (CET)
        
        +2 replies
        
        FIFO
        
        2017-02-04 17:43
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        2017-02-04T15:19:37 rosti
        PS/Edit: Ich glaub ich habs jetzt kapiert. Mit untenstehenden Eigenschaften muss ich zunächst alle Structs erstellen entsprechend der usb.h
        
        Sieht z.B. so aus:
        
        Code (perl): (dl )
        
        1 2 3 4 5
        
        Win32::API::Struct->typedef('usb_device'); my $dev = Win32::API::Struct->new( 'usb_device' ); $dev->{filename} = ''; # char filename[LIBUSB_PATH_MAX]; $dev->{devnum} = 1; # unsigned char devnum;
        
        Die Frage ist noch, wie setze ich ein struct usb_device *next, *prev; in das Struct?
        
        Ich habe nicht mit libusb gearbeitet. Offensichtlich sind die usb_devices in einer doppelt verketteten Liste. Ob Win32::API::Struct mit struct-pointers auf selbstdefinierte structs richtig umgeht, kann ich nicht sagen. Im Zweifelsfall kannst Du versuchen, die prev/next-Zeiger in Deinem struct-typedef als void* oder sogar als long zu deklarieren. Keine Ahnung, sorry :)
        
        Good Luck,
        FIFO
        
        Edit:Achso, und Dein typedef für das usb_device-struct ist natürlich unvollständig (nur ein Name, keine Members deklariert)
        Last edited: 2017-02-04 17:46:16 +0100 (CET)
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        rosti
        
        2017-02-04 18:15
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Hi danke mein Lieber.
        
        Deinem Post entnehme ich, dass ich aufm richtigen Weg bin. Ja meine Structs sind unvollständig da wirds noch ein bischen Tipparbeit geben. Ist aber jetzt klar wo's langgeht.
        
        In c sind es ca. 200 Zeilen, wieviele es in Perl werden .... wir werden sehen. Wahrscheinlich viel mehr ;)
        
        Um die Sache abzukürzen ist es auch gar nicht notwendig, den USBus (oder gar mehrere) nach allen Devices zu durchsuchen um bspw. eine VID=0xFFFF und PID=0x1122 rauszufischen, Weil:
        
        Ich hab ja nur ein Device mit dieser ID für die LibUSB eingerichtet. Da reicht also eine einfache Prüfung ob der Dongel steckt und gut isses.
        
        Schönes Wochenende, Grüße an alle.
        
        Ich mach trotzdem zu, wer weiß wann ich damit fertig werde ;)
- +21 replies
- rosti
  
  2017-02-05 19:14
  User since
  2011-03-19
  3492 Artikel
  BenutzerIn
  Pointer- Akrobatik ;)
  ===================
  
  Struct zusammenbauen über die Speicheradressen:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14
  
  Win32::API->Import('libusb0', 'int usb_get_busses()'); my $mem_usb_bus = ReadMemory(usb_get_busses(), 532); my %usb_bus; @usb_bus{qw(next prev dirname devices location root_dev)} = unpack "VVZ512VVV", $mem_usb_bus; die Dumper \%usb_bus; $VAR1 = { 'devices' => 11880344, 'dirname' => 'bus-0', 'location' => 0, 'next' => 0, 'prev' => 0, 'root_dev' => 12579720 };
  
  Btw., die 32-bit-Integer sind little Endians, war auch nicht schwer, das rauszukriegen. So zeigt 'devices' => 11880344,
  auf die Adresse im MEM wo die Devices liegen, und siehe da ist es auch:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
  
  $VAR1 = { 'bDescriptorType' => 1, 'bDeviceClass' => 0, 'bDeviceProtocol' => 0, 'bDeviceSubClass' => 0, 'bLength' => 18, 'bMaxPacketSize0' => 8, 'bNumConfigurations' => 1, 'bcdDevice' => 1, 'bcdUSB' => 272, 'dev' => 0, 'filename' => '\\\\.\\libusb0-0001--0xffff-0x1122', 'iManufacturer' => 1, 'iProduct' => 2, 'iSerialNumber' => 0, 'idProduct' => 4386, 'idVendor' => 65535, 'next' => 0, 'prev' => 0, 'usb_bus' => 9769944, 'usb_config_descriptor' => 9769760 };
  
  Allerdings ist der Hash unvollständig. In der usb.h struct-Definition gibt es 2 Einträge, da weiß ich nicht weiter
  
  Code: (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
  
  struct usb_device { struct usb_device *next, *prev; char filename[LIBUSB_PATH_MAX]; struct usb_bus *bus; struct usb_device_descriptor descriptor; # Frage 1 struct usb_config_descriptor *config; void *dev; /* Darwin support */ # Frage 2 unsigned char devnum; unsigned char num_children; struct usb_device **children; };
  
  Pointer ist klar, der beansprucht 4 Bytes als little Endian.
  
  Frage 1: Das ist kein Pointer, wieviele Bytes muss ich da veranschlagen? sizeof(usb_device_descriptor) und die Daten als Array?
  
  Frage 2: Vermutlich 0 Bytes?
  
  Ansonsten wird das Device schonmal gefunden und die mit ReadMemory gelesenen Konfig-Daten stimmen auch, s.oben.
  
  Viele Grüße!
  - +20 replies
  - FIFO
    
    2017-02-05 22:58
    User since
    2005-06-01
    469 Artikel
    BenutzerIn
    
    2017-02-05T18:14:31 rosti
    
    Code: (dl )
    
    1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
    
    struct usb_device { struct usb_device *next, *prev; char filename[LIBUSB_PATH_MAX]; struct usb_bus *bus; struct usb_device_descriptor descriptor; # Frage 1 struct usb_config_descriptor *config; void *dev; /* Darwin support */ # Frage 2 unsigned char devnum; unsigned char num_children; struct usb_device **children; };
    
    Pointer ist klar, der beansprucht 4 Bytes als little Endian.
    
    Frage 1: Das ist kein Pointer, wieviele Bytes muss ich da veranschlagen? sizeof(usb_device_descriptor) und die Daten als Array?
    
    Frage 2: Vermutlich 0 Bytes?
    
    Die Anzahl der Bytes für einen Pointer hat mit Big/Little Endian nichts zu tun ...
    
    Frage 1: Die Größe des struct usb_device_descriptor ergibt sich aus seiner Definition im Headerfile.
    edit: Wie das struct im struct dann in den Ergebnis-Hash abgebildet wird, kann ich Dir nicht sagen. Vermutlich musst Du am Byteoffset des Members descriptor einen Bytestring-Platzhalter (Ann) in Dein unpack-Pattern setzen und diesen String dann wiederum mit einem Pattern entpacken, das der struct-Definition von usb_device_descriptor entspricht.
    
    Frage 2: void *dev ist ein Pointer, also 4 Bytes bei 32bit Adressbreite.
    Last edited: 2017-02-05 23:19:33 +0100 (CET)
    Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
    - +19 replies
    - rosti
      
      2017-02-06 07:28
      
      User since
      2011-03-19
      3492 Artikel
      BenutzerIn
      
      Hi Danke Dir!
      
      Meine Schablonen passen ja, das sind V bzw. v für die Endians, das ist nicht das Problem. Und offensichtlich liegen die Daten für struct_in_struct (war Frage 1) auch hintereinander im RAM, denn ich komm ja an die Daten ran.
      
      Mit schmiert aber die Kiste ab, wenn ich usb_oben aufrufe:
      
      Code (perl): (dl )
      
      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
      
      Win32::API->Import('libusb0', 'usb_open',"I","P") or die $^E; Win32::API::Struct->typedef( 'usb_device', "LPLONG","next", "LPLONG","prev", "CHAR","filename", # hat 512 byte "LPLONG","usb_bus", "CHAR","bLength", "CHAR","bDescriptorType", "SHORT","bcdUSB", "CHAR","bDeviceClass", "CHAR","bDeviceSubClass", "CHAR","bDeviceProtocol", "CHAR","bMaxPacketSize0", "SHORT","idVendor", "SHORT","idProduct", "SHORT","bcdDevice", "CHAR","iManufacturer", "CHAR","iProduct", "CHAR","iSerialNumber", "CHAR","bNumConfigurations", "LPLONG","config", "VOID","dev", "CHAR","devnum", "CHAR","num_children", "LPLONG","children" ); my $dev = Win32::API::Struct->new( 'usb_device'); foreach my $key(keys %usb_device){ $dev->{$key} = $usb_device{$key}} usb_open($dev);
      
      Und da weiß ich schonmal nicht, ob ich die Funktion richtig deklariert habe, in usb.h steht
      
      usb_dev_handle *usb_open(struct usb_device *dev);
      
      also, ob meine Übergabe so gesehen richtig ist?
      
      Unklar auch die typedef. So ist filename lt. struct
      
      char filename[LIBUSB_PATH_MAX];
      
      und meine Deklaration mit CHAR ist mit Sicherheit falsch -- nur wie mache ich es richtig? In Type.pm finde ich nichts passendes und die Doku gibt es auch nicht her..
      
      MfG
      - +18 replies
      - FIFO
        
        2017-02-06 20:44
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        2017-02-06T06:28:11 rosti
        Unklar auch die typedef. So ist filename lt. struct
        
        char filename[LIBUSB_PATH_MAX];
        
        und meine Deklaration mit CHAR ist mit Sicherheit falsch -- nur wie mache ich es richtig? In Type.pm finde ich nichts passendes und die Doku gibt es auch nicht her..
        
        Ahoi.
        Ich bin nicht so ganz sicher, wie routiniert Du Dich in C bewegst?! filename ist doch ein Array of char mit LIBUSB_PATH_MAX Elementen (Bytes), der Typ CHAR bezeichnet aber genau ein Byte.
        
        Es wäre besser, wenn Du mal komplett posten würdest aus usb.h (kann ich nur vermuten):
        - Die struct-Definitionen
        - Den Prototyp der usb_open-Funktion und der anderen benutzten Funktionen
        - Die Konstanten (z.B. #defines) wie LIBUSB_PATH_MAX
        oder das ganze .h-File. Ansonsten ist es hier sehr neblig ...
        
        Gruß FIFO
        
        Editiert von FIFO: Typo, Präzisierung
        Last edited: 2017-02-06 23:59:40 +0100 (CET)
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +17 replies
        
        rosti
        
        2017-02-07 06:53
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Moin,
        
        die libusb.h ist in der Anlage.
        
        Mit ist vieles unklar, ob ich die Win32::API überhaupt richtig anwende, ich verstehe die Doku einfach nicht.
        
        Win32::API->Import($self->{CFG}{dll}, 'usb_open',"T","I") or die $^E;
        
        erwartet ein struct, ist T da richtig? Ein mit Win32::API::Struct->typedef und new erstelltes struct bringt mein Programm zum Absturz. Andererseits kriege ich die komplette Konfig des USB-Gerätes korrekt ausgelesen, d.h. also,
        dass ich die Pointer-Arithmetik richtig anwende.
        
        Entweder mache ich bei der Übergabe des structs einen Fehler, oder es ist nicht richtig aufgestellt. Ein c-Programm schmiert immer dann ab, wenn es auf Speicherbereiche greift, die nicht resierviert sind.
        
        In Fakt brauche ich mal ein konkretes Beispiel für einen Funktionsaufruf mit struct-Übergabe.
        
        Das Ziel lohnt sich. Auf Win32 gibts nämlich gar nichts für USB/Perl. Wenns fertig ist haben alle was davon.
        
        Viele Grüße.
        
        PS: Als absolute Baustelle meine Perl-Lib in der Anlage.
        Anhänge
        
        text/plain
        427 lines
        lusb0_usb.h
        
        text/plain
        227 lines
        LibUSB.pm
        
        Last edited: 2017-02-07 06:55:25 +0100 (CET)
        
        +16 replies
        
        FIFO
        
        2017-02-07 06:59
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        Ok, das ist ja mal Lesestoff :) Muss jetzt erstmal arbeiten ...
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +15 replies
        
        rosti
        
        2017-02-07 07:07
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Herzlichen Dank, ich feu mich auf heut' abend.
        
        Das Ding kriegen wir zum Laufen, ein c-Beispiel ist in der Anlage (das hab ich nur geringfügig ändern müssen).
        
        USB-Gerät für die LibUSB einrichten ist hier:
        http://rolfrost.de/libusb.html
        
        Viele Grüße!
        
        PS: Und zum Sniffen am USB gibt es pcapusb ;)
        Anhänge
        
        text/plain
        239 lines
        bulk.c
        
        +14 replies
        
        FIFO
        
        2017-02-07 07:15
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        OK, mal sehen ...
        Apropos Alignment: Im lusb0_usb.h sprang mir direkt ins Auge:
        
        Code: (dl )
        
        1 2
        
        /* ensure byte-packed structures */ #include <pshpack1.h>
        
        Was steht da drin?
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +13 replies
        
        rosti
        
        2017-02-07 07:25
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Code: (dl )
        
        1 2 3
        
        #ifndef RC_INVOKED #pragma pack(push,1) #endif
        
        +12 replies
        
        FIFO
        
        2017-02-08 00:19
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        Aha. Also kann man davon ausgehen, dass die structs bytegenau im Speicher abgebildet sind (zumindest wenn RC_INVOKED nicht defined).
        
        Ich hab mal durch Dein Modul geschaut, der Kostruktor sieht ok aus, bis vor den Methodenaufrufen
        
        Code (perl): (dl )
        
        1 2 3 4 5 6
        
        $self->_get_busses; $self->_get_fst_device; $self->_get_configuration; $self->_get_interface; $self->_usb_open;
        
        In _get_busses ist nicht alles so einsichtig, hab mal Orientierungskommentare platziert:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
        
        sub _get_busses{ my $self = shift; my $usb_get_busses = Win32::API->new('libusb0', 'int usb_get_busses()'); my $bus_addr = $usb_get_busses->Call(); #print $bus_addr,"\n"; # Erstes usb_bus-struct einlesen und entpacken my $mem_usb_bus = ReadMemory($bus_addr, 532); my %usb_bus; @usb_bus{qw(next prev dirname devices location root_dev)} = unpack "VVZ512VVV", $mem_usb_bus; # In $usb_bus{devices} ist also jetzt die Adresse des ersten usb_device-structs im ersten usb_bus # ab hier ??? --------------------------------------------------- Win32::API::Struct->typedef( 'usb_bus', "INT_PTR","devices" # ??? ); my $usb_bus = Win32::API::Struct->new( 'usb_bus'); #$self->dd($usb_bus); # bis hier ??? -------------------------------------------------- $self->{usb_bus} = \%usb_bus; }
        
        Sollte aber eigentlich trotzdem klappen ... _get_fst_device scheint auf den ersten Blick ok, zumindest das unpack-Pattern. Weiter kam ich noch nicht.
        
        Ab wo bekommst Du denn Probleme?
        
        Btw halte ich es für riskant, sich auf bestimmte struct-Repräsentationen im Speicher zu verlassen. Spätere libusb-Versionen haben wahrscheinlich eine andere Datenstruktur-Grundlage.
        
        edit: Ich frag mich die ganze Zeit: Warum schreibst Du nicht eine Wrapper-DLL, die den Low-Level-Kram in C erledigt und ein einfaches Interface für Win32::API bereitstellt?
        Last edited: 2017-02-08 07:09:01 +0100 (CET)
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +11 replies
        
        rosti
        
        2017-02-08 07:10
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Herzlichen Dank!
        
        Letzter Stand siehe Anlage. Bei usb_open schmierts ab. Es ist schon möglich das ich die falschen Datentypen notiere. Und ich kann mir auch nicht vorstellen, dass ich -- so wie im derzeitigen Entwurf -- den ganzen Speicher in Structs rekonstruieren muss.
        
        In c sieht das was bis zum usb_open()-Call gemacht werden mus, so aus:
        
        Code: (dl )
        
        1 2 3 4 5 6 7 8 9 10 11 12 13 14
        
        usb_dev_handle *open_dev(void){ struct usb_bus *bus; struct usb_device *dev; for (bus = usb_get_busses(); bus; bus = bus->next){ for (dev = bus->devices; dev; dev = dev->next){ if (dev->descriptor.idVendor == MY_VID && dev->descriptor.idProduct == MY_PID){ return usb_open(dev); } } } return NULL; }
        
        D.h., ich in Perl brauchen wir nur einen Pointer auf *dev. Und dafür sämtliche Pointer's bis ins letzte Struct aufzulösen kanns eigentlich nicht sein ;)
        
        Ab sub _get_fst_device{ sollte usb_open in Fakt möglich sein. Bitte guck mal ob das device struct richtig ist und meine Deklaration der usb_open über die Win32::API.
        
        Aufgeben is nich ;)
        
        Herzlichst.
        Anhänge
        
        text/plain
        318 lines
        LibUSB.pm
        
        +10 replies
        
        FIFO
        
        2017-02-08 08:40
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        Nur kurz: Wenn Du ohnehin nur das erste Device aus dem ersten Bus nimmst, kannst Du usb_open mit dem .devices-Member aus dem usb_bus-struct aufrufen, der zeigt ja genau dorthin. _get_fst_device ist an der Stelle verzichtbar, _get_busses liefert die Info bereits.
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7 8 9 10
        
        my $mem_usb_bus = ReadMemory($bus_addr, 532); my %usb_bus; @usb_bus{qw( next prev dirname devices location root_dev )} = unpack "VVZ512VVV", $mem_usb_bus;
        
        Der Aufruf von usb_open verlangt als Parameter einen struct-Pointer, hier würde ich "P" nehmen (nicht "T") und .devices übergeben.
        Probier doch mal, was usb_open dann liefert.
        
        Win32::Struct würde ich hier ehrlich gesagt garnicht verwenden, da Du ohnehin Byte-Blocks liest und unpackst, da schafft das Abstraktionslayer nur Verwirrung ...
        
        EDIT: In Deinem C-Code iterierst Du über die busses, aber nicht im Perl-Modul.
        Last edited: 2017-02-08 08:48:14 +0100 (CET)
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +9 replies
        
        rosti
        
        2017-02-08 09:21
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Ja, danke das sehe ich ganz genauso!!!
        
        Also fürs Erste Verzicht auf die Iteration über Busses und Devices. Bus-0 abfragen und den Pointer für das erste Device an usb_open() übergeben.
        
        Die Frage ist nur, wie übersetze ich diese Übergabe mit der Win32::API???
        
        usb_open() gibt mir ja den Pointer aufs Device, in Perl hätte ich die Speicheradresse. Und wie das Struct fürs Device aussieht, was LibUSB intern verwendet, gibt nicht einmal die Header Datei her. Denn da steht lediglich:
        
        Code: (dl )
        
        void *dev /* Darwin support */
        
        Also irgendwie ist das hier ein Henne-Ei-Katze-Schwanz-Problem ;)
        
        Vlg;)
        
        +8 replies
        
        FIFO
        
        2017-02-08 09:34
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        2017-02-08T08:21:10 rosti
        usb_open() gibt mir ja den Pointer aufs Device, in Perl hätte ich die Speicheradresse. Und wie das Struct fürs Device aussieht, was LibUSB intern verwendet, gibt nicht einmal die Header Datei her.
        
        An dieser Stelle ist vermutlich Schluss, denn usb_open gibt einen Pointer auf ein struct zurück, das im Header als ADT definiert ist:
        
        Code: (dl )
        
        1 2 3 4
        
        struct usb_dev_handle; typedef struct usb_dev_handle usb_dev_handle; ... usb_dev_handle *usb_open(struct usb_device *dev);
        
        Man müsste also die usb.c-Sources haben, da steht's vermutlich drin.
        Ich hab leider nicht die Zeit, mich mit den Interna von libusb zu befassen, hatte lediglich einige Erfahrungen mit Win32::API und hoffe, dass Dich das irgendwie weiterbringt ... bin dann mal weg :)
        
        So long, FIFO
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +7 replies
        
        rosti
        
        2017-02-08 14:47
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        auf
        http://www.bribes.org/perl/ppmdir.html#ap
        
        liegt Device::USB für 5.6, 5.8 und 5.10 kompiliert mit LibUSB-Win32
        
        Dies für ein neueres Perl zu tun, scheitert bei mir daran, dass ich Inline C nicht zum Laufen kriege aufgrund einer fehlenden Entwicklungsumgebung.
        
        Vielleicht kann das mal jemand aufgreifen.
        
        vlg
        
        +6 replies
        
        FIFO
        
        2017-02-08 15:10
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        Integration von Inline::C macht (mir) unter Win32 keine Freude, für XS ~~bin ich wohl zu blöde~~ kann ich mich irgendwie nicht erwärmen, dabei hab ich sogar noch ein altes VC6 und kann ActivePerl-kompatibel kompilieren. Das für mich mit Abstand geschmeidigste Verfahren: System-/C-Funktionalitäten - wenn ich sie denn wirklich brauche - in C programmieren, in eine DLL packen, die ein simples Interface bietet. Vorteil: Kann es mit Perl, aber auch mit anderen Sprachen nutzen ...
        Last edited: 2017-02-08 16:09:12 +0100 (CET)
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +5 replies
        
        rosti
        
        2017-02-08 15:42
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Ok, Plan B:
        
        Ein eigene DLL in C erstellen. Eine pxhex.exe für meinen USB-Dongel hab ich erstellt, aber wie ich eine dll erstellen kann weiß ich nicht.
        
        Gibt mir mal bitte eine Hilfe wo ich nachlesen kann wie das geht.
        
        +4 replies
        
        FIFO
        
        2017-02-08 16:11
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        2017-02-08T14:42:25 rosti
        Gibt mir mal bitte eine Hilfe wo ich nachlesen kann wie das geht.
        
        Also bitte! Du ist doch schon groß :) Hängt von der Compiler-Umgebung ab (VC? gcc? bcc? PellesC? dmd? ...)
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        +3 replies
        
        rosti
        
        2017-02-08 16:25
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        Ich hab MinGW Msys und gcc, cpp auf der Kommandozeile.
        
        Anleitungen für VisualStudio nützen mir nichts.
        
        Ich hab eine .exe mit gcc pxhex.c -lusb auf der Kommandozeile erstellt.
        
        Auf demselben Weg muss es auch möglich sein, eine .dll zu erzeugen.
        
        Wie fange ich das an?
        
        Und ist eine so erstellte DLL dann über Win32::API nutzbar?
        
        Ich brauch ja nur ein ganz einfaches Beispiel dafür wie der Plan ist. Wenn Du sowas schonmal gemacht hast, gib es doch einfach mal weiter, ein ganz einfaches Beispiel würde mir völlig reichen.
        
        VlG
        
        +2 replies
        
        FIFO
        
        2017-02-08 16:30
        
        User since
        2005-06-01
        469 Artikel
        BenutzerIn
        
        Sample DLL MinGW/gcc
        Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan: "The Elements of Programming Style"
        
        rosti
        
        2017-02-08 16:55
        
        User since
        2011-03-19
        3492 Artikel
        BenutzerIn
        
        2017-02-08T15:30:18 FIFO
        Sample DLL MinGW/gcc
        
        Die dll hab ich schon erzeugt aber Win32::API will damit nicht.
        
        Wahrscheinlich bin ich zu doof dazu.
- +2 replies
- rosti
  
  2017-02-08 19:11
  
  User since
  2011-03-19
  3492 Artikel
  BenutzerIn
  
  Um die Sache abzuschließen
  ===========================
  
  LibUSB-Win32 ist und bleibt ein experimentelles Feature. Ich hab mich jetzt tagelang erfolglos genug an diesem Thema verheizt und lass es einfach nur gut sein (zumal ich meine persönliche Lösung ohnehin längst fertig habe als ausführbare Datei).
  
  Geräte die LibUSB-Win32 nutzbar sein sollen, müssen über den Win-Gerätemanager extra konfiguriert werden und auch nach diesem Akt behält die LibUSB-API einen Low-Level-Charakter.
  
  Einfacher im Sinne einer portablen High-Level-API wäre es feilich, ausgesuchte USB-Geräte auf einen virtuellen COM-Port umzulegen. Serial wird sowohl auf Win32 als auch Unixoiden Systemen gleichermaßen unterstützt -- da wäre nur der Layer auszutauschen und bei gleichem Code wird das Gerät direkt angesprochen.
  
  Aber das kann jeder halten wie er will ;)
  
  Danke Fifo, danke fürs Interesse,
  
  MfG
  - rosti
    
    2017-02-19 10:15
    
    User since
    2011-03-19
    3492 Artikel
    BenutzerIn
    
    ... und: Mein Versuch, über Win32::API auf LibUSB zugreifen zu wollen war absolut unsinnig und von vornherein zum Scheitern veurteilt, weil Perl ein ganz anderes Konzept vorsieht, c-structs in Perl-Code einzubinden: XS
    
    Nunja, hinterher ist man immer schlauer, auch wenn's mal wieder länger dauert ;)
    
    Viele Grüße!
    
    PS: Freilich ists ungemein einfacher ein Gerät an COMx anzusprechen. Aber USB ist nunmal der Fortschritt ;)
    
    Und ja: LibUSB ist eine klasse Idee! Das Ergbnis ist nämlich ein plattformunabhängiger CODE und das ist genau das, was der Philosophie von Perl entspricht.
    
    Schönen Sonntag ;)

View all threads created 2017-02-03 11:40.