Hallo, da ich als stiller Mitleser hier in Forum schon einige hilfreiche Tipps entdeckt habe, möchte ich mich heute erstmals mit einer Frage an Euch wenden. Und zwar geht es mir darum einen geeignetes FPGA-Chip oder Entwicklungsboard für mein Projekt zu finden: Hierbei geht es um verschiedene Sensoren welche über SPI kommunizieren und später mit einem eigenen FPGA in ein Gehäuse eingebaut werden sollen. Diese Module sollen später wie ein TAP ihre Daten über Ethernet an einen PC senden. Jedoch möchte ich nicht jedes Modul direkt mit dem PC verbinden sondern nur eine Verbindung zum PC haben und dafür die Module aneinander reihen. Das ganze ist bewusst dezentral gehalten und nicht alle Sensoren an einem FPGA angebunden um eine gewisse Modularität zu erreichen. Wichtig wäre mir noch ein RTC bzw. Zeitstempel, damit ich die Daten aus verschiedenen Quellen über eine gemeinsamem Zeit darstellen kann. Die Hardware bis zum SPI steht bereits, nur leider bin ich in Sachen FPGA ein absoluter Neuling. Ich würde mich daher Freuen wenn mir jemand ein Entwicklungsboard (Später soll das Modul ein eigenes Layout bekommen) empfehlen könnte um erste Erfahrungen zu sammeln, oder auch wenn mein Vorhaben so nicht umsetzbar ist. Danke und Gruß
Warum willst Du FPGAs nehmen? Welche Datenrate haben Deine Sensoren. Zur Ankopplung an Ethernet würd ich lieber ein fertigs Board nehmen, z.B. RaspberryPi.
Hallo Martin, das hätte ich wohl noch dazu schreiben sollen. Es sind 18bit bei 1MHz Abtastrate pro Modul also doch einiges an Daten. Ist dies mit einem RaspberryPi noch machbar? Prinzipiell bin ich auch keinem µC abgeneigt aber hatte irgendwie schon FPGA im Kopf ohne das jetzt zu begründen.
Ich sehe keinen Grund einen FPGA zu nehmen. Ich würde einen Cortex-M mit Etherenet nehmen und für das "durchschleifen" ein Ethernet-Switch-IC mit drauf packen...
Senden alle Module ohne Pause mit je 18*1Mbit/sec ? Wieviele Module sind es maximal ?
Im Messbetrieb kann das durchaus vorkommen das alle senden. Die genaue Modulanzahl habe ich mir noch nicht überlegt aber ich hoffe das es mit bis zu 10 Stück funktioniert.
Dann würd ich Auschau halten nach einem FPGA-Board, das nen Gigabit-Ethernet Interface unterstützt. Die Messmodule selbst können vermutlich relativ kleine FPGAs besitzen.
Cortex-M schau ich mir mal an :) @Martin, ok also kein interen sondern ein zweikanal Interface extra dazuhängen. Die Aufgabe des FPGA ist eigentlich "nur" die umsetzung der Daten von SPI in einen Frame plus Zeitstempel anbringen. Wie meinst Du das mit "kleinen FPGA"? Es soll ja keine Zentrale Steuerung geben sonder das Entwicklungsboard nur für den Anfang genutzt werden uns später alles ins Modul integriert werden.
Ein Pi ist bei datenintensiven Anwendungen so ziemlich das dümmste, was man nehmen kann, weil das Ethernet dort über USB läuft. Wenn, dann wäre ein BeagleBone sinniger. 18 MBit/s sind einzeln nicht besonders viel. Dafür reicht etwas in der Größenordnung MSP432 bzw Tiva TM4C129. Da sind MAC und PHY schon im Chip eingebaut. Für Timing gibts mit IEEE 1588 eine Standardlösung, die bis hinab in den µs Bereich geht. Das erfordert spezielle Hardwareunterstützung in den beteiligten Netzwerkteilnehmern. Die oben erwähnten MSP432 bzw TM4C129 haben diesen Hardwaresupport. Der zu verwendende PC braucht auf dem Interface auch den passenden Hardwaresupport und passende Treiberunterstützung. Mit dem Hintereinanderschalten der einzelnen Geräte handelst Du Dir nur Probleme ein. Jeder Tap verursacht eine Verzögerung, und jeder Tap braucht plötzlich mindenstens Gigabit Ethernet, was dann wieder den Rest der Hardware komplexer macht. Mit einem vernünftigen Switch skaliert das alles besser - da ist einzige Flaschenhals der Link zum PC, und wenn Du dort und nur dort eine 10GBit Karte einbaust und einen Switch mit ein oder zwei 10GBit-Uplinkports nimmst, dann hat sich das Thema auch erledigt, dann sind auch 100 Module kein Problem. fchk
:
Bearbeitet durch User
Moin Ernst, wenn Du das Rad nicht neu drechseln willst, hätte ich allenfalls eine Lösung für Dich. Müsste man allerdings die SPI-Seite (Master oder Slave? DMA?) abklären. Gibt dazu ein Evalkit und etwas Doku: http://section5.ch/index.php/product/netpp-node-v0-1/ Ich habe bisher nur 200kS/s ausprobiert, aber mit demselben System kommst du im Prinzip an die volle Bandbreite des Ethernet mit UDP/RTP (Real-Time-Protokoll). Modul macht 100 MBit, also kriegst du von zehn davon die Daten über einen passenden GBit-Hub weg, aber nur im einigermassen "sandboxed" UDP-Betrieb. Von RPi, Beagleboard und Konsorten kann ich in dem Kontext auch nur abraten. Die sind nur mit TCP/IP einigermassen zu brauchen, ansonsten ist die USB-Tunnelei ein echter Murks.
Super das hört sich grade schon nach einer ganz guten Basis an. Ich überarbeite grade mein Konzept noch einmal Richtung Stern aus Switch und Modulen und was mit IEEE 1588 möglich wäre. Neu drechseln möchte ich natürlich nicht. sondern möglichst schnell auf eine umsetzbare Lösung kommen. Ob es ein Spartan6 FPGA sein muss, der ist ja im Vergleich zu den anderen beiden nicht Frank vorgeschlagenen nicht ganz günstig. Die Datenmenge an sich ist eigentlich nicht so viel es ist nur wichtig, dass keine Messpunkte verloren gehen und der Chip gängige Ethernet Mechanismen wie wiederholtes senden unterstützt. Danke und Gruß
Hier ist von ein Board mit 2xETH von Intel/Altera: https://www.altera.com/products/boards_and_kits/dev-kits/altera/max-10-fpga-development-kit.html Du brauchst "nur" einen MAC (gibts bei OpenCores oder sonst was zu finden). Es ist nicht sooo trivial, besonders für einen Anfänger, Daten über Ethernet zu schicken. Du (oder Dein MAC-Core) muss sich um Konfiguration, Arp-Packete/Antworten kümmern. Aber UDP-Protokoll (damit es einfach ist), ist nicht besonders kompliziert und übersichtlich. oder Du nimmst, NIOS auf dem Board und implementierts den MAC im NIOS (Gibts auch als IP-Core und ich glaube sogar frei?) Kest
Ernst schrieb: > Die Datenmenge an sich ist eigentlich nicht so viel es ist nur wichtig, > dass keine Messpunkte verloren gehen und der Chip gängige Ethernet > Mechanismen wie wiederholtes senden unterstützt. Dann würde ich tatsächlich auch einzelne kleine Ethernet Teilnehmer mit einem soliden TCP/IP Stack einsetzen. Beim "durchschleifen" hast du sonst auch Probleme mit der Zuverlässigkeit.
Vka schrieb: > Dann würde ich tatsächlich auch einzelne kleine Ethernet Teilnehmer mit > einem soliden TCP/IP Stack einsetzen. Nur so am Rande: Das hat bisher bei mir mehr Probleme geschaffen als gelöst. Bei Echtzeitanwendungen kann man sich allzuviel Datenpuffern nicht leisten, wenn die TCP-Verbindung hängt (und das kann sie lange). Lieber setzt man eine separate Box ein, die keine UDP-Pakete wegwirft oder reordert, und daraus einen TCP-Stream irgendwohin tunnelt. Wenn die 90 kHz von RTP reichen, braucht man auch keinen 1588-fähigen MAC-Layer.
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.