mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 Datensynchronisation von Sensoren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Stephan W. (stephan29)
Datum:

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

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: RAc (Gast)
Datum:

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

Autor: Stephan W. (stephan29)
Datum:

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

Autor: RAc (Gast)
Datum:

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

Autor: Wolfgang (Gast)
Datum:

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

Autor: Ruediger A. (Firma: keine) (rac)
Datum:

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

Autor: Stephan W. (stephan29)
Datum:

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

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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.