|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 02.02.2018, 14:25 Titel: Übersetzung C nach FB |
|
|
Hallo Leute!
Wie übersetze ich die obere Zeile nach FB (leerer TYPE geht ja nicht)?
Code: | struct usb_dev_handle;
typedef struct usb_dev_handle usb_dev_handle; |
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 02.02.2018, 17:59 Titel: |
|
|
Zeile 1 vorwärts-deklariert einfach ein Struct namens usb_dev_handle. Das geht auch in FB: https://www.freebasic-portal.de/befehlsreferenz/type-forward-referencing-358.html
Zeile 2 ist einfach nur eine Abkürzung, die gerne in C verwendet wird, um nicht jedes mal vor die Deklaration einer Variable dieses Struct-Typs nicht immer "struct" schreiben zu müssen. Das ist für FB nicht relevant. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 02.02.2018, 18:50 Titel: |
|
|
Vielen Dank für die Antwort.
Dies hier Code: | Type fw_usb_dev_handle As usb_dev_handle
Type usb_dev_handle As fw_usb_dev_handle
| funktioniert, obwohl sich mir der Sinn des Konstrukts nicht ganz erschliesst, denn eine richtige Struktur usb_dev_handle wird nirgendwo definiert. Und wenn ich die zweite Zeile weglasse, hagelt es Fehlermeldungen.
Es funktioniert allerdings auch, wenn ich die zwei Zeilen durch Code: | Type usb_dev_handle As HANDLE | ersetze.
Zur Information: Ich bin gerade dabei, die Headerdatei von libusb-win32-bin-1.2.6.0 zu übersetzen. Irgendwie läuft es zwar, aber nicht ganz so wie erwartet. Bei einem Scan mit dem Beispielprogramm (ganz unten auf der Seite) bekomme ich nur einen Bus mit Namen "bus-0" angezeigt und 0 devices, obwohl ich reichlich Geräte angestöpselt habe.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 02.02.2018, 19:52 Titel: |
|
|
Solange du nicht auf die einzelnen Member der Struktur zugreifst und nur Pointer/Referenzen darauf hast, ist es völlig egal, ob sie definiert wurde oder nur vorwärts-definiert wurde. Das ist eine übliche Technik, um eben opake "Handles" zu definieren. Das zeigt ja auch dein zweiter Codeblock. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 08.02.2018, 11:58 Titel: |
|
|
Ich brauche noch einmal eure Hilfe:
C:
Code: | struct libusb_transfer;
/** \ingroup libusb_asyncio
* Asynchronous transfer callback function type. When submitting asynchronous
* transfers, you pass a pointer to a callback function of this type via the
* \ref libusb_transfer::callback "callback" member of the libusb_transfer
* structure. libusb will call this function later, when the transfer has
* completed or failed. See \ref libusb_asyncio for more information.
* \param transfer The libusb_transfer struct the callback function is being
* notified about.
*/
typedef void (LIBUSB_CALL *libusb_transfer_cb_fn)(struct libusb_transfer *transfer); |
FB:
Code: | Type fw_libusb_transfer As libusb_transfer
Declare Sub libusb_transfer_cb_fn(transfer As fw_libusb_transfer Ptr) |
Ist das richtig übersetzt, oder habe ich da was falsch verstanden?
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 08.02.2018, 14:29 Titel: |
|
|
Ein Typedef deklariert niemals eine Funktion. Der Typedef hier deklariert die zu verwendende Signatur für eine Callbackfunktion, die du an die Bibliothek übergeben kannst. Die von dir deklarierte SUB hat die richtige Signatur, aber die Übersetzung des Typedefs wäre, wenn mich die FB-Referenz nicht trügt:
Code: | Type libusb_transfer_cb_fn As Sub(transfer AS fw_libusb_transfer Ptr) |
_________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 09.02.2018, 08:39 Titel: |
|
|
Aber wo bleibt da das Sternchen aus der ersten Klammer? Laut Kommentar stellt der Type ja einen Pointer auf eine Callback - Funktion dar. Das wäre dann (nach meinem Verständnis) Code: | Type libusb_transfer_cb_fn As Sub(transfer As fw_libusb_transfer Ptr) Ptr |
Beide Varianten Compilieren ohne Fehlermeldung.
Es sind leider immer noch zu viele andere Fehler in der .bi, um einfach auszuprobieren, was richtig ist.
Gruß
grindstone
EDIT: Eigentlich müsste es in FB statt des Type ja auch ein Any Ptr tun. _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 09.02.2018, 15:48 Titel: |
|
|
Ein "AS SUB" wird meines Wissens, zumindest je nach Zusammenhang, als "AS SUB PTR" interpretiert. Möglicherweise gibt es dann beim Einsatz kleine Unterschiede (ob ein @ oder * benötigt wird o. ä.), da habe ich leider noch nicht viel gemacht.
ANY PTR gibt dem Compiler keinerlei Information über die benötigte Parameterliste - ich glaube nicht, dass das funktionieren kann.
(Bin gerade nicht an meinem Arbeitsplatz ...) _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 09.02.2018, 18:28 Titel: |
|
|
nemored hat Folgendes geschrieben: | Ein "AS SUB" wird meines Wissens, zumindest je nach Zusammenhang, als "AS SUB PTR" interpretiert. |
Ja, das sollte so stimmen - man kann eine Sub eben nur durch einen Pointer adressieren, man kann sie nicht als Objekt kopieren oder sonstwas. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 09.02.2018, 19:08 Titel: |
|
|
AUA!! *in die Tischkante beiss*
Da habe ich mich jetzt durch das Type verwirren lassen. Das ist eine ganz normale Festlegung einer Callback - Routine, nur halt mit vereinfachter Schreibweise.
Für alle, die irgendwann einmal das gleiche (Verständnis-) Problem haben sollten, hier ein kleines Beispielprogramm: Code: | Sub cb_proc(parameter As Integer) 'callback - routine
Print "CallbackParameter ";parameter
End Sub
Type cb_fn As Sub(parameter As Integer) ' "Type" statt "Dim" zur verwendung als type member
Type type_mit_callback
As Integer wert
As cb_fn callback 'callback - routine als type member
End Type
Dim As type_mit_callback cbv
With cbv
.callback = @cb_proc 'pointer auf callback - routine setzen
.wert = 5 'wert für parameter setzen
.callback(.wert) 'callback - routine aufrufen
End With
Dim As cb_fn cbr 'kann auch als normale callback - routine verwendet werden
cbr = @cb_proc
cbr(8)
Print "OK"
Sleep |
Gruß
grindstone
PS: Ach ja: Vielen Dank für die Hilfe! _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 11.02.2018, 19:21 Titel: |
|
|
Soweit habe ich die libusb.bi jetzt fertig übersetzt, aber das Testprogramm zeigt ein seltsames Verhalten: For...Next - Schleifen scheinen nicht zu funktionieren, sie brechen nicht ab. Nur, wenn ich (mit den auskommentierten Teilen) die Schleife explizit verlasse, funktioniert es.
Auch andere Variablen haben plötzlich einen anderen Wert, für mich sieht es so aus, als ob die libusb-1.0.dll (Win32) in einem Speicherbereich wildert, der ihr eigentlich gar nicht gehört.
Code: | #Include "libusb.bi"
Declare Sub printdev(dev As libusb_device Ptr)'; //prototype of the function
Dim As libusb_device Ptr Ptr devs
Dim As Long r, x
Dim As ssize_t cnt 'holding number of devices in list
r = libusb_init(NULL) 'initialize a library session
If r < 0 Then
Print "Init Error ";r' //there was an error
Sleep
End
EndIf
cnt = libusb_get_device_list(NULL, @devs) 'get the list of devices
If(cnt < 0) Then Print "Get Device Error" 'there was an error
Print cnt;" Devices in list." 'print total number of usb devices
Do While devs[x] <> 0
Print
Print "Device Nr.";x
printdev(devs[x])
x += 1
Loop
libusb_free_device_list(devs, 1) 'free the list, unref the devices in it
libusb_exit(NULL) 'close the session
Sub printdev (dev As libusb_device Ptr)
Dim As libusb_device_descriptor desc
Dim As libusb_config_descriptor Ptr config
Dim As Const libusb_interface Ptr inter
Dim As Const libusb_interface_descriptor Ptr interdesc
Dim As Const libusb_endpoint_descriptor Ptr epdesc
Dim As Long i, j, k, e
Dim As Long r = libusb_get_device_descriptor(dev, @desc)
If r < 0 Then
Print "failed to get device descriptor"
Return
EndIf
Print "Number of possible configurations: ";desc.bNumConfigurations
Print "Device Class: ";desc.bDeviceClass
Print "VendorID: ";desc.idVendor
Print "ProductID: ";desc.idProduct
e = libusb_get_config_descriptor(dev, 0, @config)
If e = 0 Then
Print "Interfaces: ";config->bNumInterfaces;" ||| "
For i = 0 To config->bNumInterfaces - 1
Print " Kontrolle: i =";i;" (max =";config->bNumInterfaces - 1;")"
inter = @config->interface[i]
Print "Number of alternate settings: ";inter->num_altsetting;" | "
For j = 0 To inter->num_altsetting - 1
Print " Kontrolle: j =";j;" (max =";inter->num_altsetting - 1;")"
interdesc = @inter->altsetting[j]
Print "Interface Number: ";interdesc->bInterfaceNumber;" | "
Print "Number of endpoints: ";interdesc->bNumEndpoints;" | "
For k = 0 To interdesc->bNumEndpoints - 1
Print " Kontrolle: k =";k;" (max =";interdesc->bNumEndpoints - 1;")"
epdesc = @interdesc->endpoint[k]
Print "Descriptor Type: ";epdesc->bDescriptorType;" | "
Print "EP Address: ";epdesc->bEndpointAddress;" | "
'If k >= interdesc->bNumEndpoints - 1 Then
' Exit For
'EndIf
Next k
'If j >= inter->num_altsetting - 1 Then
' Exit For
'EndIf
Next j
'If i >= config->bNumInterfaces - 1 Then
' Exit For
'EndIf
Next i
Else
Print
Print *libusb_error_name(e)
Print
EndIf
libusb_free_config_descriptor(config)
End Sub
? "OK"
Sleep
|
Weiß jemand Rat?
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 11.02.2018, 19:39 Titel: |
|
|
Code: | 'If i >= config->bNumInterfaces - 1 Then
' Exit For
'EndIf
|
Welchen Wert hat in diesem Fall config->bNumInterfaces? Ich kann mir das Verhalten im Moment nur erklären, wenn es dem höchsten Wert eines LONG entspricht (dann findet beim NEXT ein Überlauf statt und es geht munter im negativen Bereich weiter). _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 11.02.2018, 21:17 Titel: |
|
|
Der Wert von config->bNumInterfaces ist korrekt (je nach aktuellem Device). Aber bei einem Wert von z.B. 2 bricht die Schleife nach 2 Durchgängen nicht ab, sondern läuft immer weiter. Irgendwann stürzt das Programm dann ab.
Und wenn ich versuche, For...Next mit Code: | i = 0
Do
...
i += 1
Loop While i < config->bNumInterfaces | nachzubilden, haben die Variablen beim 2. Durchlauf irgendwelche willkürlichen Werte.
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
tom_dehn
Anmeldungsdatum: 05.10.2015 Beiträge: 30
|
Verfasst am: 13.02.2018, 02:40 Titel: |
|
|
Hallo,
auf die Gefahr, mich schrecklich zu blamieren, egal.
i,j,k sind als LONG deklariert, der Vergleichswert z.B. bNumEndpoints als uInt8_T, auf den ersten Blick also als uByte. Wenn da der Compiler ein unbedachtes CBW und/oder CWD oder wie das heissen mag reinsetzt, nee nee, das ist Quatsch...
Da könnte man trotzdem mal ansetzen.
Irgendwo erinnere ich mich auch, mal gelesen zu haben, dass ein bestimmter BASIC - Dialekt kein explizites "next i" oder "next j" mag, sondern nur pure "next"-Statements. Ob das FreeBASIC war, weiss ich nicht mehr.
Noch ne Idee: i,j,k nach "innen" verlegen:
Code: |
for Var i as uInteger (oder halt uByte) = 0 to <was weiss ich>
for Var j...
for Var k...
next k
next
next
|
...oder, noch naiver, weil i,j,k auch in der C-Source verwendet werden, schlicht als ix, ij, ik oder so benennen.
Wichtig kommt mir auch vor, genau zu ermitteln, ab wann, ab welcher Stelle denn die Variablen zu "spinnen" anfangen.
Genug blamiert meinerseits:
Viel Glück
Tom
PS:Wenn es doch was anderes ist/war, täts mich schon interessiern, wie die korrekte Lösung aussieht. |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 13.02.2018, 12:20 Titel: |
|
|
@tom_dehn:
In FreeBASIC ist ein "NEXT i" rein kosmetischer Natur. Das "i" kann angegeben werden oder nicht - der Compiler prüft nur die richtige Reihenfolge (die äußere Schleife kann nicht vor der inneren beendet werden), ansonsten dient die Angabe nur der Orientierung für den Programmierer, wirkt sich aber nicht auf den Ablauf aus. Abgesehen vom Beenden zweier Schleifen gleichzeitig z. B. mit "NEXT k, i" (was ich für ein ziemlich kurioses Konstrukt halte ...)
@grindstone:
Ggf. mal nach jeder Befehlszeile prüfen, ob die Werte noch korrekt sind (ja, ich weiß ...). Ich kann mir gerade nut vorstellen, dass entweder einer der Speicherzugriffe Murks baut, oder, wenn intern Multithreading verwendet wird, das Hauptprogramm weiterarbeitet, während der Thread noch im Speicher herumschreibt oder -liest (wobei ich in diesem Fall eher mit einem Absturz rechnen würde). _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 13.02.2018, 16:56 Titel: |
|
|
@tom_dehn:
Damit blamierst du dich nicht, die meisten dieser hartnäckigen Fehler haben eine ganz banale Ursache, allerdings meist an einer Stelle, an der man es nicht erwartet.
nemored hat Folgendes geschrieben: | Ggf. mal nach jeder Befehlszeile prüfen, ob die Werte noch korrekt sind (ja, ich weiß ...) |
Hab ich alles schon durch. Wenn ich eine Variable definiere, die mit dem restlichen Programm überhaupt nichts zu tun hat, und einen Wert hineinschreibe, steht nach dem nächsten Schleifendurchlauf was völlig anderes dort drin.
Wenn ich beispielsweise epdesc (als libusb_endpoint_descriptor Ptr dimensioniert) mit Code: | epdesc = @interdesc->endpoint[k] | einen Wert zuweise, passiert überhaupt nichts, epdesc ändert sich nicht. Dimensioniere ich epdesc als Long, funktioniert die Zuweisung.
Und gcc hat sich auch gegen mich verschworen. Damit bekomme ich die Fehlermeldung:
compiling C: C:\Programme\Programmiersprachen\FreeBASIC-1_05_0\bin\win32\gcc.exe -m32 -march=i486 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -masm=intel "test_u.c" -o "test_u.asm"
gcc.exe: error: CreateProcess: No such file or directory
compiling C failed: 'C:\Programme\Programmiersprachen\FreeBASIC-1_05_0\bin\win32\gcc.exe' terminated with exit code 1
Wenn mir da vielleicht jemand auf die Sprüge helfen könnte...?
Gruß
grindstone
EDIT:
Mit wildem Gecaste und einer gesonderten Abfrage am Ende jeder For...Next - Schleife habe ich das Programm jetzt (irgendwie) zum Laufen gekriegt.
Code: | #Include "libusb.bi"
Declare Sub printdev(dev As libusb_device Ptr)'; //prototype of the function
Dim As libusb_device Ptr Ptr devs
Dim As Long r, x
Dim As ssize_t cnt 'holding number of devices in list
r = libusb_init(NULL) 'initialize a library session
If r < 0 Then
Print "Init Error ";r' //there was an error
Sleep
End
EndIf
cnt = libusb_get_device_list(NULL, @devs) 'get the list of devices
If(cnt < 0) Then Print "Get Device Error" 'there was an error
Print cnt;" Devices in list." 'print total number of usb devices
Do While devs[x] <> 0
Print
Print "Device Nr.";x
printdev(devs[x])
x += 1
Loop
libusb_free_device_list(devs, 1) 'free the list, unref the devices in it
libusb_exit(NULL) 'close the session
Sub printdev (dev As libusb_device Ptr)
Dim As libusb_device_descriptor desc
'Dim As libusb_config_descriptor Ptr config
Dim As Long config
'Dim As Const libusb_interface Ptr inter
Dim As Long inter
'Dim As Const libusb_interface_descriptor Ptr interdesc
Dim As Long interdesc
'Dim As Const libusb_endpoint_descriptor Ptr epdesc
Dim As Long epdesc
Dim As Long i, j, k, e, s
Dim As Long r '= libusb_get_device_descriptor(dev, @desc)
r = libusb_get_device_descriptor(dev, @desc)
If r < 0 Then
Print "failed to get device descriptor"
Return
EndIf
Print "Number of possible configurations: ";desc.bNumConfigurations
Print "Device Class: ";desc.bDeviceClass
Print "VendorID: ";desc.idVendor
Print "ProductID: ";desc.idProduct
e = libusb_get_config_descriptor(dev, 0, @Cast(libusb_config_descriptor Ptr, config))
If e = 0 Then
Print "Interfaces: ";Cast(libusb_config_descriptor Ptr, config)->bNumInterfaces;" ||| "
For i = 0 To Cast(libusb_config_descriptor Ptr, config)->bNumInterfaces - 1
Print " Kontrolle: i =";i;" (max =";Cast(libusb_config_descriptor Ptr, config)->bNumInterfaces - 1;")"
'inter = @config->interface[i]
inter = Cast(Long, @Cast(libusb_config_descriptor Ptr, config)->interface[i])
Print "Number of alternate settings: ";Cast(libusb_interface Ptr, inter)->num_altsetting;" | "
For j = 0 To Cast(libusb_interface Ptr, inter)->num_altsetting - 1
Print " Kontrolle: j =";j;" (max =";Cast(libusb_interface Ptr, inter)->num_altsetting - 1;")"
interdesc = @Cast(libusb_interface Ptr, inter)->altsetting[j]
'Print "Interface Number: ";interdesc->bInterfaceNumber;" | "
Print "Interface Number: ";Cast(libusb_interface_descriptor Ptr, interdesc)->bInterfaceNumber;" | "
'Print "Number of endpoints: ";interdesc->bNumEndpoints;" | "
Print "Number of endpoints: ";Cast(libusb_interface_descriptor Ptr, interdesc)->bNumEndpoints;" | "
For k = 0 To Cast(libusb_interface_descriptor Ptr, interdesc)->bNumEndpoints - 1
Print " Kontrolle: k =";k;" (max =";Cast(libusb_interface_descriptor Ptr, interdesc)->bNumEndpoints - 1;")"
'? @interdesc->endpoint[k]
Print " epdesc1 ";epdesc, s
'epdesc = @interdesc->endpoint[k]
epdesc = @Cast(libusb_interface_descriptor Ptr, interdesc)->endpoint[k]
s = @Cast(libusb_interface_descriptor Ptr, interdesc)->endpoint[k]
Print " epdesc2 ";epdesc, s
Print "Descriptor Type: ";Cast(libusb_endpoint_descriptor Ptr, epdesc)->bDescriptorType;" | "
'Print "Descriptor Type: ";epdesc->bDescriptorType;" | "
Print " epdesc3 ";epdesc, s
'Print "Descriptor Type: ";interdesc->endpoint[k].bDescriptorType;" | "
Print "EP Address: ";Cast(libusb_endpoint_descriptor Ptr, epdesc)->bEndpointAddress;" | "
'Print "EP Address: ";interdesc->endpoint[k].bEndpointAddress;" | "
sleep
If k >= Cast(libusb_interface_descriptor Ptr, interdesc)->bNumEndpoints - 1 Then
Exit For
EndIf
Next k
If j >= Cast(libusb_interface Ptr, inter)->num_altsetting - 1 Then
Exit For
EndIf
Next j
If i >= Cast(libusb_config_descriptor Ptr, config)->bNumInterfaces - 1 Then
Exit For
EndIf
Next i
Else
Print
Print *libusb_error_name(e)
Print
EndIf
libusb_free_config_descriptor(config)
End Sub
? "OK"
Sleep
|
_________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 16.02.2018, 13:47 Titel: |
|
|
Puuh, ich habe den Fehler endlich gefunden. Die korrigierte Fassung der libusb.bi kann hier heruntergeladen werden.
Anders als andere dlls unterscheidet die libusb zwischen verschiedenen Aufrufkonventionen, abhängig vom verwendeten Betriebssystem. Für Windows muß diese auf StdCall gesetzt werden statt auf Cdecl (wie gesagt: Eine ganz banale Ursache, an einer Stelle, wo man sie nicht erwartet. )
Jetzt habe ich erst mal wieder ein neues Spielzeug!
Gruß
grindstone _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
Jojo alter Rang
Anmeldungsdatum: 12.02.2005 Beiträge: 9736 Wohnort: Neben der Festplatte
|
Verfasst am: 16.02.2018, 15:32 Titel: |
|
|
Da gibt es noch ein paar Dinge, die du aufräumen kannst, z.B.
FreeBASIC wird sich wohl nie als Microsofts C-Compiler verschleiern wollen. Der Block ist also komplett unnötig, da er nie ausgeführt werden wird.
Ebenso ist es natürlich komplett unsinnig zu prüfen, ob der verwendete FreeBASIC-Compiler C99-kompatibel ist:
Code: | #If (__STDC_VERSION__ >= 199901) |
Plot Twist: Er ist garantiert nicht C99-kompatibel.
Generell wirst du jegliche Abfragen von Makros mit zwei Unterstrichen aus dem Originalheader nicht kopieren müssen (sofern es kein explizites FB-Äquivalent dazu gibt), denn das sind vom Compiler definierte Makros, d.h. diese werden garantiert nicht in einer FB-Umgebung gesetzt sein. _________________ » Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
Nach oben |
|
|
grindstone
Anmeldungsdatum: 03.10.2010 Beiträge: 1211 Wohnort: Ruhrpott
|
Verfasst am: 16.02.2018, 16:17 Titel: |
|
|
Danke für die Hinweise. Da sind bestimmt noch einige andere überflüssige Sachen drin. Aber erstmal bin ich froh, daß das Ding überhaupt läuft. Ich war schon am Verzweifeln.
Hoffentlich tauchen nicht noch weitere Probleme auf. Die meisten der Konstanten mit den Größenangaben der Strukturen stimmen z.B. nicht. Warten wir's mal ab...
Gruß
grindstone
EDIT:
Die __FB_CYGWIN__ - Abfragen kann ich doch auch alle rausnehmen, oder? FB ist doch entweder Windows oder Linux, oder sehe ich das falsch? _________________ For ein halbes Jahr wuste ich nich mahl wie man Proggramira schreibt. Jetzt bin ich einen! |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2507 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 16.02.2018, 22:54 Titel: |
|
|
nemored hat Folgendes geschrieben: | @tom_dehn:
In FreeBASIC ist ein "NEXT i" rein kosmetischer Natur. Das "i" kann angegeben werden oder nicht - der Compiler prüft nur die richtige Reihenfolge (die äußere Schleife kann nicht vor der inneren beendet werden), ansonsten dient die Angabe nur der Orientierung für den Programmierer, wirkt sich aber nicht auf den Ablauf aus. Abgesehen vom Beenden zweier Schleifen gleichzeitig z. B. mit "NEXT k, i" (was ich für ein ziemlich kurioses Konstrukt halte ...) |
Kurz getestet: Compiler erlaubt beide Varianten. Empfehlung: Am besten Laufvariable immer bei NEXT angeben - verbessert zum einen die Code-Lesbarkeit und ergibt ausserdem eine zusätzliche Fehlerprüfung bei der Übersetzung, weil der Compiler darauf achtet, dass die richtige Schleifenvariable bei NEXT angegeben wird -> Verschachtelungsfehler produzieren bereits beim Übersetzen den nötigen Fehler, der sonst "durch die Latte gehen" könnte. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|