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ß
ARM-basiertes Gerät? Läuft das wenigstens auf Windows CE? Oder soll das an einen "kleinen" ARM7 oder ARM9 mit USB-Host dran?
ein kleiner arm7 oder 9, das steht noch zur debatte.. mit integriertem usb host.
>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.
eine ILDA Ausgabekarte ;) Also alles andere als Standard, würde ich sagen. hier zu finden: http://lumax.de/
>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?
Such mal nach libFTDI. Damit kannst du mit Hilfe von LibUSB mit FTDI Geräten kommunizieren.
>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?
Weil es soetwas meinen Recherchen zufolge eben noch nicht gibt ;) Danke Mars dem werd ich mal bei Gelegenheit nachgehen
tat ich neulich, es lassen sich jedoch dafür nur programme finden... ich möchte jedoch nicht an der gegenstelle keinen ganzen pc hinstellen.
Der vierte Treffer der oben genannten Suche fördert dieses Gerät hier zu Tage: http://www.lantronix.com/device-networking/external-device-servers/ubox.html
ok es ist der moment gekommen ... wo ich mich wie ein idiot fühle^^ Sry für die Umstände, mal sehen ob wir das damit lösen. Danke für die Erleuchtung
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.