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
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.
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
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...
@ 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
@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
@ Michael, Digilent hat ein USB2 Interface für Ihre FPGA boards. http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Accessory&Cat=Accessory 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
@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
@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
@ 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
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
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
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
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
@ 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
@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
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?products_12.shtml und dort "IEEE 1394 Software Stack und Protokolle" an. Mario
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
@ 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
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 ;)
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.
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.