Realisierung eines persistenten Pre-Triggers

[Werner B. (Firma: Brösel) (werner2014)]

Hallo,

mich würde mal interessieren, was es für Möglichkeiten gibt, um eine 
Messdatenerfassung mit Pre-Trigger zu realisieren, wobei die Daten im 
Pre-Trigger stets persistent gespeichert würden, sodass diese im Falle 
eines Systemausfalls erhalten blieben.
Angenommen, man hat eine regelmäßige, zeitgesteuerte Triggerung und 
erhält eine konstante Anzahl X an Werten pro Sekunde. So wäre es sicher 
denkbar, die Messdaten des Pre-Triggers in einer Datenbank vorzuhalten, 
wobei man dabei stets die Anzahl X der letzten Messwerte beibehält und 
die älteren Daten löscht. Dabei wäre man natürlich arg beschränkt, durch 
die Geschwindigkeit der Datenbank.
Andererseits könnte man auch Dateiblöcke aufzeichnen, unter der Annahme, 
dass
bei einem Trigger-Ereignis (also nicht dem Pre-Trigger-Ereignis) eine 
definierte Anzahl an Messdaten, inkl. den Pre-Trigger-Daten-Blöcken zu 
einer Datei zusammengefügt wird. Wenn man dafür Flash-Speicher 
verwendet, sollte das doch relativ schnell arbeiten, sodass höhere 
Abtast-Frequenzen drin sind, sofern es sauber umgesetzt wäre!?
Es gibt sicher noch mehr (bessere?)(schnellere?) Möglichkeiten.
Ist die Frage verständlich? Hat jemand eine Idee?

Es gibt keinen konkreten Hintergrund zu der Frage, also auch keine 
konkrete Umgebung, in der die Messdatenerfassung realisiert würde, das 
kann beliebig sein, es geht mir mehr darum, wie man so etwas generell 
lösen würde. Gibt es so etwas wie "Lehrbuch-Lösungen" dafür?

Gruß

[Werner B. (Firma: Brösel) (werner2014)]

Werner Brösel schrieb:
> ibt es so etwas wie "Lehrbuch-Lösungen" dafür?

Wie wird es bspw. in einem Oszilloskop umgesetzt?
Wahrscheinlich nicht persistent sondern im RAM!?

[Lars (Gast)]

So ganz habe ich die Frage nicht verstanden glaube ich.

Im Prinzip werden die meisten kontinuierliche Datenerfassungssysteme 
einen Ringpuffer haben. Dies bietet den Vorteil, die Daten zirkulieren 
zu lassen.
Sprich, man hat immer die maximal mögliche Anzahl an aktuellen Daten.
Bei Blockweisem speichern, würde man am Ende des Blocks ja immer die 
Daten verwerfen und dadurch Daten bei einem trigger verlieren.

Man wird es also so machen, das man  kontinuierlich aufzeichnet und bei 
einer Triggerbedingung noch eine definierte Zeit nachläuft.

Klar, Flash ist für sowas ungeeignet da schnell kaputt.
RAM hat den Nachteil das er flüchtig ist, dafür schnell und beliebig oft 
beschreibbar.
Eine Mischung beider  Eigenschaften bietet der FRAM, aber leider meist 
teuer und geringe Speichergrößen.

Man könnte sich auch überlegen den Ringpuffer im RAM zu halten und ab 
und zu einen Block in den Flash zu speichern.

Zumindest hätte man dann nicht alles verloren bei einem Systemausfall...

[Werner B. (Firma: Brösel) (werner2014)]

Lars schrieb:
> So ganz habe ich die Frage nicht verstanden glaube ich.

Doch, ich glaube schon ;-)

So etwas wollte ich hören.

Ich Grunde stehen meine Überlegungen der Ringspeicher-Variante 
gegenüber. Also mich interessiert, ob es eine "bessere" Lösung, 
hinsichtlich der Geschwindigkeit gibt.

Angenommen, man probiert es mit Blöcken und nähme den möglichen 
Datenverlust bis zu einer Blockgröße in Kauf (das optimieren der 
Blockgröße würde den potentiellen Verlust sicher reduzieren), könnte 
eine solche Lösung performanter sein?

Wahrscheinlich spricht zu viel dagegen, da möglicherweise mehr 
IO-Operationen erforderlich sind.

FRAM wäre sicher, egal, für welche Lösung, vorteilhaft.

Wie wäre es mit einem persistenten FIFO?

[lrep (Gast)]

Werner Brösel schrieb:
> Wie wäre es mit einem persistenten FIFO?

FIFOs werden ja meist als Ringspeicher realisiert.
Früher gab es auch "richtige" FIFOs aus z.B. 1024 8-Bit-PIPO-Registern, 
die jeweils noch ein Steuer-Flipflop hatten.
Diese FIFOs waren aber relativ langsam, da die Daten ja erst durch 
sämtliche Register kopiert werden mussten, bis sie am Ausgang 
erschienen, und umgekehrt musste nach Entnahme eines Bytes der Zustand 
"Leer" erst durch sämtliche Steuer-Flipflops vom Ausgang zum Eingang des 
FIFO kopiert werden.

Demgegenüber geht der Abgleich der Adresszähler beim Ringpuffer viel 
schneller.
Den Nachteil, dass beim Ringpuffer lesen und Schreiben i.d.R. nicht 
völlig asynchron erfolgen können, behebt man mit einfachen 
Auffang-Registern.

Was den Datenerhalt bei Stromausfall angeht, so bietet es sich an den 
Speicher und die Steuerlogik in CMOS zu realisieren und eine 
Pufferbattreie zu verwenden.
Die Stromaufnahmen von CMOS ist ja i.W. durch das Umladen von 
Kapazitäten bedingt, und deshalb verbraucht es im statischen Betrieb 
nahezu keinen Strom.