Hallo,
Ich bin auf der Suche nach einer geschickten Mäglichkeit, viele Daten
extrem schnell via WLAN von einem FPGA zu einem PC zu senden.
Ein UART-basiertes System mit einem 802.11g Modul das bisschen weniger
als 1Mbps liefert habe ich am laufen, aber das ist grob mindestens
Faktor 50 zu langsam (wobei es beliebig schneller sein darf).
Aus diesem Grunde ist es notwenig, 802.11n zu verwenden. Serielle
Module, die über z.B. SPI arbeiten, sind immernoch zu langsam, welche
die über SDIO arbeiten sind ggf. schnell genug, aber die Auswahl ist
sehr beschränkt, falls die Module überhaupt schon bezogen werden können.
Also muss etwas her, das existiert und gut verfügbar ist. Ich dachte
dabei an USB Sticks oder PCIe Module mit mehr als 150 Mbps, wie sie von
PCs verwendet werden. Die Preise sind gut und die Verfügbarkeit auch.
Das Problem das es dabei zu überwinden gilt, ist der Anschluss und die
Treiber.
Jetzt ist die Frage: wie mach ich das am schlausten:
a) FPGA über nen vielleicht 32 Bit breiten parallellen Datenbus an einen
ARM µC mit USB 2.0 Host Schnittstelle anschließen, Embedded linux laufen
lassen, USB-WLAN-Stick anschließen und gut ist?
b) MicroBlaze (Softcore CPU) in den FPGA prorgammieren, darauf Linux
laufen lassen? Ist so ein Softcore schnell genug?
c) Treiber im FPGA relalisieren? Ist denke ich ein ungeheurer Aufwand,
oder existiert IP die man sich da einfach reinziehen kann?
d) Etwas anderes, woran ich noch nicht gedacht habe?
Ich persönlich favorisiere a), hab aber keine Ahnung von ARM-µC und
Embedded Linux. Von dem her würde es mich interessieren, ob das so
einfach geht, oder ob ich mit irgendwelchen Komplikationen rechnen muss
(z.B. dass der ARM-µC und das Linux zu langsam sind aufgrund von
Scheduler etc...)
Wäre klasse, wenn ich hier ein paar Tipps/Infos von Leuten bekommen
könnte, die sich mit den genannten Dingen (embedded linux, Treiber in
FPGA, ARM-µC etc...) schon beschäftigt haben.
Johannes schrieb:> Ich bin auf der Suche nach einer geschickten Mäglichkeit, viele Daten> extrem schnell via WLAN von einem FPGA zu einem PC zu senden.
Was genau bedeutet extrem schnell? Da bräuchte man schon einen
numerischen Wert. Wenn du den noch nicht weißt, dann solltest du mal an
dieser Stelle beginnen.
Extrem schnell ist ziemlich relativ. Manche sagen, dass der Intel i7 in
Maximalausführung mit 80 GigaFLOPs das non plus Ultra ist während ein
Metrologe bei Wettersimulationen über 800 TerraFLOPs noch einschläft ...
Johannes schrieb:> PCIe Module
Eine gute Idee - zum Einstieg: auf www.fpga4fun.com gibt es ein Beispiel
zum Thema PCI und Konsorten. Der Treiber dürfte gut Aufwändig werden -
da müsste man schauen, ob man eine PCI Karte bekommt über deren IC was
bekannt ist ...
Johannes schrieb:> FPGA über nen vielleicht 32 Bit breiten parallellen Datenbus an einen> ARM µC mit USB 2.0 Host Schnittstelle anschließen, Embedded linux laufen> lassen, USB-WLAN-Stick anschließen und gut ist?
Das würde zumindest das Treiberproblem eliminieren. Wird eine sportliche
Sache. Wie steht es um den FPGA bestellt? Was sind da
Geschwindigkeitsmäßig die Limiten ?
Johannes schrieb:> b) MicroBlaze (Softcore CPU) in den FPGA prorgammieren, darauf Linux> laufen lassen? Ist so ein Softcore schnell genug?http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/microblaze;hb=HEADJohannes schrieb:> Ich persönlich favorisiere a), hab aber keine Ahnung von ARM-µC und> Embedded Linux. Von dem her würde es mich interessieren, ob das so> einfach geht, oder ob ich mit irgendwelchen Komplikationen rechnen muss> (z.B. dass der ARM-µC und das Linux zu langsam sind aufgrund von> Scheduler etc...)
Ich würde persönlich auch A wählen.
Wegen der Geschwindigkeit: Es kommt darauf an was für einen ARM du
verwendets unter welchen Betriebsparametern du ihn betreibst.
Das könnte interessamt sein:
http://www.comp.leeds.ac.uk/jj/linux/arm-sbc.html#Linux%20on%20the%20TS-7200
(generell der gesamte Inhalt dieser Seite).
Viel Erfolg
Hey, danke für die ausführliche Antwort! Werde mir das Material das du
verlinkt hast gleich mal angucken.
Was die Geschwindigkeit angeht: Ich bekomm im FPGA mehrere Gigabit/s an
Daten, von denen ich soviel wie möglich an den PC senden möchte. Das ist
natürlich utopisch. Von dem her würde ich mich halt mit dem was 802.11n
so her gibt (150/300/450/600 Mbps, abhängig vom verwendeten Modul/Stick
und dessen Fähigkeiten) zufrieden geben.
Prinzipiell sollten 150 Mbps schon für die Anwendung reichen, aber da
USB 2.0 bis 480 Mbps leisten kann, wärs nicht verkehrt das System auf
300 oder 450 Mbps auszulegen. Je mehr Daten ich so übertragen bekomme,
desto besser.
Der FPGA der derzeit verwendet wird, kann bis 450 MHz betrieben werden.
Aber auch da könnte man wahrscheinlich einen schnelleren nehmen, falls
notwendig...
Das Problem liegt nicht beim FPGA sondern beim ARM, für die volle
Bandbreite bei 802.11n müsstest du schon PCIe nehmen. Als Linux Treiber
würde ich den ath9k vorschlagen.
Danke für den Input.
Dass ein Kabel die bessere Alternative ist, denke ich mir auch, aber die
Anwendung verlangt nunmal komplett drahtlos zu sein.
Was die WLAN Geschwindigkeit angeht: Mir ist bewusst, dass die 150 Mbps
zum Beispiel der "physikalische" Wert ist. Der Wert an Userdaten liegt
aufgrund von TCP/IP overhead etc. selbstverständlich darunter...
wieviele Antennen ich am Ende brauche und ob der Accesspoint in der Nähe
ist, ist zunächst mal egal und kann angepasst werden. Der PC kann
wahrscheinlich auch via Gbit-Lan an den AP angeschlossen sein.
Problematischer ist da vielmehr, dass ich wohl 6+ dieser Geräte in einem
System habe. Da die sich gegenseitig in die quere kommen, brauch ich
halt möglichst schnelle Übertragung - ggf. mit mehreren Accesspoints und
unterschiedlichen Kanälen. Aber ich denke mit 150 Mbps wäre ich schon
gut dabei.
Was die Geschwindigkeit des ARM und PCIe angeht: Wie schnell muss so ein
ARM getaktet sein, dass ich davon ausgehen kann, dass er den Datenstrom
schnell genug in ein PCIe Modul oder USB Stick pumpen kann?
Johannes schrieb:> Danke für den Input.> Dass ein Kabel die bessere Alternative ist, denke ich mir auch, aber die> Anwendung verlangt nunmal komplett drahtlos zu sein.>> Was die WLAN Geschwindigkeit angeht: Mir ist bewusst, dass die 150 Mbps> zum Beispiel der "physikalische" Wert ist. Der Wert an Userdaten liegt> aufgrund von TCP/IP overhead etc. selbstverständlich darunter...> wieviele Antennen ich am Ende brauche und ob der Accesspoint in der Nähe> ist, ist zunächst mal egal und kann angepasst werden. Der PC kann> wahrscheinlich auch via Gbit-Lan an den AP angeschlossen sein.> Problematischer ist da vielmehr, dass ich wohl 6+ dieser Geräte in einem> System habe. Da die sich gegenseitig in die quere kommen, brauch ich> halt möglichst schnelle Übertragung - ggf. mit mehreren Accesspoints und> unterschiedlichen Kanälen. Aber ich denke mit 150 Mbps wäre ich schon> gut dabei.
Ich glaube, du hast völlig falsche Vorstellungen von WLAN.
Evtl. hilft auch eine ausführliche Beschreibung der Projektziele weiter.
Ich arbeite seit mehreren Monaten mit mehreren Geräten in dem Projekt,
die mit 802.11g arbeiten. Ich beobachte dabei auf regelmäßiger Basis den
TCP/IP traffic mit Wireshark, schau mir an, ob ich einen Kanal verwende,
auf dem wenig los ist, hab mich informiert, was der maximale
Nutzdaten-Durchsatz von b und g ist etc... Von dem her würde ich schon
sagen, dass ich eine grundlegende Vorstellung habe, was zumindest b und
g WLANs angeht. 802.11n, kann eine andere Geschichte sein, die hab ich
mir noch nicht komplett angeguckt.
Und zur Projektbeschreibung:
6 Geräte produzieren simultan mehrere Gbit Daten pro Sekunde, von denen
soviel wie möglich drahtlos über ein paar Meter Entfernung mittels WLAN
(802.11) an einen PC (ggf. über den AP) übertragen werden sollen.
Relevant ist dabei, dass die Daten zeitgleich erfasst werden und daher
auch quasi-zeitgleich übertragen werden müssen, da ein FPGA halt nur
einen begrenzten Puffer darstellt.
Also: Daten werden gesammelt bis die Puffer voll sind, dann werden die
Daten "zeitgleich" verschickt und dann werden neue Daten gesammelt
sobald alle Puffer wieder leer sind. Endlosschleife.
