Hallo,
ich habe ein USB Device welches ich an einen ARM µC mit integriertem USB
Host anschließen möchte. Zur Ansteuerung liegt dem Device eine DLL bei.
Da ich mir schon denken kann, dass die DLL auf x86 Systeme ausgelegt ist
und damit wohl kaum auf einem ARM basierenden Prozessor zum Laufen zu
bewegen ist, steht die Frage:
Wie kann ich ein bestehendes x86 Assembly in Form einer DLL auf einem
ARM System verwenden, bzw. kann man es umwandeln?
Erst den C Code der DLL beim Hersteller zu erfragen wäre dann wohl der
allerletzte Ausweg, möchte ich aber möglichst umgehen.
Gruß
> Wie kann ich ein bestehendes x86 Assembly in Form einer DLL auf einem> ARM System verwenden, bzw. kann man es umwandeln?
Du müsstest einen x86 - Interpreter schreiben, der die x86-Befehle,
genauer die i386-Befehle interpretiert.
Sowas existiert zwar, sogar im Quelltext (z.B. Bochs?), dürfte aber
einen durchschnittlichen ARM ganz erheblich überfordern.
Desweiteren müsstest Du die Laufzeitumgebung des Betriebssystems
nachbilden, für das die DLL geschrieben ist, denn diese wird sicherlich
den einen oder anderen Systemaufruf tätigen.
Auch das dürfte recht deutlich am Ziel vorbeigeschossen sein.
Sicherlich kannst Du die DLL durch einen x86-Disassembler jagen und
versuchen, dessen Ausgabe in ein logisch verständliches Programm zu
überführen, aber auch das dürfte ganz erheblichen Aufwand bedeuten, weil
auch hier die Interaktion mit dem zugrundeliegenden Betriebssystem zu
berücksichtigen ist.
Kontaktiere den Hersteller und frage ihn nach Linux-Unterstützung für
sein Gerät. Damit dürftest Du mehr anfangen können als mit dem Quelltext
einer Windows-DLL.
Wenn der Hersteller keine Informationen 'rausrückt, kannst Du mit einem
USB-Protokollanalysator à la USB Snoopy herausfinden, was an das
USB-Gerät zu senden ist bzw. was es antwortet, und die für Dich
interessante Funktionalität nachbilden.
Die oben genannten Ansätze (Emulation, Disassembler) erscheinen mir
sehr fruchtlos.
Das kannst Du eigentlich vergessen.
Ich will nicht ausschließen, daß es irgendwo so etwas ähnliches wie
einen statischen oder dynamischen Binärcodeübersetzer von IA-32 auf ARM
gibt (auch wenn mir pauschal keiner einfällt, die meisten gehen in die
umgekehrte Richtung) und das Portable-Executable-Format der DLL bekommt
auch auch decodiert.
Das Hauptproblem ist aber, daß die DLL mit ziemlicher Sicherheit die
Win32-API verwenden wird. So lange Du nicht so etwas wie WINE auf Deinem
Gerät laufen hast, kannst Du es spätestens an diesem Punkt vergessen
etwas mit der DLL anzufangen.
Danke, das habe ich eigentlich befürchtet^^
Werde mal den Hersteller kontaktieren und wenn das nicht fruchten mal
einen USB Protokoll Sniffer probieren.. wusste garnicht dass es sowas
gibt, danke für den Hinweis :)
Gruß
>ein kleiner arm7 oder 9
dann vergiß die DLL einfach.
>ich habe ein USB Device
Ja, was denn für eins?
Welche Geräteklasse?
Vielleicht läßt sich mit Standards was erschlagen.
>Also alles andere als Standard
Also wenn ich den "USB-Treiber" dort mal anschaue, sehe ich FTDI-DLLs.
ALso doch Standard. Nämlich CDC, wenn ich mich nicht irre.
Nagut wenn ftdi ein Standard ist... Es wird also schon c code zur
Ansteuerung dieses Bausteins geben, bräuchte man also nur noch das
Protokoll in Erfahrung bringen?
@NOX
wenn die Patine ein Chip besitzt dessen Kennung mit FT****
beginnt hast du gute Chancen dort deine Steuersignale seriell
abzugrifen.
das ist dann ein Standart Seriell USB umsetzer...
http://www.ftdichip.com/FTProducts.htm
73
Nun, ob FTDI wirklich CDC implementiert, sei dahingestellt.
Wäre dem so, würde ja an und für sich eine simple *.inf-Datei genügen,
und der CDC-Treiber von Windows könnte genutzt werden.
Außerdem könnte es sein, daß die betreffende Schaltung nicht einen
FT232, sondern einen FT245 verwendet, und der ist nicht seriell ...
Jedoch sollten aus dem Linux-Lager auch Treibersourcen für FTxxx zu
organisieren sein, wenn es wirklich nötig ist, den Baustein per USB
anzusteuern.
/drivers/usb/serial/ftdi_sio.c könnte ein Ausgangspunkt für eigene
Entwicklungen sein.
jap auf der Platine ist auch ein 245rl .. also wäre es wohl sinnvoll ein
Linux System auf dem ARM aufzusetzen und nicht mit "Hardcode" ohne
Betriebssystem zu arbeiten.
Na mal schaun, werd den Hersteller mal kontaktieren, muss ja wenigstens
das Protokoll erfahren, ehe ich mit nem USB Sniffer anfange.
Der kennt das Protokoll aber nicht, denn das wird von FTDI definiert.
FTDI stellt sowohl das USB-Device als auch das Gegenstück, den
zugehörigen Treiber zur Verfügung. Für Nutzer der FTxxx-Bausteine ist
das Protokoll opak, was normalerweise auch kein Problem darstellt.
>FTDI wird das Protokoll nicht 'rausrücken.
Gegen NDA schon.
So langsam zweifele ich aber an der Sinnhaftigkeit des Projekts.
WAS soll der ARM denn mit diesem USB-Gerät anstellen, was ein PC
nicht kann. Mobile Lasershow?
Ich möchte doch auch eigentlich nicht das Protokoll der FTDI
Kommunikation wissen, da diese scheinbar in den oben erwähnten
Treibersourcen für diese Bausteine enthalten ist. Viel mehr geht es mir
um das was die DLLs über die FTDI "Schnittstelle" schieben und das weiß
sicher nur der Hersteller des Boards ;)
Oder hab ich jetzt an irgendeiner Stelle etwas missverstanden?
Du mußt beides wissen, wenn du die Host-Funktionalität selber
programmieren willst. Nimmst du ein Betriebssystem (Windows/Linux),
dass den FTDI-Chip unterstützt, dann bleibt "nur" noch die Funktion,
hinter dem FT245.
Aber WAS macht denn dieses Board so tolles, was man nicht gleich mit
dem ARM + x selbst erschlagen könnte???
zumindest genug um 300eu zu kosten... mein projekt soll/muss aber mit
diesen karten auskommen, um die Kompatibilität mit den Programmen zu
wahren, die diese Karte nutzen... Kompliziert aber nagut...
Im Prinzip geht es nur darum das USB Kabel zwischen diesem Board und dem
PC virtuell über Ethernet zu "verlängern". Ein Treiber soll dabei auf
dem PC die Daten abfangen, über Ethernet zu dem µC schicken un dieser
soll es wieder auf die Karte geben^^
Vielleicht fällt euch dazu ja ein besserer Weg ein?
>Im Prinzip geht es nur darum das USB Kabel zwischen diesem Board und dem>PC virtuell über Ethernet zu "verlängern". Ein Treiber soll dabei auf>dem PC die Daten abfangen, über Ethernet zu dem µC schicken un dieser>soll es wieder auf die Karte geben
Und warum sagst du das nicht gleich im ersten Post?
Dann hätte man sich das Rumgeeiere sparen können.
Gibts sowas nicht fertig zu kaufen?
