www.mikrocontroller.net

Forum: FPGA, VHDL & Co. USB oder 1394


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi @ all

Ich taste ein Signal mit 2MHz ab. Die Auflösung des AD-Wandlers beträgt
12Bit. Da ich die Daten an den PC übertragen möchte, benötige ich eine
Schnittstelle, die mindestens 24Mbit überträgt. Auf der PC-Seite kommt
Labview zum Einsatz, um die ankommenden Daten graphisch darzustellen.
Zudem stellt Labview Treiber für die USB und Firewire Schnitstelle
bereit.

Damit die FPGA-Seite möglichst einfach wird, benötge ich einen
Baustein,  der für mich die Übertragung der Daten übernimmt. Ich möchte
die Daten möchglichst nicht seriell an den Baustein übergeben, sondern
parallel. Habe auch schon Bausteine bei TI.com gefunden, jedoch sind
diese zu kompliziert anzusteuern. Dort muss man noch die Übertragung
programmieren. Ich suche einfach nur ein IC, dass die Daten über eine
Datenleitung bekommt und diese dann per USB oder Firewire an den PC
sendet. Dies muss doch möglich sein, denn ein USB-Stick besitzt so
etwas ja auch.

1. Was ist denn einfacher zu realisieren USB oder Firewire?
2. Gibt es bei USB nur 2 feste Geschwindigkeite USB1.1 und USB 2.0 oder
kann man jede beliebige Geschwindigkeit dazwischen wählen?
3. Welche Geschwindigkeiten gibt es bei Firewire?
4. Zu welchen Baustein könnt Ihr mir raten?

Grüsse

Michael

Autor: ,,,, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zu 1) USB ist einfacher, Firewire erfordert sehr viel höheren
Hardwareaufwand.

zu 2) USB kennt drei Geschwindigkeiten: low speed, full speed und
highspeed, wobei USB1.1 kein high speed kann und USB 2.0 kein low speed
unterstützen muß. USB 2.0 muß allerdings zwingen full speed können, da
sonst keine Anmeldung als high speed device möglich ist.

zu 3) Dazu habe ich keine genauen Infos. Ich kenne 400MBit/s und
800MBit/s, 1600MBit/s ist bereits spezifiziert.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist ja blöd, das es nur so wenig USB-Geschwindigkeiten gibt. Wenn
man nun 20MBit/s übertragen möchte, dann muss man das HighSpeed
nehmen.

Welche Bausteine benötigt man denn für eine USB-Übertragung

Autor: Mario Grafe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal eine Anmerkung zu FireWire (IEEE1394):
Ich arbeite im FhG IPMS in Dresden und wir haben viel mit FireWire zu
tun und sind u.A. Testhouse für FireWire-Produkte (Standardkonformität
prüfen). FireWire bedeutet in der Tat einen höheren Aufwand, da man
einen physical- und linklayer (hardware) benötigt sowie den
Protokoll-Stack (software) auf dem Controller implementieren muß (wir
haben uns einen eigenen Stack auf dem C161 entwickelt). Dafür bietet
FireWire für Echtzeitanwendungen die nötige Performance und vor allem
einen QoS. Wir benutzen es vor allem bei Videoanwendungen (DCAM, DV,
MPEG-2 over FireWire) aber auch zeitkritischen Steuerungen. Die
FireWire-Spec wurde bis jetzt 2-mal erweitert:
- IEEE1394-1995 -> initial version (100, 200, 400 MBit/s)
- IEEE1394a -> 100, 200 und 400 MBit/s spezifiziert
- IEEE1394b -> 100, 200, 400, 800, 1600, 3200 MBit/s, wobei 1600 und
3200 nur über Glasfaser (GOF) oder Plastikfaser (POF) spezifiziert
sind.

Es wäre in der Tat mal ein interessantes Projekt, den FireWire-Stack in
den AVR zu implementieren. Dies ist nicht so schwierig wie es klingt, da
der LinkLayer das Meiste übernimmt. Der Standard ist z.B. im Buch
"FireWire System Architekture" von Don Anderson (ISBN 0-201-48535-4)
bzw bei der www.ieee.org gut dokumentiert. PhysicalLayer und LinkLayer
sind übrigens bei Texas Instruments oder Philips zu bekommen (wir
nehmen immer TI). FireWire wird leider viel zu wenig beachtet...

Autor: Didi Fouke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Mario,

von Philips gibt es zu dem PDI1394L40 Link Layer Chip ein Eval-Kit, zu
dem auch Firmware (C-code) erhältlich ist:

http://www.semiconductors.philips.com/pip/PDI1394L40.html

Auf dem Board ist ein 80C51 mit 64k Speicher. Daher ist die Firmware
etwas üppig ausgelegt. Aber aus eigener Erfahrung kann ich sagen, dass
eine abgespeckte Implementierung des FireWire Stack auf dem ATmega8515
platz hat.

Nun kenne ich mich nur mit Linux aus und habe mit USB keine große
Erfahrung, aber mit der libraw1394 bin ich der Meinung, dass auf der
PC-Seite der Zugriff auf die Daten per FireWire mir recht einfach
erscheint. Mich würde da mal ein Vergleich zu USB interessieren.

Gruß

Didi

Autor: Mario Grafe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Didi:
Den Philips LLC hatte ich noch nicht in den Fingern, ist aber quasi der
gleiche Link wie der TSB42AB4 von TI, also für Audio/Video Anwendungen
optimiert. Wir haben bei uns eine IEEE1394-Stack-Implementation auf
einem C51 (64K Flash) mit IEC61883 und AV/C (nicht selbstgeschrieben).
Einen einfachen asynchronen Transfer hinzubekommen, wird nicht so
schwierig sein. Man kann den Stack relativ gut skalieren, wenn man
einige Funktionen weglässt (z.B. Busmanagerfunktion etc.). Ich
persönlich denke das die Möglichkeiten für private Projekte mit
IEEE1394 noch nicht richtig ausgelötet sind. Viele schreckt die
Protokoll-Stack Programmierung ab. Auf der PC-Seite (Windows) gibt es
Fix und Fertige Treiberbiblotheken (z.B. von UniBrain oder Pionsys).
Aber auch direkte Verbindungen über den WinSocket sollte einen findigen
Programmierer nicht abschrecken.
Ich denke das wäre mal ein lohnendes Projekt.

Vergleich zu USB:
- FireWire, s. mein voriger Post
- USB 2.0 -> 480MBit/s BRUTTO, also nicht wirklich erreicht. USB ist
auch kein echtes Bussystem, da immer Host-Slave basiert. FireWire-Netze
organisieren UND optimieren sich selbst.

Gruß
Mario

Autor: Günter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Michael,

Digilent hat ein USB2 Interface für Ihre FPGA boards.

http://www.digilentinc.com/Products/Catalog.cfm?Na...

Der Vorteil von dem Board ist, es gibt fertigen VHDL-Code für die
FPGA-Seite, einen Windows-Treiber und Software für den Zugriff auf die
Daten auf der PC-Seite. Zur Beschreibung gibt es auch den
Stromlaufplan.


@ Mario

Die Daten eines A/D Konverter über FireWire zu übertragen hatte ich mir
auch schon mal überlegt. Meine erste Frage war dann ob ich asynchronen
oder isochronen Transfer dazu nehmen soll. Im Endeffekt würde
isochroner Transfer dafür ganz gut funktionieren.

Wie ich die Diskussion hier verfolgt habe ist mir dann die Idee
gekommen, man könnte eigentlich eine Art FireWire Drop-In Modul
entwickeln, dass man mit 2.54mm Pfostenstecker in ein anderes Design
einbinden kann. Das Modul könnte zwei AV-Schnittstellen für isochronen
Transfer zur Verfügung stellen und den Adress-Daten-Bus des verwendeten
Mikrocontrollers.

Der Mikrocontroller würde den asynchronen Transfer managen und die
Register des Link-Layer Chips in den FireWire Adressbereich mappen. Der
Adress-Daten-Bus des MC währe, wie bereits erwähnt, auch über die 2.54mm
Pfosten verfügbar und erlaubt dadurch asynchronen Zugriff auf das Board,
auf dem das Modul eingesetzt wird.

Günter

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günther:

So was in der Art schwebte mir auch vor. Als Standard würde ich
IEEE1394a, also max. 400MBit/s, empfehlen. Für 1394b gibt es noch nicht
so viele LinkLayer (PHY) und PhysicalLayer (LLC). Texas hat dafür eine
ganze Bandbreite an 1394a LLC und PHYs, oder auch integrierte Varianten
(LLC+PHY) das wäre zu empfehlen. Der TSB43AB21A wäre ein guter Kandidat,
da ist alles in einem Device. Es gibt übrigens auch "integreted
devices" mit einem ARM7 drin (iceLynx), aber wir wollen ja die Kirche
im Dorf lassen :) Einen isochronen Transfer hinzubekommen wird nicht so
schwierig zu sein, man muß sich halt etwas ins Protokoll reinfuchsen und
den Stack so weit implementieren (siehe meine Literaturangabe weiter
oben).
Man müßte sich allerdings etwas für die PC-Seite ausdenken, das sollte
aber auch machbar sein. Ich selbst habe mal das AV/C-Protokoll in ein
Device implementiert, da braucht man auf der PC-Seite gar nix mehr zu
tun, sind alles Standardtreiber. Aber wir wollen ja keine
Videoanwendung machen :)

Mario

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mario:

Ein intergrierter Chip währe gut, was mir bei dem TSB43AB21A aufstösst
ist, dass er eine PCI-Schnittstelle hat.

Vielleicht müssten wir uns auch erst mal austauschen was die
Anforderungen bezüglich isochronen und asychronen Datenraten sein
sollen.

Meine Idee war die volle isochrone Datenrate ausnutzen zu können. Da
wahrscheinlich nur ein 8-bit AVR zum Einsatz kommt, würde die
asynchrone Datenrate entsprechend begrenzt sein.

Später könnte man mal über eine Version mit voller asynchroner
Datenrate denken. Ich habe gesehen das TI da einen Chip hat der dafür
ausgelegt ist.

Was ist denn deine Idee wie die Schnittstelle zu einem Host-Board
aussehen soll?

Mit der isochronen Übertragung kenne ich mich nicht so im Detail aus.
Habe nur mal etwas Logik für eine FPGA entwickelt, der Daten von einem
A/D-Wandler an den AV-Port eines PDI1394 gesendet hat. Was ich an dem
Chip so einfach fand war, der AV-Port nimmt einfach die rohen Daten und
generiert selber den isochronen Rahmen daraus. Über die Konfiguration
musste ich mich wiederum auch nicht kümmern, da das vom PC aus kam. Die
Register des Chips waren also über asychrone Requests erreichbar und
konnten vom PC aus konfiguriert werden.

Der Ansatz scheint mir den Aufwand auf der Modulseite einfach zu halten
und einen Teil der Komplexität auf die PC-Seite zu verlagern.

Mit einer PCI-Schnittstelle habe ich das Gefühl, dass das Modul
komplexer wird. Vielleicht sehe ich das aber auch falsch?

Das Anderson Buch habe ich hier vorliegen. Wirklich gut geschrieben.
Machmal hätte ich mir die Aufteilung der Themen etwas anders
gewünscht.


Günter

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Mario:

Jetzt hab ich mir das noch mal überlegt und vielleicht ist die
PCI-Schnittstelle doch nicht so schlecht. Dadurch das der LLC + PHY
integriert sind spart man einen Chip. Da könnte man noch eine FPGA
spendieren, der die Schnittstelle von der PCI-Schnittstelle zum
Host-Board darstellt.

Die einfachste Logik währe eine 1:1 Verdrahtung und man hat die
PCI-Schnittstelle als Interface zum Host.

Der FPGA erlaubt die Schnittstelle flexibel zu gestalten und dadurch
ist es möglich einen simplen 8-bit oder 32-bit Datenbus als
Schnittstelle zum Host zu ermöglichen, über den isochrone Daten
übertragen werden können.

Dadurch kann das eine Modul universell genutzt werden und durch die
entsprechende FPGA-Logik den Erfordernissen angepasst werden.

Günter

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, ich finde PCI kompliziert das ganze. Der PDI1394L40 besitzt ein
High-Speed-Data-Interface, genau wie der TSB42AB4 von TI, mit dem ich
schon gearbeitet habe. Ich denke ein "normales" paralleles Interface
ist einfacher. Aber den Protokoll-Stack muß man implementieren, da
kommt man nicht drum rum, und das ist wirklich kein kleines Projekt...
aber lohnen würde es sich.

Mario

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hättest du Interesse so ein Projekt zusammen zu machen?

Vielleicht sollen wir das auch bilateral per email weiter verfolgen, da
ja nicht allzu grosses Interesse daran zu bestehen scheint?

Günter

Autor: jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ebenfalls für eine schnelle Bildübertragung interessiere ich mich für
eine Datenverbindung, die ohne große Treiber auskommt und leicht in
vielen Programmiersprachen genutzt werden kann. Bisher verwende ich
noch HiSpeed USB, wollte nun aber auf Ethernet umsatteln. Etwas
schreckt mich der Aufwand der Headergenerierung für TCP/IP (oder etwas
einfacher UDP/IP). Wie sieht es mit FireWire aus? Auch darauf sollte
man ja via Socket-Verbindung zugreifen können. Gibt es da
Hardwarelösungen für schnelle TCP/IP-Stacks oder muß man auch hier die
Packete im FPGA generieren?

Gruß,

jörn

Autor: Max Müller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mich würde das hir weiter intressieren.
Wobei ich lieber ein 1394B interface hätte.
Am liebsten mit Kunststoffleiter verbunden und bidirektional.
Von der Datenrate reicht mir zwar auch 400MBit, aber 1394B führt mich
weiter in die industrial Anwendung.
Gibt es dazu in der FhG entsprechende Kontakte?

Ich würde das eventuell über die Firma, wo ich angestellt bin puschen.

Ein kleinen Stack (am besten für den AVR) wäre hier aber auch zwingend
notwendig.

Max

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ jörn

Es gibt da einige RFC's vom IETF die TCP/IP über IEEE1394
spezifizieren. Bei TI habe ich keine FireWire Chips gesehen die sogar
TCP/IP integrieren.

Wenn es unbedingt TCP/IP sein soll, hast du dir mal den W3100 Chip von
Wiznet angesehen? Der hat den TCP/IP-Stack in Hardware integriert:

http://www.iinchip.com/wiznet/product_assp.html

Ich weiß jedoch nicht was für einen Durchsatz der bringt.


@ Max:

Faser statt Kabel würde mich auch interessieren. Bei TI habe ich nur
einen 1394b LLC gesehen und der hat eine PCI-Schnittstelle. Das macht
das ganze erst mal etwas komplizierter. Von meiner Seite hätte ich auch
keine Testmöglichkeiten bezüglich 1394b.

Günter

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günter:
Wir können das Projekt gerne machen. Ich bin nur grad dabei, die
Wohnung zu wechseln, aber ab März wäre machbar. Mail mir einfach mal.

@jörn:
von Ethernet und schneller Bildübertragung würde ich abraten. No QoS.

@Max:
Natürlich gibt es dazu offizelle Kontake in der FhG IPMS Dresden
(www.ipms.fraunhofer.de). Wir haben einen 1394a-Stack auf einen C161
entwickelt. Er ist aber so ausgelegt, das er sich leicht auf andere
Plattformen portieren lässt. Mit 1394b über POF und GOF haben wir auch
schon Erfahrungen gesammelt. Es wird wohl keine Firma/Institut in
Deutschland geben, welches sich mehr mit FireWire beschäftigt, mein
Chef ist in der 1394 Trade Association. Mail mir einfach mal deine
Vorstellungen an: mario.grafe(at)ipms.fraunhofer.de.
Mario

Autor: Mario Grafe (mario)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nochmal @jörn:
Für FireWire gibt es eine ganze Palette von Protokollerweiterungen,
viele davon für Videoübertragung. Ich selbst z.B. habe das IEC61883 mit
AV/C als Kommunikationsprotokoll in den Stack implementiert. Da braucht
man überhaupt keinen Treiber mehr beim PC. Wenn der Rechner das Gerät
als IEC61883/AVC-Gerät erkennt (anhand des Config-ROMs), lädt er
Standard-Treiber, mit denen man das Gerät asynchron via AVC-Befehlen
steuern kann. Die Videoübertragung (MPEG-2 oder DV) erfolgt isochron
mit garantierter Bandbreite. Oder man nimmt die
DCAM-Protokollerweiterung, um unkomprimierte Videodatenströme zu
übertragen -> ebefalls keine Treiber am PC nötig. Schau dir mal bitte:
http://www.ipms.fraunhofer.de/products/index.shtml...
und dort "IEEE 1394 Software Stack und Protokolle" an.

Mario

Autor: JensB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ,

bin durch zufall auf dieses Forum gestossen und hab mal ne Frage. Ich
arbeite mit einem Pegasos , ein nachfolger des Amigas , und der hat
einige FireWire anschlüsse. Leider gibt es keinen Stack dazu und ein
bissle was wollte ich dafür Progen und warum nicht das. Meine Frage.
Gibt es irgendwo Deutsche beschreibungen zum Thema?? Nicht das ich kein
Englisch kann aber nicht sehr gut da ich noch ein Alter DDR Bürger bin
und erst Englisch in Mode kam als ich die 10Klasse machte. Dadurch
fehlt mir einiges an Englisch und das meiste hab ich mir selbst
erlernt. Wäre schön was in Deutsch zu bekommen und wenn's gehen würde
auch gut kommentierte beispiele oder code in Deutsch.

Mfg JensB

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jens

Ich kenne mich mit dem Pegasos nicht so aus. Was für ein Betriebssystem
hast du denn darauf?

Was du benötigst für FireWire ist eine Softwareschnittstelle
(Application Programmer Interface oder auch API) die unter deinem
Betriebsystem läuft.

Ich habe mal nach Pegasos gesucht und bin in der wikipedia auf eine
kurze Beschreibung gestossen:

http://de.wikipedia.org/wiki/Pegasos

Da sind noch einige Links angegeben. Wahrscheinlich findest du unter
anderen Pegasos Nutzern mehr Informationen darüber.

Gruß,

Günter

Autor: JensB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider gibt es für den Pegasos noch kein API für FireWire und ich wollte
mich mal darüber ein wenig schlau machen. Als OS läuft MorphOS ein vom
Amiga übenommenes system nur verbessert oder für manche auch
verschlechtert aber eben FireWire fehlt noch ;)

Autor: SupaChris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne viel Protokoll-Entwicklung gehts mit fertigen Firewire-Modulen. ICH
arbeite beim Fraunhofer IZFP in Dresden, und wir verwenden für unsere
Messgeräte die
"ultra-compact UC1394a-1 highly flexible single device
2-Port IEEE1394 (FireWire®) solution with IEEE1394a software stack"
von www.orsys.de Kosten in Einzelstückzahlen ca 300€ netto, aber
dafür muss man keine FireWirekenntnisse haben, äußerst leicht in
FPGA-Schaltungen zu integrieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.