Delphi 7, mit USB auf Cypress CY7C68013 FX2 zugreifen

[max pack]

Hallo Delphi-Profis,
wer kann mir sachlich helfen?
Bitte keine Antworten wie: Guck mal in der Microsoft API-Doku, schreib doch einfach ein Beispiel von C/C++ in Delphi um usw.
Würde ich das können, würde ich hier nicht fragen sondern hätte es schon gemacht. Dazu habe ich viele techn. Dokus (auch vom Hersteller Cypress mit mehreren hundert Seiten) gelesen über USB, stundenlange Recherchen im Internet usw. Konnte aber bisher nichts Brauchbares finden. Die bekannte LibUSB (Delphi-libusb-master 1.0.zip) ist für Delphi 10.xx oder höher. Bei der Umstellung für D7 verzweifele ich, es sind einfach zuviele Fehler und Einzelbaustellen, mit denen ich als Feierabendprogrammierer mit vertretbarem Aufwand in begrenzter Zeit nicht mehr weiter komme.

Meine Ausgangssituation:
------------------------
-Win 11 (64bit) und Delphi 7 (32bit). Daran ist Nichts zu ändern.
-USB-Gerät: NoName Logic-Analyzer mit 8 Digitaleingängen, ohne Doku und ohne Software. Nach meiner Kenntnis ist da ein Cypress CY7C68013A (Derivat vom 8051) mit entsprechender Firmware drinnen.

Das Gerät funktioniert, getestet mit fertiger Software anderer Hersteller. Ich benötige aber nicht eine grafische Darstellung der Digitaleingänge, sondern die Zustände (0/1) als Daten, damit ich diese Signale selbst weiter verarbeiten kann.

-Zugriff auf USB-Gerät über die WinUSB.dll aus dem Ordner ...\Win\system32\..., weil die auf jedem Rechner mit Win vorhanden ist.
-Anschluss Hardware: USB 2.0-Port oder USB 3 macht keinen Unterschied.

Ausführung bisher:
------------------
-Treiber mit dem Zadig 2.x erzeugt, der anscheinend auch funktioniert
-Herzstück meines bisherigen Programms ist eine C-Datei in Pascal umgeschriebene Datei für den Zugriff auf die WinUsb.dll, stammt aus dem Internet.
-Programm bisher:

-WinUsb_QueryPipe(Handle,1,zaehler,@Info): Liefert ein richtiges Handle, richtige PID + VID und plausible Pipe-Infos zurück. Gerät arbeitet im Bulk-Verfahren. Funktioniert also.

-WinUsb_ReadPipe(Handle,$81,@buffer,sizeof(buffer), EmpfangeneBytes,nil):
Handle, Endpoint, Buffer und Buffergröße funktionieren.
Aber: Bei den empfangenen Bytes wird nur 0 angezeigt, im Puffer stehen aber 64 bzw. 512 Bytes als Hexadezimalwerte.
Warum nicht die Anzahl der Bytes im Buffer?

Fragen:
-------
-Wie kriege ich es hin, dass x Bytes (je nach reservierter Puffergröße, z.B. 512) mir als empfangene Bytes angezeigt werden?
-Woher bekomme ich nun die gewünschten Daten der acht Digitaleingänge aus ReadPipe, oder gibt es noch andere Aufrufe dafür?
-Wie sind die Daten im Buffer (Eingang, Endpoint $81) zu interpretieren, sind darin vielleicht irgendwo die acht Digitaleingänge versteckt? Wenn ja, wo?
Gibt es dafür ein brauchbares Datenprotokoll (z.B in der Form Byte 0: Start, Byte 1: 8 Bit Daten, Byte 2: Zeitstempel, Byte 3: CRC...)?
In der chaotischen Doku von Cypress konnte ich unverständlicherweise nichts brauchbares finden. Für die Descriptoren gibts sowas, für den Datenempfang nicht. Hört sich komisch an, ist aber (anscheinend) so.


Wäre schön, wenn sich hiermit jemand auskennt und mich in diese Feinheiten der
USB-Geheimnisse einweihen könnte.
Vielen Dank an alle Kenner und Könner!

[Alter Mann]

Moin,
habe mal bei mikrocontroller.net nach CY7C68013A gesucht.
Im Beitrag Benötige Hilfe bei Einstieg in Cypress CY7C68013a USB - I2C Programmierung wird die CyUSB.dll verwendet, was mich zu GitHUB
führte.
Wäre das nicht etwas für Dich?.

[himitsu]

Wenn das Ding so ein Ding sich selbst als COM-Port via USB ausgibt
und am Besten noch einen der 2 bzw. 3 Standard-Chipsätze nutzt oder kompatibel dazu ist,
oder es einen Treiber gibt, welcher im System einen virtuellen COM-Port bereit stellt,
dann ist es eigentlich ganz einfach und mit Hausmittelchen (ComPort-Komponente bzw. Terminal) zu realisieren.

Was das Ding für ein Protokoll über USB nutzt, hab ich auf die schnelle nicht erkennen können,
und ob man da einfach mit "Standardsachen" z.B. über die SetupAPI auf das USB-Device zugreifen könnte,
aber steht bestimmt alles in der Doku.
https://www.infineon.com/dgdl/Infine...7d0ec9f7974252

Bei speziellen Treibern, mit 'ner zu komplexen API, wird es dann schwieriger.

Hier scheint es eine DLL zu geben (wie Vorgänger erwähnte), wofür du meistens "nur" eine passende Unit mit den DLL-Exports benötigst,
und schon kannst du die Funktionen dieser DLL einfach aufrufen ... je nachdem, wie kompliziert oder pervers diese API dann aufgebaut ist, kann es einfach oder schlimm werden.

Falls es eine C++-Header-File für die DLL gibt, und es nicht extrem viele Funktionen sind, dann wäre es wohl nicht so aufwändig, das in eine Delphi-Unit zu übersetzen.


Es gibt/gab wohl auch schon Projekte, wo jemand das Ding auf einen DruckerPort umgebogen hat
und darüber via DeviceIoControl auf den RAM (Speicher) des Chips zugreift.
https://www-user.tu-chemnitz.de/~heh...LPT/api.en.htm



https://www.edaboard.com/threads/del...fx2-usb.24193/

Zitat von Alter Mann:

GitHUB

HID ... lange her und selbst nie wirklich genutzt.
Bissl schade, dass unsere beiden foreneigenen Experten, zu diesem Thema, verstorben sind.

https://github.com/kategray/CyUSB/bl.../src/CyAPI.cpp
https://github.com/kategray/CyUSB/tr...ibrary/cpp/inc
Ich seh da jetzt keine Exports für eine DLL (oder übersehn), falls man es mit einem C++-Compiler zu einer DLL kompilieren würde/könnte,
aber vermutlich kann man den Code davon nach Delphi übersetzen und dann letztendlich via DeviceIoControl direkt mit dem USB-Gerät reden,
falls das ganze kompatibel zum eigenen Gerät und dessen Firmware ist.

CyAPI.cpp -> CCyFX3Device würde scheinbar die eigentliche API darstellen, deren Funktionen du dann selbst ansprechen würdest (nach Aufbau der Verbindung).

[Alter Mann]

Noch etwas zum stöbern:

DLL für Cypress CyUSB Treiber erstellen

[max pack]

Vielen Dank Alter Mann und himitsu für die schnellen Antworten.
Ich habe nach dutzenden von Stunden gefühlt schon das ganze Internet durchsucht nach einer Lösung bzw. wenigstens nach einer neuen Idee, daher kannte ich die hier vorgeschlagenen Seiten schon. Leider hilft mir das bei meinem Problem nicht weiter. Ich bin offen für weitere Lösungsansätze, vielen Dank und Gruß.

[Alter Mann]

Hi,

reden wir hier von so einenm Teil (wie im Anhang)?.