www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FTDI USB 2.0 Chips Virtual COM Port Geschwindigkeit?


Autor: Anguel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Kann mir jemand definitiv sagen, welche max. Geschwindigkeit ein FTDI 
USB 2.0 high-speed Chip (z.B. FT2232H) über Virtual COM Port (VCP) 
Treiber schafft? Irgendwie konnte ich das nicht aus den Datasheets 
ableiten. Ich möchte den Chip evtl. an ein FPGA klemmen. Danke im 
Voraus.

Grüße,
Anguel

Autor: mki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau mal im Hyperterminal nach. Dort kann man maximal 921600 Bits pro 
Sekunde einstellen. Und das habe ich mit einem FTDI USB 1.1 Chip auch 
schon geschafft. Zwar schleichen sich bei höheren Geschwindigkeiten auch 
mehr Fehler ein, aber das ist ja ein anderes Problem.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tipp! Leider habe ich den Chip noch nicht. Sowas müsste 
doch in einem Datasheet stehen. Ich habe an FTDI geschrieben, mal sehen 
was die antworten.

mki schrieb:
> Schau mal im Hyperterminal nach. Dort kann man maximal 921600 Bits pro
> Sekunde einstellen. Und das habe ich mit einem FTDI USB 1.1 Chip auch
> schon geschafft. Zwar schleichen sich bei höheren Geschwindigkeiten auch
> mehr Fehler ein, aber das ist ja ein anderes Problem.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu dem FT2232H kann ich nichts sagen, aber dem FT245 habe ich schon 
>500kByte/s in der Richtung PC->FT245 über den VCP entlocken können.
In umgekehrter Richtung waren es glaube ich um die 300kByte/s.
Mit dem D2XX Treiber waren in Richtung PC auch mal 700kByte/s möglich.
Das Ding ist also ganz schön flott wenn die Hardware nachkommt die Daten 
wegzuschaffen, bzw. zu liefern.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessant, eigentlich redet FTDI von Unified Driver Model und der COM 
Port ist eh nur virtuell, trotzdem gibt es Unterschiede in der 
Geschwindigkeit im Vergleich zu D2XX. Ist die Geschwindigkeit der 
virtuellen COM Ports eigentlich durch etwas begrenzt, oder könnte ich 
unter Windows auch Datenraten von 2MByte/s z.B. mit LabVIEW erreichen?

Benedikt K. schrieb:
> Zu dem FT2232H kann ich nichts sagen, aber dem FT245 habe ich schon
>>500kByte/s in der Richtung PC->FT245 über den VCP entlocken können.
> In umgekehrter Richtung waren es glaube ich um die 300kByte/s.
> Mit dem D2XX Treiber waren in Richtung PC auch mal 700kByte/s möglich.
> Das Ding ist also ganz schön flott wenn die Hardware nachkommt die Daten
> wegzuschaffen, bzw. zu liefern.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anguel S. schrieb:
> Interessant, eigentlich redet FTDI von Unified Driver Model und der COM
> Port ist eh nur virtuell, trotzdem gibt es Unterschiede in der
> Geschwindigkeit im Vergleich zu D2XX.

Vermutlich liegt das an dem zusätzlichen Overhead durch die Weitergabe 
der Daten an das Betriebssystem, während man mit D2XX direkt in den 
Puffer des FTDI Treibers schreiben kann (und damit schön einen 
Bluescreen erzeugen kann, da FTDI einen Pufferüberlauf beim Senden nicht 
abgefangen hat).

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"RS232/RS422/RS485 UART Transfer Data Rate
up to 12Mbaud. (RS232 Data Rate limited by
external level shifter)."

Datenblatt FT2232H. 1. Seite

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da ist aber gar kein External Level Shifter wenn alles direkt über USB 
geht oder verstehe ich etwas falsch?

ich schrieb:
> "RS232/RS422/RS485 UART Transfer Data Rate
> up to 12Mbaud. (RS232 Data Rate limited by
> external level shifter)."
>
> Datenblatt FT2232H. 1. Seite

Autor: Sebastian B. (sfreak) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anguel S. schrieb:
> ich schrieb:
>> "RS232/RS422/RS485 UART Transfer Data Rate
>> up to 12Mbaud. (RS232 Data Rate limited by
>> external level shifter)."
>>
>> Datenblatt FT2232H. 1. Seite
>
> Da ist aber gar kein External Level Shifter wenn alles direkt über USB
> geht oder verstehe ich etwas falsch?

Mit der USB-Seite hat das nix zu tun. Das heisst blos das, wenn du einen 
externen Pegelwandler an der RS232-Seite des FTDI anschliesst, der mit 
dieser hohen Geschwindigkeit auch mitkommen muss (mit standard MAX232 
ist schon bei 115k Schluss). Wenn du die ganze Geschichte an einen FPGA 
haengen willst brauchste natuerlich wahrscheinlich gar keinen Konverter 
=> kein Problem.

Sebastian

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau das meinte ich.

Sebastian B. schrieb:
> Wenn du die ganze Geschichte an einen FPGA
> haengen willst brauchste natuerlich wahrscheinlich gar keinen Konverter
> => kein Problem.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Antwort von FTDI:

The speed is not only decided by the driver type but also many other 
factors such as operation mode and so on.
Please refer to the application note: 
http://ftdichip.com/Documents/AppNotes/AN232B-04_D...

Werde mir das ganze mal anschauen. Leider ist die App Note schon etwas 
älter.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der COM-Treiber wird in jedem USB Mikroframe nur einen Read request 
absetzen. Mit 512 Bytes USB Blocksize und davon 2 Bytes 
Statusinformation kommt man dann maximal auf 8000 x 510 Byte = 
4MByte/Sekunden. Ein extra Treiber  oder ein Programm, dass libusb oder 
evt auch libftd2xx nutzt, kann auch mehr Requests pro Mikroframe 
absetzen und so deutlich hoeher kommen. Ob der VCP Treiber eine 
entsprechend hohe Bausrate setzen kann, ist eine andere Frage.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe Bonnes schrieb:
> maximal auf 8000 x 510 Byte =
> 4MByte/Sekunden.
> Ob der VCP Treiber eine
> entsprechend hohe Bausrate setzen kann, ist eine andere Frage.

Vielen Dank für die Info! 4MByte/s hört sich gut an, auch wenn nur 
theoretisch - müsste ich dann also kaufen und testen :) Die Frage ist 
letztendlich, welcher USB 2.0 Chip für meine Anwendung am besten 
geeignet ist. Am besten beschreibe ich aber zuerst, was ich genau machen 
möchte:

Ich sample Daten mit einem A/D-Wandler der am FPGA hängt, verarbeite 
diese evtl. und streame sie an einen Host-PC über USB 2.0 (auf dem PC 
läuft z.B. LabVIEW). Die geforderte Datenrate ist dabei ca. 2 MByte/s. 
Der Host-PC sendet nur kurze Befehle an das FPGA, um z.B. zu sagen, wann 
das Streaming starten bzw. enden soll.

Welcher USB 2.0 Chip wäre aus eurer Erfahrung in meinem Fall am besten 
geeignet? FTDI? Cypress? Ich kenne bisher nur die FTDI Chips und davon 
nur die langsameren. Ich wollte FTDI nutzen, weil der Treiber viele 
Betriebssysteme unterstützt und das gute am VCP Treiber ist, dass man 
das Ding dann als normalen COM-Port sieht. Ich sehe, dass Xilinx auf 
deren Demo-Boards den Cypress USB 2.0 Chip verwendet. Wäre das eine gute 
Alternative? Danke im Voraus für jede Empfehlung.

Grüße,
Anguel

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wir verwenden für sowas (nur bissl schneller) den Cypress FX2 im 
Slave FIFO Modus. Geht super und liefert knapp 40MB/s, wenn man die 
daten schnell genug anliefern kann und der PC auch schnell genug 
abnimmt. Und man muss große Blöcke übertragen, sonst hat man die 
gleichen 4MB/s Maximum.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Christian! Hab in der Zwischenzeit auch nochmal geschaut und so 
ziemlich alle Designs scheinen FX2 zu verwenden. Soweit ich das 
überblicke, sollte es auch für die meisten Betriebssysteme (Win, Linux, 
Mac OS) auch Standardtreiber von Cypress geben, so dass das Gerät sofort 
erkannt wird, oder?

Christian R. schrieb:
> Also wir verwenden für sowas (nur bissl schneller) den Cypress FX2 im
> Slave FIFO Modus. Geht super und liefert knapp 40MB/s, wenn man die
> daten schnell genug anliefern kann und der PC auch schnell genug
> abnimmt. Und man muss große Blöcke übertragen, sonst hat man die
> gleichen 4MB/s Maximum.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem FT2232H wirst Du keine Probleme haben dies zu schaffen. die 
ganzen Beiträge gehen noch von den älteren Versionen aus. Der H-Typ kann 
sowohl parallel als auch seriell betrieben werden. Im parallelen Betrieb 
kann pro Kanal je 12 MByte übertragen werden. Davon hast Du im Notfall 
ja zwei. Der H-Typ ist ja ein High-Speed-Device (480 M-Bit). Die älteren 
Typen sind nur Full-Speed.

Allerdings solltest Du den Chip im parallelen Mode betreiben. Seriell 
sind maximal 12 MBaud möglich. Also ca. 1 MByte Pro Kanal.

Viel entscheidender ist aber die PC-Seite. Dort müssen die Daten ja auch 
zeitlich abgeholt werden können. Wenn der PC mal schnell in einen dummen 
Task abtaucht oder ein anderes USB-Device angesteckt wird, dann taucht 
der Rechner auch mal schnell für einige Sekunden ab. Es wäre deshalb 
durchaus sinnvoll mal so 10 Sekunden Daten zwischenspeichern zu können. 
Also Speicher am FPGA nicht vergessen. Mit dem internen kommst Du da 
nicht weit.

Egal was für ein Chip verwendet wird. Das Problem mit dem Puffer besteht 
überall.

Alternativ kannst Du ja mal über Ethernet nachdenken.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, der FX2 ist ziemlich verbreitet. Wahscheinlich weil das nahezu 
das einfachste USB 2.0 HighSpeed Bauteil ist. Puffern muss man natürlich 
echt viel, wenn man durchgängig hohe Datenraten fahren will. Treiber 
gibts zumindest für Win und Linux, geht ja auch mit der LibUSB 
problemlos.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke nochmals an alle für die Infos!

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FX2 braucht eine eigene Firmware, FT2232H braucht keine Firmware...

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre das Problem mit dem Puffern durch Ethernet behoben?

Matthias G. schrieb:
> Egal was für ein Chip verwendet wird. Das Problem mit dem Puffer besteht
> überall.
>
> Alternativ kannst Du ja mal über Ethernet nachdenken.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe leider bisher nicht so viele Referenzimplementierungen mit dem FTDI 
gefunden, während der FX2 fast schon eine Art "Standard" zu sein 
scheint.
Außerdem lese ich auch negetives über FTDI:

http://www.embeddedrelated.com/usenet/embedded/sho...

http://www.8052.com/forum/read/161005


Uwe Bonnes schrieb:
> FX2 braucht eine eigene Firmware, FT2232H braucht keine Firmware...

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der FX2 ist schon meherer Jahre auf dem Markt, der FT2232H erst seit 
letztem Jahr. Das erklaert die Anzahl der veroeffentlichten Designs.

Ob die Probleme un den Baustein, oder in dem liegen, was die Leute damit 
machen, kann ich nicht sagen. Ich habe zwar ein Demoboard, bin aber noch 
nicht zum Programmieren gekommen...

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde mich diesbezüglich jederzeit auf Feedback freuen. Wo kann man 
eigentlich so ein Demo-Board kaufen?

Uwe Bonnes schrieb:

> Ob die Probleme un den Baustein, oder in dem liegen, was die Leute damit
> machen, kann ich nicht sagen. Ich habe zwar ein Demoboard, bin aber noch
> nicht zum Programmieren gekommen...

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

die VCP-Treiber bringen nicht die optimale Performance, besser faehrt 
man mit den D2XX-Treibern im FIFO oder MPSSE-Mode. Zur Anbindung ans 
FPGA ist die FIFO-Schnittstelle ziemlich simpel zu implementieren, wenn 
Du genug Pins hast. SPI habe ich noch nicht probiert, aber JTAG schafft 
beim maximalen Clock schon ca. 2MByte/s transfer (und das Protokoll ist 
nicht effizient).

Ich benutze den 2232H v.a. unter Linux via modifizierte libftdi und kann 
den Chip ziemlich bedingungslos empfehlen. Mit einem wirklich dummen 
Protokoll, dass viele Reads/Writes macht, sind's um die 5MByte/s an 
write, bei read etwas weniger.
Den FX2 habe ich auch eingesetzt, der Chip ist auf jeden Fall lecker, 
aber fuer die meisten Zwecke zu komplex, da wie gesagt, Firmware noetig 
(viel Spass beim Debugging..)
Ausserdem gibt es die ueblichen laestigen Nachteile: Wer sein Geraet auf 
den Markt werfen moechte, muss sich mit den bescheuerten VID/PID 
policies der usb.org herumschlagen. Bei FTDI ist man da eher generoes 
mit einem kostenlosen PID 8er-Block.

Zum Thema Referenzimplementierungen: Der 2232H ist gegenueber dem 2232L 
softwarekompatibel, Designs lassen sich also sehr leicht 'upgraden'.

Gruss,

- Strubi

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch mal zur Frage Datenbuffer: Um den wird man bei keinem Bussystem 
herum kommen. Das hängt in Deiner Anwendung aber vor allem an der 
PC-Seite. Betriebssystem etc.

Die neueste FTDI-Generation habe ich noch nicht in Verwendung, aber bei 
den älteren ist die Handhabung denkbar einfach. Ein virtueller COM-Port 
ist sehr leicht überall zu implementieren. Dadurch, dass der Virtuell 
ist, hat der ja nichts mit Gewschwindigkeit zu tun. Auf der 
Hardwareseite ist quasi ebenfalls nichts zu tun. Also schon fast 
Hardware-Plug-and-Play. Wenn es nicht zwingende Gründe gibt, wäre für 
mich die FTDI-Lösung die 1. Wahl.

Noch mal zurück zur Ethernetschnittstelle:
Ethernet ist im Vergleich zu USB deutlich robuster. Mal abgesehen von 
der Netwerkfähigkeit etc. bietet das physische Übertragungsmedium schon 
eine galvanische Trennung  (Trafos in oder vor der Buchse). Dadurch ist 
es deutlich weniger Störanfällig und es kommt auch nicht zu 
Masseschleifen, die vor allem bei Analog-Anwendungen immer wieder zu 
Problemen führen. Zudem "kakt" bei ESD, Burst und Surge regelmäßig die 
USB-Schnittstelle weg. Daher: USB ist nicht Insustrietauglich (außer für 
Firmwareupdates) und auch nur Bedingt Labortauglich, wenn es um 
Messungen geht.

Vorteil USB: Bei moderatem Energiebedarf und lokaler Anwendung als 
Stand-Alone-Gerät kann man über ein Kabel alles erschlagen. Und bei 
Verwendung von solchen Schaltkreisen wie die von FTDI wird auf der 
Hardware für die Schnittstelle kein Controller benötigt.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USB als per se nicht industrietauglich abzutun, halte ich für gewagt. 
Wir haben hier ordentlich ausgeführte USB Verkabelungen in harschen 
Umgebungen im Einsatz, durchdachtes EMV Design mit FX2 als Device 
Controller. Bisher ist auch in den rauhen Umgebungen noch nicht ein Byte 
verloren gegangen. Das kommt nur mal an schrottigen USB Host Controllern 
vor, mit VIA kann man da viel Spaß haben.

Ethernet ist an sich super, allerdings ist der Aufwand einige 
Größenordnungen höher als bei USB.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias G. schrieb:
> Ein virtueller COM-Port
> ist sehr leicht überall zu implementieren. Dadurch, dass der Virtuell
> ist, hat der ja nichts mit Gewschwindigkeit zu tun. Auf der
> Hardwareseite ist quasi ebenfalls nichts zu tun. Also schon fast
> Hardware-Plug-and-Play. Wenn es nicht zwingende Gründe gibt, wäre für
> mich die FTDI-Lösung die 1. Wahl.

Für mich auch, dumm nur, dass der VCP Treiber anscheinend doch langsamer 
ist als der D2XX (siehe andere Postings)... Sonst würde ich die FTDI 
VID/PID drin lassen und dann läuft das Teil auf etlichen 
Betriebssystemen ohne Problem und man kann es in allen 
Programmiersprachen als Seriellen Port ansprechen (mein Target ist vor 
allem LabVIEW).

> Noch mal zurück zur Ethernetschnittstelle:
> Ethernet ist im Vergleich zu USB deutlich robuster.

Ich würde es natürlich vorziehen, aber die Nachteile von Ethernet die 
ich sehe:
1. Kein Host-Powered-Mode wie bei USB. Welcher PC hat schon PoE?
2. Wie konfiguriere ich die IP-Adresse. Wenn Lantronix nur Ethernetchips 
mit parallelem Interface anbieten würde, wäre alles einfach...
3. Man braucht einen Switch, da man am Laptop meist nur einen 
Ethernet-Port hat.
4. Implementierung im FPGA: Man braucht EDK. Ok kostet nicht die Welt, 
aber was für einen FPGA-Chip soll man dann nehmen? XC3S500E soll evtl. 
zu klein für Ethernet Lite sein?

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> USB als per se nicht industrietauglich abzutun, halte ich für gewagt.

Ok, da gebe ich Dir recht.

> Wir haben hier ordentlich ausgeführte USB Verkabelungen in harschen
> Umgebungen im Einsatz, durchdachtes EMV Design mit FX2 als Device
> Controller. Bisher ist auch in den rauhen Umgebungen noch nicht ein Byte
> verloren gegangen. Das kommt nur mal an schrottigen USB Host Controllern
> vor, mit VIA kann man da viel Spaß haben.

Meist hat man in den Anwendungen aber auch eine galvanisch Trennung am 
USB-Controller zur eigentlichen Hardware-Applikation. Damit ist aber 
auch gleich der Vorteil der Energieübertragung über USB mit hin. Man 
könnte da zwar auch noch mit DCDC-Wandlern arbeiten, aber auch die haben 
meist relativ hohe Kapazitäten zwischen Primär und Sekundär. Konkret 
hatte ich da schon Probleme, wenn dann in der Anwendung z.B. 
Hochspannungspulse >1kV mit 20-100A vorhanden sind (Prozessbedingt). Da 
reichen auch schon kleinste Kapazitäten über DCDC-Wandler für solche 
Effekte. Bei Ethernet gibt es da keinerlei Probleme.

> Ethernet ist an sich super, allerdings ist der Aufwand einige
> Größenordnungen höher als bei USB.

Ja, leider. Es ist letztlich immer eine Entscheidung die im Hinblick auf 
die Gesamt-Anwendung bezogen werden muss.

Zur Größe des FPGAs bei Ethernet ist immer die Frage, wie viel man vom 
"Ethernet" in den FPGA verlegen will. Eine Phy braucht man sowieso und 
es gibt ja auch Schaltkreise, die einen MAC und eine Phy enthalten. Da 
reicht dann ein kleiner 8-Bit µC im FPGA (oder sogar in einem CPLD). 
Oder man verwendet gleich einen externen µC mit MAC.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias G. schrieb:

> Zur Größe des FPGAs bei Ethernet ist immer die Frage, wie viel man vom
> "Ethernet" in den FPGA verlegen will. Eine Phy braucht man sowieso und
> es gibt ja auch Schaltkreise, die einen MAC und eine Phy enthalten. Da
> reicht dann ein kleiner 8-Bit µC im FPGA (oder sogar in einem CPLD).
> Oder man verwendet gleich einen externen µC mit MAC.

Naja, wenn man nur 100MBt/s braucht, ist das alles recht entspannt. Bei 
GbE siehts schon schwieriger aus, da muss man dann schon einen Virtex 4 
FX oder sowas auffahren....um die 40MB/s vom USB 2.0 zu erstzen.

Übrigens gibts für galvanische Trennung und lange Kabel die IRanger 
Lösungen von Icron.

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Strubi: Hast Du Deine Modifikationen auf der linftdi Liste diskutiert?

@Anguel S:  Mit libUSB/libftdi kannst Du auch auf Windows auf die FTDI 
Chips zugreifen, auch wenn das System VCP Treiber geladen hat.

Autor: Matthias G. (mgottke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Übrigens gibts für galvanische Trennung und lange Kabel die IRanger
> Lösungen von Icron.

Da kann man ja gleich WLAN oder was vergleichbares machen. Zudem ist die 
maximale Datenrate auf 54 MBit doch recht dürftig um dann reell auf die 
mittlere Datenrate von 4MByte zu kommen.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias G. schrieb:
>> Übrigens gibts für galvanische Trennung und lange Kabel die IRanger
>> Lösungen von Icron.
>
> Da kann man ja gleich WLAN oder was vergleichbares machen. Zudem ist die
> maximale Datenrate auf 54 MBit doch recht dürftig um dann reell auf die
> mittlere Datenrate von 4MByte zu kommen.

Deswegen Icron. Da kannst du Lichtleiter nehmen und hast die vollen 
480MBit/s von USB 2.0, das Ding verhält sich wie ein Hub. Wir haben das 
in der Cat5 Variante, klappt wunderbar über 60m.

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias G. schrieb:
> Zur Größe des FPGAs bei Ethernet ist immer die Frage, wie viel man vom
> "Ethernet" in den FPGA verlegen will. Eine Phy braucht man sowieso und
> es gibt ja auch Schaltkreise, die einen MAC und eine Phy enthalten. Da
> reicht dann ein kleiner 8-Bit µC im FPGA (oder sogar in einem CPLD).
> Oder man verwendet gleich einen externen µC mit MAC.

Ich dachte da eher an etwas fertiges, was sich mit dem EDK 
zusammenclicken ließe :) Das Problem ist, dass ich noch keine 
FPGA-Erfahrungen habe.
Meine Applikation würde so aussehen: Sampling mit 1 MSample/s mit 16 bit 
A/D. Gesamplete Daten werden entweder in externes DDR SDRAM gepackt und 
später auf Anforderung zum PC übertragen oder aber gleich über USB (oder 
evtl. Ethernet) gestreamt. Da klar wurde, dass auch Buffering benötigt 
wird, könnte man IMHO den externen RAM auch gleich als Puffer nutzen. 
Tipps sind an dieser Stelle herzlich willkommen :) Nun dachte ich 
bisher, dass das RAM-Interface (inkl. RAM-Controller) mit den Xilinx 
Tools (MIG) einfach zu realisieren wäre. Habe aber vorhin hier im Forum 
ein paar Beiträge gelesen und es scheint doch nicht so unproblematisch 
zu sein. Ob sowas in einen XC3S500E passt?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anguel S. schrieb:

Naja, EDK ist ohne Erfahrung ein steiler Weg. Aber Microblaze plus 
xps_ethernet_lite wäre schon ein Anfang. Dann aber noch den IP-Core 
(PLB-Slave oder FSL) für deine Hardware schreiben...naja.
Für die Geschwindigkeiten reicht dir ja SRAM oder gar der interne 
BlockRam, da brauchst du keinen MIG (ist eher für SDRAM, DDR, DDR2...).
Schau dir mal die Quellem vom gnuRadio an, FPGA plus Cypress FX2.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Uwe,

> Hast Du Deine Modifikationen auf der linftdi Liste diskutiert?

Nee, ehrlich gesagt, weiss ich nicht mal mehr, was ich veraendern 
musste. Irgendwas ging nicht, kann sein, dass es die Anzahl Ports (ev. 
beim 4232-Typen) war. Werde mir demnaechst mal die neuesten Sourcen 
ziehen und diffen, gehe mal davon aus, dass inzwischen auch die Userbase 
fuer den 2232H gewachsen ist und sich die Anfangsprobleme geloest haben. 
Irgendwas war da noch mit dem USB port claiming, aber aus Zeitmangel 
habe ich mich darum nicht mehr gekuemmert.

Gruss,

- Strubi

Autor: Anguel S. (anguel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> Für die Geschwindigkeiten reicht dir ja SRAM oder gar der interne
> BlockRam, da brauchst du keinen MIG (ist eher für SDRAM, DDR, DDR2...).

Hab ich mir auch so gedacht, leider hat das Spartan 3E Starter nur DDR 
SRAM :(

> Schau dir mal die Quellem vom gnuRadio an, FPGA plus Cypress FX2.

Danke für den Tipp! Das sieht sehr interessant aus. Sieht aber auch nach 
ziemlich viel Code aus. Wenn es nur VHDL wäre, so muss ich erstmal auch 
Verilog lernen :) Naja, ich glaube ich arbeite mich erstmal langsam in 
die Welt der FPGAs ein. Gibt es vielleicht ein gutes Buch, was vor allem 
die Zusammenhänge gut erklärt? Man findet hier und dort etwas, verliert 
aber so den Überblick, z.B. wie einzelne Module miteinander 
synchronisiert werden etc.

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich benutze den 2232H v.a. unter Linux via modifizierte libftdi und kann
> den Chip ziemlich bedingungslos empfehlen. Mit einem wirklich dummen
> Protokoll, dass viele Reads/Writes macht, sind's um die 5MByte/s an
> write, bei read etwas weniger.

Hi Strubi,

Ich habe mir mal libftdi direkt aus dem Git-Repository gezogen und damit 
versucht eine Baudrate von 6 bzw 12 MBit/s einzustellen. Allerdings 
verweigert mir damit die Lib den Dienst mit der Meldung:
"unable to set baudrate: -1 (Unsupported baudrate. Note: bitbang 
baudrates are automatically multiplied by 4)"
Auf Grund der 5 M*Byte*/s die du angibst nehme ich zwar an, dass du eh 
nen andren Mode benutzt, aber der dürfte ja den gleichen Probs 
unterliegen. Wie hast du das geschafft, so hohe Datenraten einzustellen?

Grüße,
Chris

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.