Hallo Leute,
ich möchte gerne diesen 16-Kanal-A/D-Wandler mit USB-Schnittstelle an
einem Raspberry Pi betreiben:
http://www.bmcm.de/index.php/de/externe-messysteme/usb-ad16f.html
Vom Hersteller wird das Protokoll auf der USB-Schnittstelle leider nicht
veröffentlicht. Stattdessen gibt es eine Bibliothek für Windows und
Linux mit einem dokumentierten API. Allerdings nur als Binary, nicht im
Quelltext. Wobei das Linux-Binary nur für Intel-Plattformen verfügbar
ist, nicht für ARM. Also läuft es auf dem Pi nicht. Damit möchte ich
mich aber nicht abfinden. Das Protokoll kann ja nicht derartig
kompliziert sein, dass man sich nicht schnell ein C-Progrämmchen dafür
schreiben könnte.
Nur wie herausfinden, was auf der Schnittstelle passiert? Ich habe es
mit Wireshark versucht. Allerdings schreibt das scheinbar den gesamten
USB-Overhead mit und ich verstehe nur Bahnhof.
Kann jemand aus dem angehangenen PCAP irgendwelche sinnvollen Dinge
herauslesen?
Aufgezeichnet ist die Kommunikation zwischen dem Wandler und einem PC
über die vom Hersteller mitgelieferte Library. Es werden nacheinander
alle 16 Kanäle ausgewählt und die Daten abgefragt.
> Was ist ein PCAP?
In Anbetracht dieser Frage glaube ich nicht, daß Martin Dich
angesprochen hat. Trotzdem danke für Deinen konstruktiven Beitrag.
Gruß,
Fernando
Wenn Martin schreibt das er: "Ich habe es mit Wireshark versucht." dann
könnte es Möglich sein das die angehängte Datei ein 'protocol capture'
von Wireshark ist.
Du suchst dir aus dem PCAP die Descriptoren Requests raus (Setup Paket,
EP0) und die Antworten darauf.
Im Interface Descriptor liest du das Feld Class und SubClass aus.
Für den groben Paketaufbau:
http://www.beyondlogic.org/usbnutshell/usb6.shtml
Ansonsten siehe USB Spec. Solltest du dir sowieso anschauen, wenn du
nachher auf Linux Ebene Requests selber abschicken willst.
Ich weiß was ein PCAP-File ist, darf ich jetzt antworten? :-)
Im Ernst, googeln der VID/PID ergibt z.B.
http://ubuntuforums.org/archive/index.php/t-1718390.html> The card implements the CDC class as ACM.
Also angeblich CDC-ACM. Das ist standardisiert. Ich habe das nicht mit
dem PCAP-File gegengeprüft. Weitere Untersuchungen mit einem
Terminal-Emulator würden sich anbieten.
Aus der Reaktion des Herstellers in dem Thread sieht man auch, dass der
ziemlich am Rad dreht. Vielleicht wäre es besser ein anderes Produkt zu
wählen.
Okay, gerade mal inc pcap geschaut: USB Class Vendor, also hält er sich
an keine offiziell Dokumentierte Klasse. Du darfst alle Requests selber
zerlegen oder jemand finden, der es schon gemacht hat.
martin w. schrieb:> Vom Hersteller wird das Protokoll auf der USB-Schnittstelle leider nicht> veröffentlicht. Stattdessen gibt es eine Bibliothek für Windows und> Linux mit einem dokumentierten API. Allerdings nur als Binary, nicht im> Quelltext. Wobei das Linux-Binary nur für Intel-Plattformen verfügbar> ist, nicht für ARM. Also läuft es auf dem Pi nicht. Damit möchte ich> mich aber nicht abfinden. Das Protokoll kann ja nicht derartig> kompliziert sein, dass man sich nicht schnell ein C-Progrämmchen dafür> schreiben könnte.Jay schrieb:> Aus der Reaktion des Herstellers in dem Thread sieht man auch, dass der> ziemlich am Rad dreht. Vielleicht wäre es besser ein anderes Produkt zu> wählen.Maxx schrieb:> Okay, gerade mal inc pcap geschaut: USB Class Vendor, also hält er sich> an keine offiziell Dokumentierte Klasse. Du darfst alle Requests selber> zerlegen oder jemand finden, der es schon gemacht hat.
Ich würde alle Energie dahinein stecken andere Hardware zu finden.
Hihi ... Das Protokoll kann ja nicht derartig kompliziert sein, dass man
sich nicht schnell ein C-Progrämmchen dafür schreiben könnte.
Ja, dann mach mal. Zeitaufwand nach Einarbeitung 6 Monate und mehr. Also
vergiss es, suche eine andere Loesung.
> Das Protokoll kann ja nicht derartig kompliziert sein
Warum nicht? Es könnte sogar absichtlich extrem kompliziert sein, damit
Leute wie du es nicht reverse enginneeren.
Es gibt Firmen, die scheiben dir so ein Basisprotokol, dies koennen sie
dank der akkumulierten Erfahrung relativ kostenguenstig. Im Bereich von
drei Nullen hinten dran. siehe zB thesycon.de
Wenn du das Gerät ansteckst und dann in dmesg schaust, wird das als
cdc-acm-Gerät erkannt? Dann fällt eine Protokollschicht schonmal weg und
das Ganze könnte recht machbar sein. Andernfalls würde ich auch eher
nach anderer Hardware suchen, das lohnt die Mühe nicht.
Ich würde erst mal anfangen nur einen(zwei Kanal zu samplen.
Dann bekomme ich schon mal irgendwo die Kanalnummer heraus.
Das aber der Hersteller bei einem Preis von > 400 EUR nicht mal das
Protokoll heraus gibt ist sch**.
Vielleicht passt was im drivers/staging/iio in den Kernelsourcen /
Hans Ulli K. schrieb:> Das aber der Hersteller bei einem Preis von > 400 EUR nicht mal das> Protokoll heraus gibt ist sch**.
was ist denn das Protokoll von USB?
Bei RS232 war da noch einfach. Bei USB muss man ja erst mal den Layer
festlegen.
Peter II schrieb:> Hans Ulli K. schrieb:>> Das aber der Hersteller bei einem Preis von > 400 EUR nicht mal das>> Protokoll heraus gibt ist sch**.>> was ist denn das Protokoll von USB?>> Bei RS232 war da noch einfach. Bei USB muss man ja erst mal den Layer> festlegen.
vergleiche das mal mit dem Netzwerk -> OSI Layer
USB macht eben nur Layer1 und Layer 2.
Dazu gibt es noch den "SCSCI" Layer z.B. für Massenspeicher.
Und Netzwerkkarten z.B. Wifi kochen da ihre eigene Suppe
Oder D. schrieb:> Hihi ... Das Protokoll kann ja nicht derartig kompliziert sein, dass man> sich nicht schnell ein C-Progrämmchen dafür schreiben könnte.>> Ja, dann mach mal. Zeitaufwand nach Einarbeitung 6 Monate und mehr. Also> vergiss es, suche eine andere Loesung.
Könnten 6 Monate sein, oder auch nur 6 Stunden, das hängt ganz vom
Protokoll ab. Es gibt viele USB-basierte Messgeräte wo das Protokoll
trivial ist und recht schnell herauszufinden ist.
Im Manual steht "Unter Mac OS X, FreeBSD und Linux muss keine
Treiberinstallation durchgeführt werden.".
Das könnte durchaus bedeuten dass es doch "normales" CDC-ACM ist und der
normale Kernel-Treiber greift. Oder aber dass kein Treiber nötig ist
weil sie in ihrer "libad" selber mit libusb o.ä. das gesamte Protokoll
(ob CDC-ACM oder nicht) im Userspace implementiert haben.
An dem PCAP File sind ein paar Dinge auffällig:
1. Es werden Bulk Endpoints definiert aber offenbar nicht benutzt - es
läuft alles über den Control EP.
2. Es finden jede Menge 2-Byte Vendor specific Read requests statt.
Sieht für mich so aus, als würde der jedes 16-Bit Sample einzeln
anfordern.
Zu Anfang wird auch ein 256 Byte Block übertragen, das könnten
irgendwelche Konfigurationsdaten sein.
Ohne das Gerät selbst kann man aber nur raten. Es dürfte einfacher sein,
sich direkt an den Hersteller zu wenden und da mal nachzufragen, ob die
nicht das Protokoll (eventuell unter NDA) rausrücken.
Das ist doch relativ einfach. Die ganze Initialisierungsphase musst Du
halt 1:1 nachprogrammieren. Also die Endpunkte anfordern und den
Konfigurationsblock schicken. Die Hardware dürfte auf die gleiche
Konfiguration ja immer gleich antworten. Wenn Du zusätzliche
Konfigurationen ausprobieren möchtest, dann must du halt Wireshark noch
einmal bemühen.
Im Betrieb schickst Du dann die URB Pakete. Dort fragt er ja freundlich
mit Request Type 0xc0 den Request 98. In wValue steht dann
wahrscheinlich die Kanalnummer.
Die URB Antwort hat 16 bit Payload, also wahrscheinlich den Analogwert.
Das dritte Paket mit Typ 62 scheint ein Acknowledge oder Status Report
zu sein, den Du aber wohl einfach ignorieren kannst.
Am Besten Du schreibt den Code um die Endpunkte zu initialiseren und
kopierst dann einfach die host->client Pakete aus dem Protokoll. In den
Paketen kannst Du dann schnell sehen, welche Werte sich mit Änderung der
Analogeingänge ändern.
Für mich sieht das ganz unkomprimiert und unverschlüsselt aus. Also eher
6 Stunden als 6 Monate Arbeit.
Achja, genau. Bevor Du irgendetwas mit USB probierst: schau doch erst
mal nach, ob sich das Teil nicht ganz einfach als serieller Port im
"/dev" Verzeichnis anmeldet. Also z.B. "/dev/tty.usb1411"
Sven B. schrieb:> Wahrscheinlich ist es ein cdc-acm und du hast mit dem USB-Layer> überhaupt nix zu tun.
aus pcap
bDeviceClass: Vendor Specific (0xff)
Matthias M. schrieb:> Achja, genau. Bevor Du irgendetwas mit USB probierst: schau doch erst> mal nach, ob sich das Teil nicht ganz einfach als serieller Port im> "/dev" Verzeichnis anmeldet. Also z.B. "/dev/tty.usb1411"
s.o.
Moin,
nach einer längeren Pause möchte ich mich jetzt doch wieder mit diesem
Problem beschäftigen. Zwischendurch hatte ich ein Work-Around mit einem
Windows-Rechner am Start, aber das ist ziemlich hässlich.
dmesg sagt:
1
[ 2896.795088] usb 2-1.1: new full-speed USB device number 5 using ehci-pci
2
[ 2896.890562] usb 2-1.1: New USB device found, idVendor=09ca, idProduct=4132
3
[ 2896.890570] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
4
[ 2896.890575] usb 2-1.1: Product: USB-BASE Analog/Digital I/O Board
5
[ 2896.890579] usb 2-1.1: Manufacturer: BMC Messsysteme GmbH
6
[ 2896.890583] usb 2-1.1: SerialNumber: 000479
Ich werde jetzt mal mit den vorgeschlagenen Lösungen experimentieren.
