Dieses Produkt ermöglicht den Anschluss von IEEE1394-Geräten
an den USB-Anschluss eines PCs.
Die Übertragung erfolgt in USB-High-Speed (480 Mbit/s)
bzw. in S400-Geschwindigkeit (393,216 Mbit/s) auf FireWire,
sofern die angeschlossenen Gegenstellen dies erlauben.
Wichtig! Eine umgekehrte Funktionalität,
der Anschluss von USB-Geräten an den IEEE1394
ist damit nicht möglich.
Geeignete Treibersoftware ermöglicht den Zugriff auf das IEEE1394-Gerät
ohne Änderung der Software. Zunächst muss Software angepasst werden.
Einsatzgebiete
Typische Geräte sind:
Kameras
Externe Laufwerke
Scanner
Andere Computer (svw. Netzwerk)
Die Stromspeisung für IEEE1394-Geräte muss extern oder über die Hohlbuchse erfolgen.
Die Selbstversorgung des Konverters erfolgt über USB.
Die (nicht zu ändernde) Software muss unter Windows lauffähig sein!
Unter MacOS, Linux usw. muss die zugreifende Software auf USB angepasst werden.
Aufbau
Die Schaltung passt in ein „Seifen“-Gehäuse TEK10014.
Die kleinste Baugröße ist 0603 für Kondensatoren
(Reichelt).
Viele Bauelemente gibt's nicht bei Reichelt, sondern müssen bspw. bei
Digikey beschafft werden.
Die beiden Chips von
Texas Instruments
können auch direkt vom Hersteller als kostenloses Muster bezogen werden.
Vor dem Bestücken der Leiterplatte sind wenigstens die „weitläufigen“ Netze
5P und 3P3 auf Masseschluss zu prüfen.
Um sicher zu gehen, dass es später eine Zinnbrücke und kein Leiterplattenfehler
ist.
Die nur einseitig bestückte Leiterplatte wird zunächst mit SMD-Bauteilen
im Reflow-Verfahren bestückt.
Je nach Qualität der Lötpaste und der Pastenschablone neigen die 0,5-mm-Pins
der hochintegrierten Schaltkreise zu Zinnbrücken, die allesamt zu entfernen
sind. Danach wieder Kontrolle der Netze 5P und 3P3.
Danach werden die Durchsteck-Bauteile bestückt, sowie die kanten-montierten
Bauteile (Hohlbuchse und IEEE1394-Buchse).
Auf der Leiterplatte befinden sich Kondensatoren der Bauform 0402, die jedoch
zum „Grabsteineffekt“ neigen, weil die Lötflächen nicht ganz geeignet sind.
Zur Inbetriebnahme wird das USB-Kabel an den Rechner gesteckt
und das Cypress-Entwicklungskit verwendet,
um die unten stehende Firmware aufzuspielen.
Danach fordert Windows einen neuen Treiber an, der einen FireWire-Stack
zur Verfügung stellt, die Datenpakete jedoch über den USB-Umweg an den
USB-zu-Firewire-Konverter weiterleitet.
Software
Es ist zweckmäßig, das Gerät im (mindestens) zwei Rollen zu betreiben.
Dabei unterscheiden sich Treiber und Firmware erheblich:
Anschluss von Kamera und/oder Audio
Die Firmware wandelt eine FireWire-Kamera in eine USB-Kamera um (entspechend USB-Geräteklasse)
Die Firmware wandelt ein FireWire-Audiogerät in ein USB-Audiogerät um (entspechend USB-Geräteklasse)
Kein Treiber für welches Betriebssystem auch immer wird benötigt!
Die im System enthaltenenen Standard-Treiber für Video und Audio sollten laufen
Kameras und Audio erscheinen als USB-Geräte (Ärger vorprogrammiert,
wenn bestimmte Software den Anschluss zwanghaft an FireWire erwartet)
Mögliche Unterstützung auch für FireWire-Laufwerke (Festplatten) und -Scanner in der gleichen Weise
Universeller USB-zu-FireWire-Konverter
Die Firmware schaufelt den gesamten FireWire-Verkehr zum USB durch (USB ist ein Tunnel)
Der Windows-Treiber erzeugt einen (an USB angeschlossenen) IEEE1394-Hostcontroller
mit allen angeschlossenen Geräten und echtem Plug-And-Play
Alle Arten von IEEE1394-Geräten sollten damit laufen (Datendurchsatzprobleme außen vorgelassen),
vorausgesetzt die Zugriffssoftware setzt keinen spezifischen
Host-Controller-Treiber voraus (d.h. QuantumX läuft nicht mit CatMan).
Der Treiber ist echt schwierig zu implementieren, gibt es jemanden, der das macht?
(Oder mir wenigstens die Richtung weist?)
Zu erwartende Datenraten:
FireWire Isochon: Maximale USB-Datenrate: 24,576 MByte/s (bidirektional, drei isochrone USB-Pakete à 1024 Bytes pro Mikrorahmen [125 µs])
FireWire Asynchron: etwa 4 MByte/s (unidirektional, Daten gehen byteweise durch den 8051-Flaschenhals)
Möglicherweise umgekehrt je nach Anwendungsfall
Möglicherweise gleichgestellt zu 8,192 MByte/s (bidirektional, also 4 Kanäle, zwei USB-Pakete à 512 Bytes pro Mikrorahmen [125 µs])
Diese Downloads benötigen Sie nur
zum besseren Verständnis sowie zum Nachbau:
Eagle-Layoutdaten Das Gros der Leiterplattenhersteller kann diese Eagle-Daten
ohne Aufpreis verarbeiten: 2-seitig durchkontaktiert,
0,15 mm Leiterzugbreite, 0,15 mm Abstand, 0,3 mm Vias,
Fräsungen durchkontaktiert, Bestückungsdruck oben,
tPlace und tNames.
Diesen Download benötigen Sie
zum Nachbau sowie zum Firmware-Update:
Firmware für den seriellen EEPROM
Das Programmieren des seriellen EEPROMs erfolgt mit EzMr aus dem
Cypress-Entwicklungskit für den EZUSB-FX2.
Es wird kein Programmiergerät benötigt.
Dieser Download genügt für den Betrieb des
Fertiggerätes:
F:
Gibt es ein umgekehrtes Gerät? Zum Anschluss von USB-Geräten an FireWire?
A:
Ein entsprechendes Gerät war mal in Vorbereitung, ist aber aus heutiger Sicht Nonsense.
Denn hier kann man USB-Ethernet-Konverter (PC-Software) verwenden.
Dafür gibt es verschiedene Anbieter. Leider nichts open-source, und zumeist kostenpflichtig.
Derartige Software besteht aus:
Einem USB-Hostcontroller-Treiber (HCD), der die Zugriffe in TCP/IP „einpackt“ und zu einem entfernten Rechner weiterleitet.
Einem USB-Gerätetreiber (welcher auf beliebige USB-Geräte „passen“ muss) und einem Stub, das das Anwendungsprogramm simuliert.
Ein Steuerprogramm, welches dem Stub mitteilt, welches Geräte es „schnappen“ und damit umleiten soll,
entweder shared oder (meistens) exklusiv.
TCP/IP kann man via FireWire übertragen, fertig ist die Lösung.
Diese benötigt einen quasi dedizierten PC oder Notebook mit USB und FireWire auf der Geräteseite.
Kann man bei Ethernet (oder WLAN via USB⇔WLAN-Stick) bleiben, bietet sich ein
Raspberry Pi an, diese Aufgabe zu lösen.
Allerdings braucht man den Stub für Arm9-Architektur unter Linux.
Ob es dafür einen Anbieter gibt??
F:
Ist das ein Aprilscherz?
A:
Nein, ein unvollendetes Projekt, welches recht komplex ist.
Es hatte als Aprilscherz angefangen.
Das Problem der angegebenen Schaltung ist, dass das
GPIF (das aktive
Interface des USB-Chips CY7C68013A)
gewisse Vorhaltezeiten verlangt,
der FireWire-Chip TSB12LV32
diese jedoch nicht liefert.
Zum Verwenden von Slave-FIFO (das passive Interface des USB-Chips) hätte
man die Leiterplatte neu machen müssen; ob dann das Signalspiel klappt,
ist mir noch unklar. Laut Datenblatt sollte es funktionieren.
Möglicherweise braucht man ein paar Gatter oder Schaltungstricks,
um die Richtungsumschaltung zu realisieren.
Damals war's dann vorbei mit neuen Leiterplatten, und heute weiß ich
nicht, wie man günstig an FireWire-Chips herankommt. Früher gab es diese
kostenlos bei Texas Instruments.
Nicht-isochrone FireWire-Datenpakete lassen sich auch ohne das
DataMover-Interface des TSB12LV32 bzw. GPIF des CY7C68013A übertragen;
dann allerdings byte-weise über den externen 8051-Datenbus im Schneckentempo.
Damit ließe sich zumindest ein Funktionsnachweis erbringen.
Ganz sicher vor solchen Fallstricken wäre man bei einen Neuentwurf, wenn
man dazwischen einen CPLD oder FPGA setzt. Für Xilinx Virtex-II gibt es
entsprechende Vorarbeiten,
wie dieser am besten anzuschließen ist, damit der USB-Chip diesen
per Windows-Treiber-Ressource blitzschnell konfiguriert.
Die Kombination CY7C68013A - [Spartan3] - TSB12LV32
ist auch heutzutage
die optimale Konfiguration für ein solches Gerät.
Zum Programmieren des Gesamtsystems braucht man tiefgründiges und
praktisches Wissen über FireWire (die Spezifikation reicht nicht!),
was mir fehlt.
Außerdem eine Reihe verschiedener praktischer
FireWire-Beispiele (also Endgeräte).
F: Gibt es Software?
A: Nein.
F: Gibt es Weiterentwicklungen?
A:
USB ↔ FireWire (beide Richtungen) mit folgenden Chips:
OMAP3525 — Mikrocontroller mit 2x USB High-Speed Host/Device
TSB43AB23 — IEEE1394 Link+Phy mit 3 Ports
USB 3.0 und FireWire 800.
Folgende Chips wären als Grundlage:
CYUSB3014 — USB-3.0-Mikrocontroller mit ARM9-Prozessorkern
XC6SLX9 — FPGA zum Datentransfer
beliebiger DDR-RAM zum Puffern
TSB82AA2B — IEEE1394b OHCIlynx (kann bei größerem FPGA entfallen)