Hallo ihr, ich bin noch recht neu im Bereich der Microcontroller und stehe gerade vor einem Problem und hoffe auf eure Erfahrung. Ziel ist die Zeitlich Synchronisierte Datenerfassung mehrerer Sensoren mit verschiedenen Frequenzen an einem STM32. Ich möchte Daten aus z.B. einem Beschleunigungssensor und ADC aufnehmen und auf einer SD-Karte speichern. Jeder Sensor kriegt seine eigene Datei in der die Samples in ihren eigenen Abtastfrequenzen gespeichert werden. Bsp.: ADC hat eine Frequenz von 1kHz --> nach 1 Sekunde sind in seiner Datei 1000 Samples. Gleichzeitig hat der Beschleunigungssensor eine Frequenz von 100Hz --> in seiner Datei sind nach einer Sekunde exakt 100 Werte. Nun sollen die Werte exakt zueinander passen, damit auch nach längerer Zeit die Anzahl der Werte in den jeweiligen Dateien zueinander passen. Meine Idee war es nun mehrere Timer die sich alle auf die gleiche Clock Source beziehen, zu benutzen. Diese sollen jeweils Interrupts auslösen um die Daten abzuspeichern. Nun bin ich mir aber nicht sicher ob das so der richtige Weg ist. Wie würdet ihr das Problem lösen? Bin dankbar für Tipps oder auch Material wo ich mich einlesen kann Grüße Stephan
Stephan W. schrieb: > Wie würdet ihr das Problem lösen? Timestamps mitspeichern. Je nach Ausstattung kann so ein STM32 drei ADC gleichzeitig triggern.
:
Bearbeitet durch User
Das Problem wird eher sein, die Zeitstempel miteinander abzugleichen. Du könntest z.B. den DSW cycle Counter benutzen, was aber heissen wird, dass die Zeitstempel für zwei samples zweier ADC, die zur "selben Zeit" gezogen werden, voneinander abweichen. Vermutlich solltest Du einen interruptgesteuerten Timer mit höchster Priorität laufen lassen, der mit der kleinsten Auflösung, die Du brauchst, einen Zähler hochzählt, und jedes Sample schreibt diesen Zähler als Zeitstempel mit. Warum der Timer die höchste Priorität haben muss, ist die Denksportaufgabe für die Erstsemester ;-) Allerdings hat diese Strategie den Nachteil, dass der Timer mit jedem Reset bei 0 anfängt, d.h. wenn der Controller resettet, sind deine Zeitstempel nicht mehr eindeutig zuzuordnen. Mögliche Abhilfen: 1. uC mit RTC nehmen und die Timerzeitstempel relativ mit dem RTC Stand abspeichern. (Die RTC hat natürlich in der Regel keine Granularität, die für das Stampen allein reicht). Wenn dein System allerdings keine Möglichkeit der absoluten Uhrzeitsynchronisation hat, lässt sich die RTC im Feld natürlich nicht stellen... 2. Den Zähler im nichtflüchtigen Speicher ablegen und mit einer Signatur sichern. Allerdings kann es in beiden Fällen vorkommen, dass dein System komplett stromlos wird, dann ist alles weg. In dem Fall könntest Du so Dinge machen wie ein GPS mit drauf setzen (natürlich nur wenn deine Geräte GPS Empfang haben können, also draussen eingesetzt werden) und beim Systemstart den Zeitstempel mit der absoluten GPS Zeit initialiseren. Heisst aber, dass alle Samples, die während des Satellitenfixes anfallen, mglw. keinen gültigen Zeitstempel haben. Trivial ist die Sache in jedem Fall nicht, zwar nicht riesig kompliziert, aber mit ein paar Fallstricken ausgerüstet. Ich hoffe, deine Frage richtig verstanden und damit einigermassen sinnvoll beantwortet zu haben.
Vielen Dank für die schnellen Antworten! Matthias S. schrieb: > Timestamps mitspeichern. Je nach Ausstattung kann so ein STM32 drei ADC > gleichzeitig triggern. leider ist mir das Format zum abspeichern vorgegeben. Ich darf nur die Samples selber abspeichern. Die Zeit wird dann beim auswerten über die Anzahl der Samples bestimmt. RAc schrieb: > Vermutlich solltest Du einen interruptgesteuerten Timer mit höchster > Priorität laufen lassen, der mit der kleinsten Auflösung, die Du > brauchst, einen Zähler hochzählt, und jedes Sample schreibt diesen > Zähler als Zeitstempel mit. Warum der Timer die höchste Priorität haben > muss, ist die Denksportaufgabe für die Erstsemester ;-) okay, damit kann ich jedem Sample das ich reinbekomme einen Zeitstempel geben. Aber wie stell ich damit sicher das die Sensor Daten auch in einer bestimmten Frequenz erfasst werden? Ist das so gemeint, das immer wenn der Timer ein Interrupt ausgibt Daten gespeichert werden sollen? RAc schrieb: > Allerdings kann es in beiden Fällen vorkommen, dass dein System komplett > stromlos wird das ganze wird Batteriebetrieben sein und immer Zeit begrenzt benutzt, daher sollte das nicht passieren.
Stephan W. schrieb: > > okay, damit kann ich jedem Sample das ich reinbekomme einen Zeitstempel > geben. Aber wie stell ich damit sicher das die Sensor Daten auch in > einer bestimmten Frequenz erfasst werden? Ist das so gemeint, das immer > wenn der Timer ein Interrupt ausgibt Daten gespeichert werden sollen? > Nein, dieser Mechanismus würde nur sicher stellen, dass zwei ADC Auswertungsroutinen (wo und wie auch immer die gemacht werden) den SELBEN Zeitstempel kriegen. Natürlich kannst Du auch den Timer dazu benutzen, die samples selber zu nehmen, also z.B. für den einen ADC mit jedem Tick ein sample zu ziehen und für den Anderen alle 100 ticks einmal. Ob das eine gute Architektur ist oder nicht, lässt sich nur im Einzelfall beurteilen, wenn man näher in der Aufgabenstellung drin ist. Es wäre auch denkbar, für jeden ADC einen eigenen Timer aufzuziehen oder aber in der main Loop die ADCs sequentiell abzuarbeiten. Die richtige Entscheidung zu treffen hängt stark davon ab, was das System noch alles tun muss neben der Erfassung (also z.B. Aufbereitung oder Mittlung von Daten oder der Kommunikation der Daten an einen host oder oder oder). Natürlich ist es auch wichtig zu wissen, ob Du z.B. ein RTOS benutzt oder nicht. Aber letztendlich musst Du solche Entscheidungen halt selber unter Berücksichtigung der Gesamtarchitektur und Rahmenbedingungen treffen.
Stephan W. schrieb: > Bsp.: ADC hat eine Frequenz von 1kHz --> nach 1 Sekunde sind in seiner > Datei 1000 Samples. > Gleichzeitig hat der Beschleunigungssensor eine Frequenz von 100Hz --> > in seiner Datei sind nach einer Sekunde exakt 100 Werte. > Nun sollen die Werte exakt zueinander passen, damit auch nach längerer > Zeit die Anzahl der Werte in den jeweiligen Dateien zueinander passen. Wenn du gleichzeitig anfängst, Werte vom einen Sensor in die eine Datei und Werte von anderen in andere Datei zu speichern, ergibt sich bei den o.g. Abtastfrequenzen automatisch, dass auf 10 Werte in der einen Datei immer ein Wert in der anderen kommt. Wo ist jetzt das Problem?
Stephan W. schrieb: > Ich möchte Daten aus z.B. einem Beschleunigungssensor und ADC aufnehmen > und auf einer SD-Karte speichern. Jeder Sensor kriegt seine eigene Datei > in der die Samples in ihren eigenen Abtastfrequenzen gespeichert werden. > Bsp.: ADC hat eine Frequenz von 1kHz --> nach 1 Sekunde sind in seiner > Datei 1000 Samples. Hallo Stephan, eine Seitenbetrachtung: Nehmen wir mal "nur" den schnelleren Sensor. Bei 1000 Samples pro Sekunde fallen nach meiner Rechnung pro Tag 3600 (Sekunden pro Stunde) * 1000 (Samples pr Sekunde) * 24 (Stunden pro Tag) * x (Datensatzgrösse) Bytes an, den Overhead des Dateisystems mal nicht mitgerechnet. Das sind lt. meinem Taschenrechner 659 Megabytes Datenvolumen pro Tag (ausgehend von x = 8). Nimm nochmal 10% dazu (für den langsamen Sensor, gleiche Berechnung), dann hast Du 725 MB pro Tag. Eine 64 GB SD Karte ist dann spätestens nach 85 Tagen voll (vermutlich wesentlich weniger, weil ein Dateisystem einen signifikanten overhead nach sich zieht). Du schreibst nicht, was mit den gespeicherten Daten passieren soll. In aller Regel ist die SD Karte nur ein Zwischenspeicher, aus dem die Daten periodisch umgeschaufelt werden, z.B. über ein Hostinterface an einen Konzentrator, der die dann entweder auf einen grösseren Massenspeicher umlädt oder/und aufbereitet. Wenn das so ist, hast Du etliche Flaschenhälse in der Archtitektur, z.B. wirst Du es mit Sicherheit nicht schaffen, einen Datensatz innerhalb einer uS auf die SD Karte zu schreiben. Du musst also eine Anzahl von Datensätzen zwischen puffern und dann im bulk auf die SD Karte schreiben. Umgekehrt ist es abhängig vom Hostinterface (Medium, Zuverlässigkeit, Onlinestatus etc pp), wie schnell Du die Daten von der SD Karte wieder weggeschaufelt kriegst. Dabei gibt es eine Menge Szenarien, die dafür sorgen können, dass ein gegebener Datensatz nicht mehr rechtzeitig vom Sensor auf die SD Karte kommt (voller Puffer, volle SD Karte etc pp). Sollte aber die SD Karte der "finale Speicher" der Sensordaten werden, brauchst Du natürlich eine Architektur, die eine volle SD Karte so zeitgemäss hochmeldet, dass sie rechtzeitig ausgewechselt werden kann. Während der Wechselzeit is dann natürlich die Funktionalität ausser Betrieb. Je nach Aufgabenstellung und Zuverlässigkeitsanforderungen KANN es sein, dass die angedachte Architektur eine Einbahnstrasse ist. Es kann sinnvoller sein, in deinem Embedded System die Daten vorzuverarbeiten (also z.B. zu mitteln und damit das Datenvolumen zu reduzieren) und zu versuchen, die Daten ohne SD Karte in so Echtzeit wie möglich direkt an einen Host zu schaufeln, der mit grösseren Volumina besser zurecht kommt. Ein Problem mit SD Karten besteht auch darin, dass sie nur eine begrenzte Anzahl von Schreibzyklen haben, d.h. wenn dein System 24h am Tag Daten sammelt und die SD Karte als Ringpuffer dient, wird sie (abhängig von ihrer Grösse und dem Datendurchsatz) früher oder später den Geist aufgeben. Das sind nur ein paar teaser, um Dich auf die wunderbare Welt der Mikrocontroller und ihre spannenden Herausforderungen vorzubereiten (Du schreibst ja, dass Du neu in der Technologie bist) ;-).
Vielen Dank für die vielen ausführlichen Antworten :) Das hätte ich echt nicht erwartet.. RAc schrieb: > Es wäre auch denkbar, für jeden ADC einen eigenen Timer aufzuziehen besteht hier dann die Gefahr das die Timer auseinander laufen? Oder laufen die synchron wenn sie sich auf den selben Takt beziehen? Wolfgang schrieb: > Wenn du gleichzeitig anfängst, Werte vom einen Sensor in die eine Datei > und Werte von anderen in andere Datei zu speichern, ergibt sich bei den > o.g. Abtastfrequenzen automatisch, dass auf 10 Werte in der einen Datei > immer ein Wert in der anderen kommt. Wo ist jetzt das Problem? Probleme hab ich einmal darin gesehen, das die Timer evtl. auseinander laufen. Zum anderen muss ich auch schauen, das die Sensoren, die auch z.B. über SPI laufen im richtigen Takt Werte ausgeben, damit die Sensoren nicht entweder viel zu oft abgefragt werden und ich unnötig Leistung verbrauche oder zu selten und die Daten damit nicht oft genug geupdatet werden. Für mich stellt sich dabei die Frage ob ich durch den Timer nur Signale zum abspeichern, oder auch Befehle zum auslesen der Daten gebe. Zusätzlich habe ich ja auch noch die Möglichkeit mit dem Timer ein Takt Signale für externe Bauteile auszugeben oder diese auf ihrer eigenen Frequenz laufen zu lassen. Ruediger A. schrieb: > eine Seitenbetrachtung: vielen Dank für die extra Gedanken :) Speicherprobleme werde ich wohl keine haben. Das System wird nur maximal eine Woche laufen. Innerhalb dieser Woche ist die SD-Card tatsächlich der "finale Speicher". Dann werden die Daten runterkopiert und gelöscht und das ganze geht von vorne los. Ich werde mich wenn es von euch keine großen Gegenargumente gibt erstmal dafür entscheiden mit mehreren Timern die Daten abzuspeichern und das auslesen der Daten vorerst kontinuierlich in der Main Schleife zu behandeln. Allerdings weiß ich nicht ob das gerade auch aus Leistungstechnischer Sicht so schlau ist, weil der Controller dann ja durchgängig arbeiten muss. Trotzdem sollte es ja fürs erste funktionieren.
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.