Die Länge kennt man doch bevor man die Aufzeichnung beendet hat garnicht?

Mir ist grade eine andere Idee gekommen.

Angenommen, ich habe maximal 4 Kanäle die ich aufzeichnen kann. Wenn ich zwischen 4 Datenbytes (also die vier Messwerte der Kanäle zu einem Zeitpunkt) ein Trennbyte, z.B. 0xFF setze, habe ich quasi einen Rhythmus. Das Programm weiß, dass nach dem Header jedes 5. Byte 0xFF sein muss. Wenn also 4 Bytes nach einem 0xFF kein 0xFF kommt, habe ich ein Zeichen dafür, dass hier der Datensatz endet.

Oder:
Wieder maximal 4 Datenbytes pro Zeitpunkt. Das fünfte Trennbyte ist eine Art Prüfsumme, z.B. die unteren 8 Bits der Summe der vier Messwerte. Wieder weiß das Programm, dass nach dem Header das 5. Byte die Summe der vier vorausgehenden Bytes ist. Wenn nun die Summe von vier Bytes ungleich dem 5. Byte ist, ist das das Ende des Datensatzes.

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Wenn man das statisch und mit bekannten Abfolgen macht, geht es auch so. Ich würde dann allerdings die erste Methode mit 0xff als Trennzeichen benutzen. Die zweite Methode muss nicht immer hinhauen.
Allerdings verschenkt man dann mit den redundanten Steuerzeichen Platz im Flash. Bei vier Datensätzen gehen schon 4 Byte flöten.
Und man kann u.U. nicht zwischen alten und neuen Werten unterscheiden: Durch die Datensatzlänge und evtl. Offset kann ich sicher sein, dass die gelesenen Werte auch Sinn ergeben. Bei 0xff kann es sich auch um leere Seiten im Flash handeln...


Wulf hat es allerdings auf den Punkt gebracht: Im Header die Länge des Payloads (Nutzdaten) mitspeichern. Das macht man in vielen Bereichen so.
Dazu kannst du um den Flash zu schonen, ein paar hundert Datensätze im RAM aufzeichnen und mit einem Timer alle paar Zeiteinheiten alle gesammten Datensätze zum Flashbaustein rüberschieben. Dabei kann man dann die Datenlänge berechnen und mitschreiben bzw. man hat noch eine Zählvariable und nimmt deren Wert, der jede Messung erhöht wird, als Datensatzlänge.


Mein Vorschlag wäre eine Tabelle mit Basis-Adresse und Datensatzlänge.
Blöd bei allen Methoden: Bestimmte Zellen werden sehr häufig, z.B. meine Tabellen oder deine Basiszellen der Pages, beschrieben, während die Endbereiche kaum oder gar nie beschrieben werden.

_________________


[ Diese Nachricht wurde geändert von: DonComi am 21 Mai 2009 23:24 ]

[ Diese Nachricht wurde geändert von: DonComi am 21 Mai 2009 23:27 ]

Zitat :

Allerdings verschenkt man dann mit den redundanten Steuerzeichen Platz im Flash. Bei vier Datensätzen gehen schon 4 Byte flöten.

Das find ich nicht sooo tragisch. Bei 64k Platz und der maximalen Samplingrate von 4Hz sind das immernoch etwa 54 von möglichen 68min. Man könnte auch alle 16 Bytes (also 4 Samples á 4 Bytes) ein Steuerzeichen einbauen, was weniger Platz verschwenden würde. Statt 0xFF nimmt man dann halt 0x55, damit, wie du schon sagtest, der Kontrollör zwischen leerem Flash und Steuerzeichen unterscheiden kann.

Zitat :

Und man kann u.U. nicht zwischen alten und neuen Werten unterscheiden

Wie meinst du das? Ich schreib ja nicht kreuz und quer in den Flash.

Zitat :

Mein Vorschlag wäre eine Tabelle mit Basis-Adresse und Datensatzlänge.

Das ist glaube ich die beste Möglichkeit. Müsste ich mir halt nen kleinen festgelegten Bereich am Anfang des Flashs reservieren. Internes EEPROM ist überflüssig Hab ja genug Flash zur Verfügung.

Hätte auch Geschwindigkeitsvorteile: Habe eine Funktion die den noch freien Speicherplatz anzeigt, braucht bei komplett leerem Flash etwa 1,3s um die 64k durchzuklappern und zu prüfen, ob 0xFF drinsteht. Bei dieser "FAT" Variante müsste er nur ein paar Bytes verrechnen. Ähnlich bei der (noch nicht implementierten) Datensatz-Ausgabefunktion: Ohne FAT müsste er den Flash durchklappern um den Header mit der richtigen Datensatz-Nummer zu finden, mit FAT wäre das wieder nur etwas Rechnerei.

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Moin,

Zitat :

Zitat : >> Und man kann u.U. nicht zwischen alten und neuen Werten unterscheiden Wie meinst du das? Ich schreib ja nicht kreuz und quer in den Flash.

Naja, angenommen, gleiche Zellen sollen irgendwann mal überschrieben werden. Dann ändert sich das Muster ja nicht:

n1-4: neue Bytes
a1-4: alte Bytes

n1 n2 n3 n4 0xff n1 n2 n3 n4 0xff n1 n2 n3 n4 0xff a1 a2 a3 a4 0xff a1 a2 a3 a4 0xff a1 a2 a3 a4 0xff a1 a2 a3 a4 ...
(ich weiß nicht, ob du Big- oder Littleendian hast, aber das spielt hier erstmal keine Rolle).

Bis zu der Stelle, wo der Fettdruck aufhört, stehen relevante Daten im Flash, danach kommen alte, nicht mehr gebrauchte Werte. Sie gehören einfach nicht zum aktuellen Datensatz, werden aber dennoch gelesen, weil das Muster, also jedes fünfte Byte = 0xff, stimmt. Das reicht also nicht aus.

Zitat :

Ich schreib ja nicht kreuz und quer in den Flash.

Das wäre aber u.U. garnicht schlecht, wenn die Daten ein wenig zufällig verteilt werden. Schont die Zellen, da sie statischtisch seltener neubeschrieben werden. Allerdings: wenn die Zuordnungstabelle an statischen Adressen liegt (und häufig neugeschrieben wird) relativiert sich das. Man muss ja nicht übertreiben und 4Hz Samplingrate sind ja auch nicht sehr viel .

Zitat :

Müsste ich mir halt nen kleinen festgelegten Bereich am Anfang des Flashs reservieren. Internes EEPROM ist überflüssig Hab ja genug Flash zur Verfügung. Hätte auch Geschwindigkeitsvorteile: Habe eine Funktion die den noch freien Speicherplatz anzeigt, braucht bei komplett leerem Flash etwa 1,3s um die 64k durchzuklappern und zu prüfen, ob 0xFF drinsteht. Bei dieser "FAT" Variante müsste er nur ein paar Bytes verrechnen. Ähnlich bei der (noch nicht implementierten) Datensatz-Ausgabefunktion: Ohne FAT müsste er den Flash durchklappern um den Header mit der richtigen Datensatz-Nummer zu finden, mit FAT wäre das wieder nur etwas Rechnerei.

Genau. Du legst eine Speicherstelle fest, die angibt, wo die Tabelle anfängt und wie lang sie ist (oder Anfang und Ende).
Oder du machst es ein wenig unkomplizierter und legst z.B. die Tabelle in eine Seite. Die hat dann halt ein paar Kilobyte zur Verfügung, stört niemanden.
Musst aber auch hier wieder festlegen, wie groß dieser Block ist - sonst ließt dein Programm übers Tabellenende hinaus, wo u.U. nur Blödsinn steht.



_________________


[ Diese Nachricht wurde geändert von: DonComi am 22 Mai 2009  3:35 ]

Warum nimmst du keine SD/MMC-Karte?
Die sind ja mittlerweile sehr günstig zu haben...

_________________

Nicki: Weil ich bisher nur Code in C und für AVRs gefunden habe. Und genug RAM um einen 512Byte-Block komplett einzulesen hab ich nicht. Die Dokumentation der SD-Karten von Hitachi hab ich zwar, werd aber nicht so ganz schlau daraus. Hat imho auch etwas viel Overhead. Da steuer ich lieber nach alter Väter Sitte nen Flash an. Zudem sind mehrere hundert Megabyte wesentlich komplizierter zu verwalten als 256kbyte.

DonComi:

Zitat :

Naja, angenommen, gleiche Zellen sollen irgendwann mal überschrieben werden. Dann ändert sich das Muster ja nicht

Ein neuer Datensatz wird nach dem vorherigen in den Flash geschrieben, da wird nix überschrieben. Wenn der Flash voll ist, muss man entweder per Jumper eine andere 64k-Seite einstellen oder Löschen.

Zitat :

Das wäre aber u.U. garnicht schlecht, wenn die Daten ein wenig zufällig verteilt werden. Schont die Zellen, da sie statischtisch seltener neubeschrieben werden.

Wearlevelling also. Meine Idee dazu: Nach jedem Löschen einer 64k-Seite denkt sich der PIC eine Zufallsfolge von 256 Bytes aus, die alle nur einmal vorkommen. Diese schreibt er z.B. auf die ersten 256 Adressen. Mit der somit mehr oder weniger zufälligen Zuordnung Soft-Adresse l--> Hart-Adresse wird das höherwertige Adressbyte codiert. Damit sind aus der Sicht des Programms aufeinanderfolgende 256Byte-Blöcke in Wirklichkeit kreuz und quer über den Flash verteilt. Die Zahlenfolge sollte aber als Hart-Adresse keine 0 enthalten, sonst wird die Zuordnungstabelle


Kleinspannung (kam per PM, hoffe ist nicht schlimm):

Zitat :

Ich lese hier grad interessiert mit,und verstehe nicht ein viertel davon. Wo lernt man den Umgang mit diesen Sachen,bzw. wo hast du das gelernt?

Was meinst du genau? Die Ansteuerung von dem Flash-Baustein oder das "Dateisystem"-Gewurstel? Oder ganz was anderes?

Zur allgemeinen Belustigung mal den Schaltplan des Ganzen:
An PortB hängt noch ein LCD und die Matrixtastatur.

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Moin, hab den Schaltplan zwar nicht auf elektrische Fehler durchsucht, sieht aber sonst vernünftig aus


Ja, wenn das so ist, dann schreibe die Daten doch einfach linear in den Speicher. Bei der "Geschwindigkeit" und der Seitengröße ist das doch alles kein Problem.
Das zufällige Verteilen würde ich auch sein lassen - man sollte es in dem Fall nicht zu kompliziert machen.

Sowas ergibt wirklich erst dann Sinn, wenn viele Zellen in sehr kurzer Zeit beschrieben werden und diese Daten, aus reiner Adressierungssicht immer an der gleichen Stelle stehen.

Da greift man dann zu diesen Zuordnungen von physikalischer und logischer Adresse (die, die nämlich der Prozessor vornimmt).

_________________

Die Hardware läuft, das ist nicht das Problem. Ist alles nur noch eine Frage der Software

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Verstehe ich das richtig: du schreibst einen einzigen Header und dann kommen 4 Mal in der Sekunde einfach nur Datensätze (oben als "body" bezeichnet) dazu? Es ist doch möglich aus den Daten im Header die Datensatzlänge zu berechnen, oder? Du brauchst also gar kein Trennzeichen zwischen den Datensätzen. Man muss ja nur mitzählen.

Ein einfaches wear-levelling habe ich mir mal so gedacht: du reservierst ganz am Anfangs des Flashs 256 Byte. Das aller erste Byte ist das MSB. in die restlichen 255 kommt das LSB, jeweils an die Position die vom MSB grade angegeben wird. Beide zusammen geben gleichzeitig die aktuelle Schreibadresse im Flash an (je nach Größe des Flashs bezeichnet das eine Byte, Word, DWord, usw. Adresse). Wenn die Datensätze gelöscht werden, müssen die zwei Werte erhalten bleiben (falls man das ganze Flash komplett löscht, muss man sich die zwei Byte kurz merken; man braucht ja nicht die ganze Tabelle), sodass bei der nächsten Datenaufnahme an der richtigen Stelle weiter geschrieben wird. So wird das ganze Flash recht gleichmäßig verwendet (dazu dienen auch die 255 LSBs, eigentlich würde eine einzige Stelle im Flash reichen, aber das eine Byte würde dann sehr oft beschrieben werden). Vor jeder Datenaufnahme muss man sich noch die aktuelle Start-Adresse merken, damit man weiß, wo im Flash man zu lesen beginnen muss, wenn man die Daten auch mal haben will. Entweder man schreibt sie an eine eigene fixe Position im Flash, oder zum Beispiel in die Wear-Levelling-Tabelle, mitlaufend hinter dem LSB (254 Bytes der Tabelle sind ja eigentlich ungenutzt).

Nein, ich dachte mir das so:
Wenn eine Aufnahme gestartet wird, schreibt der PIC erst einen Header, der die Parameter enthält, also Samplingrate und Kanäle. Dann kommen im Takt der Abtastung die jeweiligen Werte der Kanäle an und werden an den nachfolgenden Adressen im Flash gespeichert. Wenn die Aufnahme gestoppt wird, kommt halt entweder eine Art Stopp-Bytesequenz oder eben die End-Adresse in die FAT. Bei der nächsten Auzeichnung wird dann einfach der Header der neuen Aufzeichnung auf die nächste freie Adresse geschrieben, nachfolgend wieder die Datenbytes.

_________________
Fnord ist die Quelle aller Nullbits in deinem Computer.
Fnord ist die Angst, die Erleichterung, und ist die Angst.
Fnord schläft nie.

Vor DOS gabs CP/M.
Kannst ja mal schauen, wie dort die Disketten organisiert waren.
http://de.wikipedia.org/wiki/CP/M