Hallo an die Community! Ich bin gerade dabei die Messelektronik für den Nachbau von einen Praktikumsversuch zu entwerfen der ursprünglich per Hand ausgewertet wurde und habe sozusagen ein paar Features ergänzt. (Ich möchte das ganze zum Erfahrung sammeln zuhause nachbauen). Mein Hauptproblem beim Überschlagen der Anforderungen ist, dass ich meine Messdaten von mehreren ADCs mit einer konstanten Datenrate von rund 10 Mbit/s irgendwo abspeichern muss. Das ganze soll so ca. 10 min. durchlaufen können was Minimum zu stolzen 750 Mbyte Daten führt. Wo ich die Daten hinschaufel ist mir egal, schlussendlich muss ich die Daten auf einem PC auswerten, da zu rechenaufwendig für MCU. Die Frage ist wohin am besten/einfachsten mit den Daten? Mit entsprechendem Chip über FullSpeed USB oder Ethernet an den PC? Auf SD-Karte speichern? Für meine bisherigen Projekte war keine so hohe Datenrate notwendig, das ist für mich also Neuland. Details: *Die Daten stammen von Strom- und Spannungsmessungen sowie einem CCD-Array und einem Zeitstempel der per Mikrocontroller erzeugt werden soll *möglicher Übertragungsweg zum PC: 1-2 Meter *verwendeter Mikrocontroller: bin ich für fast alles offen, ich möchte nur die Daten von den ADCs auf einem Speicher haben *Datenformat: kann raw im Bitformat vorliegen da ich die Software zur Auswertung selbst schreibe, .txt oder .csv ist natürlich auch nicht schlecht, muss aber nicht sein *Meine Erfahrung mit MCs: Arduino-Boards ;-) Atmega und Attiny MCUs ich arbeite mich aber auch gerne in andere MCU-Familien ein, ich möchte mit diesem Projekt hauptsächlich Erfahrung sammeln, allerdings ist der Rest auch schon recht umfangreich weshalb ich bei einer einfachen Lösung auch nicht nein sage :P Ich weiß, dass es in dieser Richtung schon einige Beiträge gibt, mich interessiert aber was sich am einfachsten realisieren lässt (hab mit SD-Karten wenig Erfahrung, nur bestehenden Code an meine Bedürfnisse angepasst, mit weitaus geringeren Datenraten). Danke übrigends für die wirklich guten Tutorials und das Forum auf dieser Seite. Ich habe mich zwar gerade erst angemeldet, mich hier aber schon öfters nach Infos umgesehen :) Vielen Dank für eure Tipps! grüße, tumbleweed
Nach meiner Erfahrung - binär ohne Filesystem auf SD-Karte schreiben. Beim Auslesen über USB oder UART die Daten im Mikrocontroller in einen Text konvertieren, den man direkt im Terminalprogramm anschauen kann.
@"Noch einer" geht das von der Datenrate her aus? ich habe hier im Forum in einigen Beiträgen gelesen, dass weitaus erfahrenere Bastler als ich Probleme mit weitaus geringeren Datenraten hatten.
Ich tendiere zu Netzwerk. STM32F4 DISCOVERY Board + STM32F4 DIS BB Board und feddich :) Mit den Beispeilen von http://mikrocontroller.bplaced.net/ solltest du auch recht fix zum Ziel kommen.
@Meister Ist natürlich fast ein bisschen übertrieben nur zum datenschaufeln, aber lässt sich sicher einfach realisieren danke :)
Wie wäre es mit einem µC + Ethernet Phy & Mac (da gibts sicher schon fertige Boards)? Da sollte das doch kein Problem sein. Die Daten kannst du dann per UDP zum Rechner schicken. 10Mbit ist da doch ein Klacks.
Wieso nicht einfach ein Raspberry PI und dann via Netzwerk oder direkt auf USB-Stick. Klar ist zwar irgendwie Overkill, aber der Pi ist günstig und das Betriebssystem ist fertig. Da braucht man sich nur noch um das Auslesen und Schreiben/Senden der Daten kümmern. Ich würde zumindest nicht anfangen mir jetzt mühselig die nötigen Codeschnipsel für SD-Karte, Netzwerk etc. zusammenzusuchen und Tage damit verbringen bis auch alles miteinander vernünftig läuft.
:
Bearbeitet durch User
Danke für die Beiträge :) wie es aussieht ist die Mehrheit für eine Ethernetübertragung da bin ich nicht abgeneigt, die Frage ist was verwendet man Mikrocontrollerseitig? @ masterfx: Raspberry Pi wär überhaupt kein Problem (bzw. ideal), den kann ich dann auch direkt die Auswertung machen lassen (lässt sich ja einfach mit Python o.ä. programmieren) Die große Frage ist wie soll das Interface zwischen den Analog Digital Wandlern und dem PC bzw. Raspberry Pi aussehen. Die GPIO-Pins sind zu langsam bzw. zu unsicher da kein realtime OS. jedenfalls nach dem was ich bis jetzt gelesen hab. oder liege ich da falsch (ich lasse mich gerne eines besseren Belehren :)
@Wutzi Danke, hab unter dem Stichwort schon einiges gefunden
Thomas H. schrieb: > dass weitaus erfahrenere Bastler als ich Probleme mit > weitaus geringeren Datenraten hatten. Man kann mit allem Probleme haben, auch mit einem 5V-Netzteil. Aber jede billige Digitalkamera kann HD-Video auf SDC-Karten speichern, das ist das einzige Problem an der Sache und also offensichtlich lösbar. Ich würde im Gegensatz zu vorherigen Vorschlägen auch unbedingt anstreben, eine Karte mit Dateisystem zu verwenden, denn dann muss man nicht auch noch Spezialsoftware zur Auswertung schreiben, man steckt die Karte einfach in irgendeinen Card Reader. Ob Ethernet oder SDC, man braucht entsprechende Libraries. Aber für Ethernet braucht man auch noch eine Verbindung und einen PC. Georg
Georg schrieb: > Ich würde im Gegensatz zu vorherigen Vorschlägen auch unbedingt > anstreben, eine Karte mit Dateisystem zu verwenden, denn dann muss man > nicht auch noch Spezialsoftware zur Auswertung schreiben, man steckt die > Karte einfach in irgendeinen Card Reader Und auch nur so wird die Karte innerhalb ihrer Spezifikation betrieben, und nur so funktionieren die internen Algorithmen zum Wear Leveling, und nur so ist die Performance garantiert. 10 Mbit/Sec ist allerdings recht sportlich. Mit nem AVR, SPI und Copy & Paste von FAT32 Code ist's da nicht getan. Da würde ich eher zu zB einem STM32F4 und der Verwendung von SDIO und DMA raten, und einem schlauen Algorithmus der große Blöcke auf einmal schreibt. Das dauert aber länger als ein paar Tage... da ist R-PI oder Ethernet doch wesentlich einfacher.
Thomas H. schrieb: > Die große Frage ist wie soll das Interface zwischen den Analog Digital > Wandlern und dem PC Was hast du da denn für ein Interface an den ICs (SPI? Parallel? I2C)? Und wie viele Wandler sind es? Der SPI von Raspberry kann bis zu 125 MHz glaub ich, sowie Interrupt und DMA.
@Georg @Programmierer: Dass es lösbar ist steht ausser Frage :P für mich stellt sich die Frage: ist es für mich lösbar, aber das muss natürlich ich selbst ausprobieren. Danke übrigends für den Rat ein Dateisystem zu verwenden, habe mich noch nicht in die Spezifikationen von SD-Karten eingelesen. Ich bin für jeden Tipp Dankbar :) Dann werde ich einmal den Rat annehmen Ethernet oder den RPi zu verwenden. Dazu bitte nochmals die Frage: Weiß jemand ob es möglich ist eine Datenrate von 10 Mbit/s über die GPIO-Pins (sei es parallel, über UART oder SPI) zu erreichen? Meine bisherige Recherche hat mich eher davon abgebracht. vielen Dank allen :)
SPI ist kein Problem. Über GPIO gewackel sind max. 22 Mhz (Native library) bzw. ~4 MHz via wiringPi drin, siehe http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ (Natürlich unter Optimalbedingungen wenn er nichts anderes zu tun hat)
:
Bearbeitet durch User
Timmo H. schrieb: > (Natürlich unter Optimalbedingungen wenn er nichts anderes zu tun hat) Das ist kein Problem, da ich sowieso geplant habe die Datenauswertung im Nachhinein zu machen. Danke für den Link! wie es aussieht muss ich meine fast nicht vorhandenen C-Kenntnisse auffrischen ;-) Wobei dort auf den ersten Blick nur das togglen von pins getestet wird, aber ich schaus mir noch genauer an.
Das Ganze funktioniert nur mit High-Speed USB (FX2 z.B.). Auf PC-Seite implementierst Du eine virtuelle Datei (bis 2 GByte bei WIN32) und schreibst dann da rein. Es empfiehlt sich mit mehreren Worker-Threads zu arbeiten: Einer liest von Deinem FX2, der nächste fängt schon mal an zu analysieren und ein weiterer zeigt die Daten an. Es geht natürlich auch mit einem Thread, der die Aufgaben nacheinander abarbeitet. Aber das dauert dann auch entsprechend. Gruß Peter
Peter schrieb: > Auf PC-Seite implementierst Du eine virtuelle Datei (bis 2 GByte bei > WIN32) und schreibst dann da rein. Aha so läuft das, hab mich schon gewundert. Wobei ich langsam dazu tendiere die RPi-Lösung zu wählen, dann hätte ich ein komplettes System für die Datenauswertung, schön handlich. hab gerade gesehen, dass der RPi bis 32 Mhz unterstützt: http://elinux.org/RPi_SPI das sollte eigentlich reichen :)
Kommen die Daten eigentlich kontinuierlich? Macht es etwas, falls mal ein paar 100 kBytes zwischendurch verloren gehen?
Wieviele ADCs sind es denn? Falls du Probleme mit der Gleichzeitigkeit von Auslesen der ADCs und Weiterleiten der Daten bekommst,könntest du ja auch die ADCs auf mehrere Raspis verteilen und erstmal nur ins RAM schreiben und dann übertragen oder speichern. Oder gleich einen ähnlichen Kleinrechner mit mehr RAM verwenden, zB einen Banana pi mit 1GB oder Odroid mit 2GB.
Peter schrieb: > Macht es etwas, falls mal ein paar 100 kBytes zwischendurch verloren > gehen? Es ist kein Problem wenn ein paar kByte hops gehen aber ein paar 100 leider nicht. Ich muss die verloren gegangenen Bytes auch nicht nachsenden. Wichtig wäre nur dass ich dahinter komme welche Daten weg sind um das in der Auswertung zu berücksichtigen. (das könnte ich aber vielleicht über den Takt rekonstruieren wenn ich genau weiß wie lang mein Code braucht. Ich plane keine Interrupts zu verwenden)
Jobst Q. schrieb: > Falls du Probleme mit der Gleichzeitigkeit von Auslesen der ADCs und > Weiterleiten der Daten bekommst,könntest du ja auch die ADCs auf mehrere > Raspis verteilen und erstmal nur ins RAM schreiben und dann übertragen > oder speichern. Ja, da bin ich auch gerade beim Überlegen. Ich verwende 4 ADCs, einer wertet den CCD-Array von 2048 Pixel Länge und 8 bis 12 Bit Auflösung aus. Das bedeutet diese Daten kommen in einem Bulk daher mit Pausen bei der Belichtung. 2 ADCs messen Spannungen (voraussichtlich 10 Bit mit vermutlich 500 SPS). 1 ADC misst auch Spannungen mit rund 500 kSPS allerdings kommt da ein MCU dazwischen welcher die Daten vorauswertet. Da kommen voraussichtlich 16 bis 32 byte 500 mal pro sec daher. Ja ich weiß ;) nicht so übersichtlich wie ich es gerne hätte, aber das sind die Anforderungen. Ich dachte mir ich könnte die Daten irgendwo dazwischen buffern. Ich wollte nur erst wissen ob ich die notwendigen 10 Mbit/s überhaupt wegschaffen kann. Wie viel Elektronik ich verbaue ist platztechnisch komplett egal (kann auch ein komplettes Mainboard sein ;) es sollte sich nur für einen Hobbybastler im erträglichen Preisrahmen bewegen.
Jobst Q. schrieb: > und erstmal nur ins RAM schreiben und dann übertragen Glaube nicht dass das geht, ich vermute dass das Betriebssystem auch gerne seine Scheibe vom RAM hätte und ich will 10MBit/s über 10 Minuten übertragen, das wird eng. Aber ich weiß auch nicht ob mir als Buffer für den SPI-Modus des RPi der ganze RAM zur Verfügung steht (glaub ich nämlich nicht, aber da muss ich erst nachschauen). Ich vermute, dass ich lange vorher die Daten irgendwo ablegen und inzwischen MCU-seitig buffern muss.
Thomas H. schrieb: > und inzwischen MCU-seitig > buffern muss. Das hilft dir nicht, höchstens um eine ungleichmässige Geschwindigkeit auszugleichen - aber über alles gesehen hast du eine Pipeline, in die du lange Zeit 10Mbit/s reinstopfst, und das geht nur gut, wenn durch alle Stufen die gleiche Datenrate bis zur endgültigen Speicherung durchgehalten wird. Wie schon Kohl sagt, wichtig ist was hinten rauskommt - buffern nützt da nichts bzw. nur sehr kurzfristig. Eher im Gegenteil, man muss das ganze System so schlank wie möglich ausführen, damit alles mit optimaler Geschwindigkeit durchläuft. Buffern = speichern und später wieder lesen kostet auch Zeit. Wenn du mehrere Zwischenpuffer einrichtest geht am Ende garnichts mehr. Georg
@ Thomas H. (tumbleweed) >Ich verwende 4 ADCs, einer wertet den CCD-Array von 2048 Pixel Länge und >8 bis 12 Bit Auflösung aus. Das bedeutet diese Daten kommen in einem >Bulk daher mit Pausen bei der Belichtung. >2 ADCs messen Spannungen (voraussichtlich 10 Bit mit vermutlich 500 >SPS). Das ist schon alles ziemlich sportlich. Die Anteuerung geht nur, wenn sie Bare metal ohne Betriebssystem erfolgt, alles andere darfst du getrost vergessen. >sind die Anforderungen. Ich dachte mir ich könnte die Daten irgendwo >dazwischen buffern. Kann und muss man, die Frage ist nur, wie groß der FIFO sein muss. Wieviel Zeit muss er maximal überbrücken? > Ich wollte nur erst wissen ob ich die notwendigen 10 >Mbit/s überhaupt wegschaffen kann. Das ist 1 MB/s, das ist nicht sooooo viel. >Wie viel Elektronik ich verbaue ist platztechnisch komplett egal (kann >auch ein komplettes Mainboard sein ;) es sollte sich nur für einen >Hobbybastler im erträglichen Preisrahmen bewegen. Ich würde einen aktuellen 32Bit ARM nehmen, der darf ruhig 100-200MHz CPU Takt und eine SD-Karte haben. Damit kriegt man 1MB/s locker weg, denn diese CPUs haben ein natives SDIO, das ist so schnell wie die SD-Karte es zuläßt (selbst die billigsten Karten schaffen heute 4MB/s). Damit kann man die harte, zeitkritische ADC-Auswertung sehr hardwarenah gestalten, das schafft man. Über High Speed USB (480 Mbit/s) kriegt man 10Mbit/s auch gut weg, da gibt es auch diverse Controller bzw. Evalboards. Aber Vorsicht, hier können dir ggf. die Interrupts des USB-Controlles dein Timing zerschießen!
Thomas H. schrieb: > Mein Hauptproblem beim Überschlagen der Anforderungen ist, dass ich > meine Messdaten von mehreren ADCs mit einer konstanten Datenrate von > rund 10 Mbit/s irgendwo abspeichern muss. Das ganze soll so ca. 10 min. > durchlaufen können was Minimum zu stolzen 750 Mbyte Daten führt. Wo ich > die Daten hinschaufel ist mir egal, schlussendlich muss ich die Daten > auf einem PC auswerten, da zu rechenaufwendig für MCU. Tja, da dürfte die primäre Frage sein, wie der/die µC an den PC angebunden sind. Sind sie nicht? Dann solltest du das unmittelbar ändern und zwar auf Ethernet. Weil: dann löst sich das Problem sofort, denn kein moderner PC hat ein Problem damit, derart lächerliche Datenmengen vie Ethernet entgegenzunehmen und in eine vollwertige Datenbank wegzuspeichern. Wenn ein µC die benötigte Datenrate nicht schafft: Nimmst du einfach mehrere (sie kosten ja fast nix mehr). Alle können so einfach direkt in die Datenbank schreiben, die als Datenbasis für die Auswertung dienen soll. Trivial.
Thomas H. schrieb: > Hallo an die Community! > > Ich bin gerade dabei die Messelektronik für den Nachbau von einen > Praktikumsversuch zu entwerfen der ursprünglich per Hand ausgewertet > wurde und habe sozusagen ein paar Features ergänzt. (Ich möchte das > ganze zum Erfahrung sammeln zuhause nachbauen). > > Mein Hauptproblem beim Überschlagen der Anforderungen ist, dass ich > meine Messdaten von mehreren ADCs mit einer konstanten Datenrate von > rund 10 Mbit/s irgendwo abspeichern muss. Das ganze soll so ca. 10 min. > durchlaufen können was Minimum zu stolzen 750 Mbyte Daten führt. Wo ich > die Daten hinschaufel ist mir egal, schlussendlich muss ich die Daten > auf einem PC auswerten, da zu rechenaufwendig für MCU. Dann liegt es ja am nächsten, die Daten direkt mit einem PC einzusammeln. Schau mal, ob so etwas Dein Problem löst: http://www.bluechiptechnology.co.uk/Product/PCIADC-Data-Aquisition-Card So etwas in der Art gibts bis in den Gigasample-Bereich, aber dann wirds echt teuer. fchk
Georg schrieb: > Wie schon Kohl sagt, wichtig ist was hinten > rauskommt - buffern nützt da nichts bzw. nur sehr kurzfristig. Ein Puffer mit z.B. 1GByte nützt ganz vorzüglich. Da während der Messung insgesamt "nur" 750MByte anfallen, hätte die Mimik danach alle Zeit der Welt, um die Daten auf SD rauszuschreiben, Auszuwerten und übers Netzwerk in die Cloud (oder sonstwohin) zu schicken.
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.