Hallo zusammen,

ich habe vor unter Windows XP ein USB Massenspeicher- Gerät zu
Simulieren.

Da USB 2.0 auf eine Master/ Slave Arhitektur Basiert, muß ich den
Rechner, der das Gerät simulieren soll dazu bringen sich auf dem USB-Bus
als Slave zu verbinden.

Problem:
1. USB On The Go- Funktionalität unterstützt mein Rechner nicht.
2. Host-Bridge-Controller stellen die Gegenstelle für gewöhnich als
Netzwerkrechner, nicht als Client dar.
3. 2 USB zu RS232 Konverter und ein zwischengeschaltetes 0-Modem- Kabel
bietet in meinem Fall keine Lösung.

Die einzige Lösung, die mir aus meiner Sicht noch bleibt um das
Kommunikationsproblem zu lösen, ist es selbst Treiber zu schreiben.
Da es zumeist als Anwendungsprogrammierer ausreichend ist auf API-
Funktionen zuzugreifen, die die gesamte Treiberschichten als transparent
erscheienen lassen, ist die Treiberprogrammierung für mich Neuland.

Hat da jemand Tipps oder hilfreiche Links, die mir weiterhelfen?

a) herauszufinden in welcher Treiberschicht ich einen WDM Treiber werde
programmieren müssen (abhängig von den bereits angebotenen
Treiberfunktionen der USB-Hub-, Host-Controller- und
USB-EHCI-Controller-Treiber).


b) Beispiele und Hinweise für die Treiberprogrammierung bieten... im
Idealfall im Bezug auf USB- Treiber unter Windows.

Du hast da ein ganz entscheidendes Hardwareproblem. Ohne einen
USB-Device-Controller kann Dein PC kein USB-Device sein.

Von Philips gab es mal eine Entwicklungsplatine für den PDIUSBD11, mit
dem der PC (unter DOS!) zu einem USB-Device werden konnte.

Du wirst einen der verbreiteten USB-Device-Controller an Deinen PC
anschließen müssen, fragt sich nur, auf welche Art und Weise das am
günstigsten zu bewerkstelligen ist.

Der erwähnte Philips-Controller wurde per I²C angesteuert, die
Entwicklungsplatine konnte an den Parallelport geklemmt werden. Rein
theoretisch ließe sich dieser Ansatz auch mit moderneren
Betriebssystemen als DOS durchführen, giveio und Konsorten machens
möglich, solange man auf "Vista" verzichtet.

Erfolgversprechender ist sicherlich der Gebrauch einer moderneren
Schnittstelle - wenn Du einen µC dazwischenschaltest, könntest Du diesen
wiederum per USB an den PC anschließen.
Der µC hat dann zwei USB-Device-Interfaces, das eine dient zur
Kommunikation mit dem PC und kann auch mit einem FT232 realisiert
werden. Das andere Deviceinterface ist das, mit dem Du arbeiten willst;
Du musst Dir dann "nur" noch eine geeignete Kommunikationsstruktur für
die USB-Daten ausdenken.
Was der USB-Device-Controller des µC diesem mitteilt, müsstest Du über
die zweite USB/FT232-Verbindung in den PC übertragen und die geeigneten
Antworten vom PC auf diese Art & Weise rückübertragen.

Statt des zweiten USB/FT232-Kanales ließe sich das ganze natürlich auch
mit Ethernet realisieren, die Hardware ähnelt dann ziemlich einer
USB-Netzwerkkarte, nur daß die Firmware eine ganz andere sein dürfte ...

Möglicherweise gibt es auch spezielle OTG-Entwicklungssysteme, die einen
USB-OTG-Controller auf einer PCI-Karte unterbringen, aber danach
müsstest Du selber recherchieren.

Was ist die eigentliche Anwendung?

Alex wrote:

> Die einzige Lösung, die mir aus meiner Sicht noch bleibt um das
> Kommunikationsproblem zu lösen, ist es selbst Treiber zu schreiben.
> Da es zumeist als Anwendungsprogrammierer ausreichend ist auf API-
> Funktionen zuzugreifen, die die gesamte Treiberschichten als transparent
> erscheienen lassen, ist die Treiberprogrammierung für mich Neuland.

Das bringt nix, wie oben schon gesagt. Die Hardware des USB Controllers
unterstützt kein Device, also kannste so viele Treiber schreiben, wie du
willst.

Ich habe mich in den letzten Wochen der Suche nach einem geeignetem
Board gewidmet. Dabei bin ich auf ein Experimentierboard von
Cypress(EZ-USB FX2LP) gestoßen, dass   über den CYC68013-Controller
verschiedene Einstellungsmöglichkeiten für die USB- Device- Entwicklung,
bietet.
(http://www.cypress.com/portal/server.pt?space=Comm...)

Man kann bis zu 4 USB-Pypes (Interrupt, Bulk oder Isochor) einrichten.
Der Standard USB-Control-Endpunkt(IN/OUT) ist im System integriert. Die
USB Busdaten werden in einstellbaren FIFO- Buffer (maximal 4 kByte)
geladen, die auch von externen Systemen ausgelesen bzw. beschrieben
werden können. Als mögliches Interface um auf die FIFO Buffer
zuzugreifen werden zum Beispiel Standards wie ATAPI/UltraDMA66,PCMCIA,
EPP, ... angegeben.

Im moment bin ich noch dabei zu untersuchen ob ich auf PC- Seite die
Möglichkeit habe die FIFO Buffer zu steuern um meinen Simulator auf dem
Rechner zu realisieren. Wenn sich hier Probleme ergeben habe ich noch
die Option das Device komplett im Entwicklungsboard zu integrieren.

@Rufus
Anwendung soll sein Embedded USB Hubs zu testen. Es sollen gezielt
Fehlkommunikationen ausgelöst werden, um die Reaktionen des Hosts
auszuwerten. Das ganze ist ein teil meines Diplomprojektes.

Ich bin für jeden Hinweis Dankbar...

Vielen Dank für die bisherigen Anregungen!

Alex

Mit dem FX2 wirst du aber nur sehr schwer ein USB Massenspeichergerät
simulieren können, das Fehler produziert. Da müsstest du das
Massenspeicher-Demo Design anpassen, aber soweit ich das in erinnerung
habe, ist da viel in Libs ausgegliedert. Oder hab ich jetzt was falsch
verstanden?
Fehlerhafte USB Übertragung wird auch schwierig, das macht der FX2 in
Hardware.

Hi,

ich habe ein ähnliches Problem und zwar muß ich auch ein Gerät
simulieren. Bei mir geht es aber nicht um "Fehler" sondern um echte
Daten, die ich übertragen werde. Die echte Hardware bekomm ich erst in
ein paar Monaten.

Da ich noch sehr unerfahren bin, was USB und C++ betrifft, würde ich
gerne mi Alex in Kontakt treten, um mir ein paar Tips einzuholen.

Wäre ein Moderator, der dessen Email einsehen kann, so nett, ihn per
Email über meinen Wunsch zur Kontaktaufnahme zu benachrichtigen?

Danke.

Ok, sorry, hab's übersehen. Die Angabe der Email ist freiwillig. Also 0
Chance ihn zu erreichen... :'(

@Reimer: Das geht nur mit einem USB on the Go Controller, und dann auch
wahrscheinlich mit sehr viel Arbeit. Ein normaler USB-Host, wie er im PC
verbaut ist, kann meines Wissens kein USB Device simulieren.

Mir ist das schon klar, aber im Rahmen meiner Projektarbeit muß ich das
Gerät erstmal simulieren. Da muß ich natürlich einen Umweg gehen, damit
das überhaupt funktioniert.

Aber mal ne dumme Frage. Gibt es USB-Controller-Karten mit Device
Controller? Wenn ja, brauch ich kein Bridge-Kabel zu besorgen.

Musst du das Gerät simulieren, oder willst du?

Für mich hört sich das so an, als hättest du die Vorstellung das
Simulieren wäre einfacher als das Gerät zu bauen. IST ES NICHT.

In der Zeit bis du einen USB-Device Simulator designed, gebaut,
redesigned, neu gebaut, und mit Treibern und Software für Windows
versehen hast, kannst du sicher drei verschiedene zu dem Originalgerät
kompatible Hardware-Versionen bauen, auch wenn du dich dafür erst in
8051 (EzUSB), PIC (18F4550) und AVRs (AT90USB) einarbeiten musst.

Was für Arten von Fehlern willst du eigentlich simulieren?

Einfache "verlorene Bits" auf der untersten Ebene gehen noch mit FETs in
den Datenleitungen, aber Fehler auf höheren Ebenen sind nicht mehr so
einfach zu erzeugen, wenn du einen fertigen USB-Device Controller
nimmst.
Dafür haben die leider schon zuviel Eigenintelligenz on board, Sachen
wie vergessene ACKS, Nichteinhaltung von Timeouts etc. kriegen die schon
hardwaremäßig nicht hin.

Am ehesten gehts noch mit einer Software-Only implementation a'la
obdev.at, dann allerdings nur Low-Speed.
Für Full/High Speed am ehesten mit einer eigenen
USB-Device-Implementation in einem FPGA, dem kannst du auch beliebig
Fehler unterschieben.

Könntest du den Empfänger deiner Nachricht genauer spezifizieren? Ich
denke, dein letzte Beitrag richtet sich an Alex.

Du könntest dir mal folgende PCI-Karte anschauen: net2880

Damit hier nicht unnötig gesucht wird: Die von "Andre" erwähnte Karte
verwendet einen der hier http://www.plxtech.com/products/net2000/
beschriebenen Bausteine.