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=HEAD Johannes 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.
denk auch dran, daß WLAN nicht gerade störunempfindlich ist. für mich wäre ein kabel bzw. gigabit LAN die bessere wahl.
WLAN schafft auch nur dann >100MBit/s wenn Du wirklich drei Antennen verwendest und nicht weit vom AP entfernt bist...
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.
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.