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)?.

[Kas Ob.]

Hi,

My knowledge with such USB devices is very limited as almost non existed, but i can put some thoughts about this subject:

1) Using specific USB API (WinUsb) is way easier than going full low level with DeviceIoControl, so yes stick to https://learn.microsoft.com/en-us/wi...32/api/winusb/

2) I see that you reported successful WinUsb_QueryPipe, yet you did not mention what is the result of WinUsb_ReadPipe, see,.. return value is the most important for any API, in case of failure then you always want to query and report/log the GetLastError, always always always do that .

3) from your post WinUsb_ReadPipe you are using $81 as PipeID, while PipeID is in fact bEndpointAddress, where

Zitat:

Bit 7 indicates the direction of the endpoint: 0 for OUT; 1 for IN.

May be i am wrong here but shouldn't be 0 here ? meaning the PipeID should be $01.

4) The buffer size is very important, many devices are so simple hardware that refuse to handle arbitrary sizes, so after WinUsb_QueryPipe, use the MaximumPacketSize in that Info, try only that size or exact multiple sizes aka n*MaximumPacketSize, no more and no less.

5) To my knowledge to almost always you need to issue a command then read the result, USB it self is protocol, so i think WinUsb_WritePipe should be involved before WinUsb_ReadPipe, but again i might be wrong.

Now to different approach :
I faced something similar with completely different hardware, there was working software, the client needed remote functionality for this USB device which the company was dissolved and gone, so i reversed engineer its protocol and extracted the few needed commands, then build an application to do it.
I will not assume you will/can entertain the full process of reversing/decompiling... , but i can suggest something you can use and at least put you on the right way, Use Api Monitor from here http://www.rohitab.com/apimonitor
or try to search for DDK debugger if you prefer, with API Monitor you can choose the following functions in the screen shot, assuming you have working software with that device


See how that software is communicating with USB device, watch how the API's are being used and deduce your usage, as Api Monitor can and will capture the selected API function and their parameters with their return value, pay extra attention to the buffers sizes , and .....
I can't emphasize enough to check if that working software is using overlapped or not, if it is then you must (have to) use overlapped as this device is asynchronous and might be filling partially, in other words your problem could be simply blocking and waiting, yet, use this monitor for confirmation.

Sorry for the bad English, and good luck !

[max pack]

Hallo zusammen,
@Alter Mann: Nein, ich habe ein anderes Teil, kommt von AZ-Delivery (ohne hier Werbung zu machen oder Urheberrechtsverletzungen BlaBla auf den Leim zu gehen, dient nur der Beschreibung). Ist zwar absolut lächerlich, sollte heutzutage aber leider dazu geschrieben werden.

@Kas Ob: Thank you for your response.
1. Thanks, yes, I know the site with the learn.microsoft.
2. Sorry, you're right. Here are the returned values by a recievebuffer-size of 512bytes:

WinUSB Initialisierung OK.
WinUSB Handle basierend auf dem DeviceHandle ist: $00647918
---------------------------------------------------------------------------------------------------------------
WinUsb_GetDescriptor: Beschreibung des USB-Geräts abrufen:
Descriptor Länge: 18
DescriptorType: 1
USB Specification (Version): 2.0
DeviceClass: 255
DeviceSubClass: 255
DeviceProtocol: 255
Max Packet Size: 64
Vendor ID (VID): 0925
Product ID (PID): 3881
Device1: 1
Device2: 0
Manufacturer: 0
Product: 0
SerialNumber: 0
NumConfigurations: 1
---------------------------------------------------------------------------------------------------------------
WinUsb_QueryPipe: Infos zu den Pipes abfragen:
Pipe: 0 Endpoint: $0001 TransferType=Bulk Maximale Paketlänge: 512 bytes Interval: 0
Pipe: 1 Endpoint: $0081 TransferType=Bulk Maximale Paketlänge: 512 bytes Interval: 0
Pipe: 2 Endpoint: $0002 TransferType=Bulk Maximale Paketlänge: 512 bytes Interval: 0
Pipe: 3 Endpoint: $0004 TransferType=Bulk Maximale Paketlänge: 512 bytes Interval: 0
Pipe: 4 Endpoint: $0086 TransferType=Bulk Maximale Paketlänge: 512 bytes Interval: 0
Pipe: 5 Endpoint: $0088 TransferType=Bulk Maximale Paketlänge: 512 bytes Interval: 0
---------------------------------------------------------------------------------------------------------------
WinUsb_ReadPipe: Daten abrufen aus Endpoint
WinUsb_ReadPipe erfolgreich
Bytes wurden emfangen: 0

48 F1 19 00 00 00 00 00 30 5C F3 00 04 00 00 00
00 84 62 00 FF FF FF FF 99 0F 01 2B 01 00 00 00
00 00 00 00 36 00 00 00 00 00 60 00 00 00 00 00
00 00 15 00 63 00 00 50 AF 74 BD 77 00 00 00 00
5E C6 B3 77 63 01 00 50 00 84 01 00 00 00 00 00
E0 83 62 00 08 84 62 00 00 00 60 00 A4 F1 19 00
C4 5F BD 77 15 00 04 11 9B 5F BD 77 0B 6F C6 7D
00 00 60 00 00 00 00 00 00 00 00 40 F4 0A 00 00
50 00 00 00 0A 00 00 00 00 84 62 00 63 01 00 50
72 B8 83 00 0A 00 00 00 50 84 62 00 00 84 62 00
00 84 62 00 64 F2 19 00 30 F3 B6 77 17 DA 1F 0A
FE FF FF FF EC F1 19 00 DD 0A B8 77 00 00 00 00
04 0B B8 77 08 84 62 00 00 00 60 00 00 00 00 00
36 00 00 00 9F 6D C6 7D 36 00 00 00 40 00 00 00
00 00 60 00 71 00 10 00 00 00 00 00 04 00 00 00
18 00 00 00 C9 00 00 00 01 00 00 00 00 00 60 00
00 00 60 00 00 00 00 00 00 00 60 00 18 F2 19 00
AF 74 BD 77 01 00 00 00 00 00 60 00 00 00 00 00
01 00 00 00 00 00 60 00 00 00 00 00 00 00 60 00
00 00 00 00 74 F2 19 00 AA 67 BD 77 58 02 60 00
7F 67 BD 77 DB 6C C6 7D 00 00 60 00 04 00 00 00
00 00 00 00 C4 F2 19 00 32 B3 7E 75 70 00 00 00
68 F2 19 00 00 00 00 00 63 00 00 50 00 00 60 00
00 84 62 00 01 00 00 00 00 84 62 00 70 87 62 01
20 F2 19 00 0F 00 00 00 A0 F3 19 00 30 F3 B6 77
BF CB 1F 0A FE FF FF FF B0 F3 19 00 46 F8 B3 77
08 84 62 00 1F 6D C6 7D 00 84 62 00 00 00 60 00
00 00 00 00 F0 F2 19 00 CB 6D DE 76 00 00 00 00
88 45 16 77 70 87 62 00 99 0F 01 2B D0 5A F3 00
00 00 00 00 58 76 01 00 62 00 00 40 00 00 00 00
F4 0A 00 00 99 0F 2B FF FF FF FF FF F4 0A 00 00
01 2B 01 00 00 00 00 00 00 00 00 00 F5 AD 7E 75

3. Yes, right, my mistake. This was just from my quick'n dirty testing. I tested several values, without any success.
4. I tested several sizes of buffer, withot success.
5. I tested this. The documentation from Sigrok says, that the device needs 2 bytes on endpoint 1: 0x01 (or 0xd5 for newer versions) and the second byte for the samplerate. Again no success.
My next work could be the test with the ApiMonitor, as you suggested.


Um uns gegenseitig nicht weiter unsere Zeit zu stehen - bitte nicht falsch verstehen(!) - sollten wir nicht weitere Links aufführen mit: Guck mal hier oder da und kennst Du das schon... Das ist sicherlich gut gemeint, aber nicht zielführend.
Ich hatte gehofft, dass schon jemand damit konkrete Erfahrungen hat und sagen kann: Hier ist ein Codeschnippsel, oder da ist ein Schreibfehler in der Doku und muss heißen Rumpelstielzchen(123) statt Schneewittchen(432), oder eine andere Lösung.
Ich muss mich wohl damit abfinden, dass ich mein Vorhaben so in dieser Zusammensetzung nicht hin bekommen werde.
Das ist zwar schade, ist aber auch eine Art Lösung und eine Erkenntnis.
Aber vielleicht meldet sich ja noch ein Wissender.


Trotzdem nochmals vielen Dank an die tüchtigen Teilnehmer und allen ein schönes Wochenende.

[Alter Mann]

So, so. Den LA habe ich auch, jedoch ekennt Windows den nicht.

Zitat:

Vendor ID (VID): 0925
Product ID (PID): 3881

Dafür ist der Saleae Treiber erforderlich, oder irre ich mich?

[mpv]

Libusb kann WinUSB als Frontend benützen, und es gibt eine gute Übersetzung von libusb in Delphi (https://github.com/ZYHPRO/Delphi-libusb)
Die Kupplung von WinUSB mit Windows soll natürlich da sein, über inf File (oder Firmware), das wird wahrscheinlich schon gemacht beim C++ Beispiel dass du hast.

Matt