Hallo Leute! Ich werde bald in einem Projekt mit dem NUCLEO-F767ZI Messgrößen aufnehmen und diese speichern müssen. Darunter werden ein paar ADC-Werte, aber auch Drehzahlen (durch Encoder ermittelt) als float-Werte sein. Die Abtastfrequenz sollte so um die 100 kSamples/s liegen, sodass sich die gesamte Datenrate auf grob 3...4 MByte/s belaufen wird. Ich hatte mir gedacht, dass ich diese Daten entweder über Ethernet live an einen PC schicke oder auf eine SD-Karte schreibe, die dann nachher an einen PC angeschlossen wird um die Daten rüber zu kopieren. Mit diesen Interfaces und so hohen Datenraten habe ich bisher nicht gearbeitet und ich lese im Handbuch der MCU (und auch in anderen Mikrocontroller-Foren) ständig etwas über Buffering. Soweit ich das verstanden habe ist das Buffering nötig, weil z.B. die ADCs die abgetasteten Werte nicht direkt an das Ethernet- oder SD-Interface weitergeben können, sondern die Werte erstmal in den RAM schmeißen müssen. Von da aus werden sich die Daten-Interfaces dann die Werte zur Übertragung holen. Die vorhin genannten RAM-Bereiche sind dann wahrscheinlich der Buffer, oder? Korrigiert mich bitte falls ich falsch liege. Meine Frage wäre außerdem: Reicht der RAM des F767ZI für das Vorhaben aus? Oder muss man bei Vorhaben mit größeren Datenraten noch externen RAM dazuholen (man kann ja externe SRAM-Module kaufen, die über Interfaces an MCUs angeschlossen werden können)? Könntet ihr mich da mal etwas erleuchten? Viele Grüße!
Hey, also 100kSamples/s ist ja nicht grad wenig, aber könntest du das vllt. genauer erläutern, wieviele "Kanäle" (Werte) möchtest du erfassen? Wenn ich das mal grob umrechne: 100 kSamples = 3 MB (3072 KB) -> 3072 KB / 100.000 = 30,72 Byte je Sample Das würde ja bedeuten du samplest ca. 8x 32-Bit Werte oder 16x 16-Bit Werte? Das mit dem Buffering sieht du richtig. Da du nie genau weißt, wie schnell die Daten per Ethernet oder USB rauß gehen oder wie lange die SD benötigt (diese kann eh nur mit ganzen Pages '512 Byte' beschrieben werden). Somit ergibt sich folgender Aufbau: ----- --------------- ---> Ethernet | ADC | -> | Sample-Buffer | ---> USB ----- --------------- ---> SD Der Buffer wäre z.B. ein FIFO, die größe müsste mindestens so groß sein, wie der langsamste "Abnehmer" benötigt um ein Paket an Daten abzuholen. Möchtest du nun mehrere Abnehmer mit Daten füttern, z.B. per USB versenden und auf SD speichern, dann müsstest du dazwischen noch eine weitere Logik hängen. Da USB sich ja nicht Daten aus dem Buffer holen kann und diese dann für die SD nicht mehr verfügbar wären (bei einem normalem FIFO). Für USB müsstest du die High-Speed Einstellung wählen, da Full-Speed nur 12Mbit hat und somit hättest du nur ein Datentransfer von max. ca. 1MB/sec. Bei der SD müsstest du mal testen bei welcher Blockgröße diese am schnellsten arbeitet. Sprich: schreibst du immer nur 1 Page, oder sammelst du lieber soviele Daten, dass du 8 Pages voll bekommst und schreibst diese mit einem Befehl. Das sollte aber zeitlich machbar sein. Zum Vergleich: Ich habe ein 120Mhz µC der mit 64Mhz läuft und ich sample mit 1kHz, USB Übertragung und SD-Speicherung...gefühlt wäre bei mir bei 4kHz echt die obere Grenze erreicht, wo alles noch irgendwie zeitlich hinhaut. Deshalb find ich die 100k erstmal sehr optimistisch ;)
Adam P. schrieb: > Das mit dem Buffering sieht du richtig. Da du nie genau weißt, wie > schnell die Daten per Ethernet oder USB rauß gehen Das ist doch Quark. In seinem Anwenungsfall ist UDP am sinnvollsten, damit weiß er genau, wie schnell die Daten rausgehen. Allgemein sind die 30MBit/s für einen M4 kein Problem. Da sollte der F7 erst recht keine Probleme bekommen. Nimm am besten einen Stack wie lwip oder gleich ein RTOS wie ChibiOS, dann kannst Du Dich auf die eigentliche Anwendung konzentrieren. Und ja, das RAM reicht locker aus.
Antitroller schrieb: > Das ist doch Quark. Mag ja das UDP betreffen. Jedoch hat er auch USB und SD angesprochen. Da UDP auch ein gewissen Overhead hat, macht es dort vllt. auch nicht viel Sinn, jede 32Byte einzeln zu versenden, wenn ein Paket viel mehr aufnehmen könnte - je nach dem wie er es aufbauen möchte - müsste er einige Werte ebenfalls zwischenspeichern.
Adam P. schrieb: > Mag ja das UDP betreffen. > > Jedoch hat er auch USB und SD angesprochen. > Da UDP auch ein gewissen Overhead hat, macht es dort vllt. auch nicht > viel Sinn, jede 32Byte einzeln zu versenden, wenn ein Paket viel mehr > aufnehmen könnte - je nach dem wie er es aufbauen möchte - müsste er > einige Werte ebenfalls zwischenspeichern. Nein, von USB hast nur DU gesprochen ;) Allerdings stimme ich Dir zu, dass es Unsinn ist, einzelne Werte zu übertragen. Die sollte er natürlich bündeln.
Adam P. schrieb: > Bei der SD müsstest du mal testen bei welcher Blockgröße diese am > schnellsten arbeitet. Hier brachte Schreiben mit 16KByte Blöcken deutliche Steigerungen. Allerdings sollte man die Spec beachten, die IIRC 500ms Pausen beim Schreiben erlaubt. Das sind bei Dir mal eben 2, besser 4 MByte Puffer - da würde man externen RAM für brauchen. Das braucht aber reichlich Pins am µC. Adam P. schrieb: > Für USB müsstest du die High-Speed Einstellung wählen, da Full-Speed nur > 12Mbit hat Ich sehe auf dem Nucleo nur Full Speed Support. Für High Speed bräuchte man einen externen Phy Chip - den sehe ich nicht.
Jim M. schrieb: > Ich sehe auf dem Nucleo nur Full Speed Support. Für High Speed bräuchte > man einen externen Phy Chip - den sehe ich nicht. Ja, ich hatte mir lediglich das Datenblatt des µC angeschaut und bin davon ausgegangen, dass es dann auch so verfügbar sei (ohne zusätzlicher PHY).
Jim M. schrieb: > > Hier brachte Schreiben mit 16KByte Blöcken deutliche Steigerungen. > Allerdings sollte man die Spec beachten, die IIRC 500ms Pausen beim > Schreiben erlaubt. > > Das sind bei Dir mal eben 2, besser 4 MByte Puffer - da würde man > externen RAM für brauchen. Das braucht aber reichlich Pins am µC. Mit DDR-Quad-Spi PSRAM hält sich die Pin-Anzahl sehr in Grenzen. Der F767 kann Quad-SPI (sogar Double).
in ein UDP paket passen 1460 Bytes ein float hat 4 bytes -> 365 werte - header ... (? ) aber sicher um >300werte pro UDP Protokoll Overhead vom RTP protokoll hält sich in grenzen ...
235456456455623563235235635 schrieb: > in ein UDP paket passen 1460 Bytes Wie kommst Du denn auf das schmale Brett? Lies mal eine Einführung in Netzwerktechnik.
Wenn man mehrere MBytes an RAM hat, kann man die gewünschte Geschwindigkeit beim Schreiben auf eine SD-karte erreichen. Ich habe das mal implementiert, es ist recht kompliziert, bei Interesse könnte man über eine Lizensierung reden :)
Also allgemein: Ich habe so ca. 9 Messgrößen. Wie gesagt sind einige davon ADC Samples (12 bit ADC) und andere Daten kommen von Encodern. Wenn ich aus den Encoder-Signalen direkt die Drehzahl berechne, läge das Ergebnis als float vor. Um die Datenmenge zu begrenzen habe ich aber auch schon dran gedacht, einfach nur die rohen Counter-Werte der Encoder-Timer als Integer zu nehmen und das ganze Umrechnen dann nachher auf dem PC zu machen, wenn ich die Daten sicher übertragen habe. Wie ich euren Beiträgen entnehme, wäre eine SD-Karte keine so gute Wahl, oder? Jedenfalls nicht solange ich genug RAM habe um mind. 500 ms lang alle Werte zu buffern falls die Karte zwischenzeitlich Schreibzyklen ablehnt. Wie sähe es denn mit Ethernet aus? Auf dem NUCLEO-Board selbst ist bereits eine RJ45-Buchse angeschlossen, allerdings nur als RMII. Nach einem Blick aufs Datenblatt habe ich gesehen, dass das Board auch Pins für ein MII bietet, das einen 4 bit breiten Datenbus bietet. Ich werde eh eine Platine für dieses Projekt entwerfen, da kann ich das Ethernet-Interface dann auch direkt manuell einbinden und routen. Könnte mir jemand erklären was genau es mit RMII und MII auf sich hat? Oder eine gute Erklärung/Dokumentation verlinken? UART oder sonstigen USB-Transfer habe ich von vornherein ausgeschlossen, da ich mir schon dachte, dass die Datenrate da zu niedrig ist.
Armin L. schrieb: > Wie ich euren Beiträgen entnehme, wäre eine SD-Karte keine so gute Wahl, > oder? Jedenfalls nicht solange ich genug RAM habe um mind. 500 ms lang > alle Werte zu buffern falls die Karte zwischenzeitlich Schreibzyklen > ablehnt. Alleine das dauernde Raus- und Reinstecken der Karte würde mich stören. Die Auswertung machst Du doch eh am PC, daher ist Ethernet sicherlich am praktischsten. > Wie sähe es denn mit Ethernet aus? Auf dem NUCLEO-Board selbst ist > bereits eine RJ45-Buchse angeschlossen, allerdings nur als RMII. Nach > einem Blick aufs Datenblatt habe ich gesehen, dass das Board auch Pins > für ein MII bietet, das einen 4 bit breiten Datenbus bietet. Ich werde > eh eine Platine für dieses Projekt entwerfen, da kann ich das > Ethernet-Interface dann auch direkt manuell einbinden und routen. > Könnte mir jemand erklären was genau es mit RMII und MII auf sich hat? > Oder eine gute Erklärung/Dokumentation verlinken? Beitrag "MII/RMII mit STM32F4"
Erstmal vielen Dank an alle! ;) Kennt ihr vielleicht Referenz-Designs bzw. Layouts der Ethernet-PHY in MII-Ausführung? Also das Netzwerk zwischen MCU-Pins und RJ45-Buchse? Im oben verlinkten Thread wurde das nur für RMII diskutiert und auch der vorgeschlagene Chip von TI ist für mich ziemlich unvorteilhaft, weil er die Lötkontakte unter dem Chip hat. D.h. mit meinem Löt-Latein wäre ich da am Ende. :/
Antitroller schrieb: > Wie kommst Du denn auf das schmale Brett? > > Lies mal eine Einführung in Netzwerktechnik. ja 16bit + header sind 65xxx bytes aber das wird eh fragmentiert Ich meinte was an payload in ein single UDP frame passt mit alles optionalen headern ist das sogar nur 1440 bytes wenn man natürlich alles aufbohrt ikl jumboframes ... aber das ist leider weit weg von kompatiblität Ich habe bisher immer RMII PHY genutzt. Mikrel KSZxxx oder SMSC LAN8720 MII sollte nicht dramatisch besser sein. Mikrel hat die 49Ohm terminierung im chip und ist auch sonst recht sparsam mit der externen beschaltung. und der RMII läuft mit 25Mhz takt
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.