www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FPGA an WLAN 802.11n anbinden - Konzeptsuche


Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

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#...

(generell der gesamte Inhalt dieser Seite).

Viel Erfolg

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: loser1234 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
denk auch dran, daß WLAN nicht gerade störunempfindlich ist. für mich 
wäre ein kabel bzw. gigabit LAN die bessere wahl.

Autor: WLAN Kabel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WLAN schafft auch nur dann >100MBit/s wenn Du wirklich drei Antennen 
verwendest und nicht weit vom AP entfernt bist...

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Matte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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]
  • [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.