Vorschlag: Diveprofile Speicheroptimierung
Posted: Saturday 2. September 2017, 11:34
Hallo,
mir ist aufgefallen, dass der Druck/Tiefe pro Sample als 16bit Wert im Flash gespeichert wird. (falls ich ghostwriter.asm Zeile 37 ff. richtig interpretiere und den Aufruf in divemode.asm).
Da der MS5541C Sensor 16bit rauswirft und max 14 Bar messen kann, ändert sich das high order byte nur alle ~0,54m Wassertiefe (falls ich richtig rechne). Sprich die Chance, dass zwei Samples das selbe high order byte besitzen ist relativ groß beim normalen tauchen und einer Samplingrate von 30 Hz, falls man jetzt nicht gerade 16m/minute (b.z.w. +-8m) auf oder absteigt.
Man könnte die Messwerte im Flash Delta enkodieren, sprich es wird am Anfang einmal das high order und das low order byte geschrieben, danach nur noch der Offset, da dieser selten > +-0,22m zwischen zwei Samples ist wird fast der komplette Tauchgang als 8bit pro Sample gespeichert, man hat aber trozdem die 16bit Auflösung wie vorher. Sollte der Offset > 127 oder < -127 sein, reserviert man einfach den Wert 0xFF dafür um zu signalisieren, dass jetzt ein 16bit Wert folgt, sprich dieses sample benötigt dann 24bit, das kommt aber relativ selten vor. Der neue 16bit Wert ist dann natürlich basis für folgende 8 bit "delta" samples.
Vorteile:
- Fast doppelt so viele Samples in der selben Flashgröße speicherbar wie wenn man alles als 16bit speichert.
- Implementierung benötigt kaum Rechenleistung
Nachteile:
- Die Länge des Datenbereichs lässt sich nicht anhand der Anzahl der Samples ermitteln, man braucht beide Werte unabhängig (weiteres Headerfield)
- Springen an eine bestimmte Sampleposition ist nur möglich, wenn man alle vorherigen Samples einliest, da die Beziehung Sampleoffset - Datenoffset nicht mehr linear ist.
mir ist aufgefallen, dass der Druck/Tiefe pro Sample als 16bit Wert im Flash gespeichert wird. (falls ich ghostwriter.asm Zeile 37 ff. richtig interpretiere und den Aufruf in divemode.asm).
Da der MS5541C Sensor 16bit rauswirft und max 14 Bar messen kann, ändert sich das high order byte nur alle ~0,54m Wassertiefe (falls ich richtig rechne). Sprich die Chance, dass zwei Samples das selbe high order byte besitzen ist relativ groß beim normalen tauchen und einer Samplingrate von 30 Hz, falls man jetzt nicht gerade 16m/minute (b.z.w. +-8m) auf oder absteigt.
Man könnte die Messwerte im Flash Delta enkodieren, sprich es wird am Anfang einmal das high order und das low order byte geschrieben, danach nur noch der Offset, da dieser selten > +-0,22m zwischen zwei Samples ist wird fast der komplette Tauchgang als 8bit pro Sample gespeichert, man hat aber trozdem die 16bit Auflösung wie vorher. Sollte der Offset > 127 oder < -127 sein, reserviert man einfach den Wert 0xFF dafür um zu signalisieren, dass jetzt ein 16bit Wert folgt, sprich dieses sample benötigt dann 24bit, das kommt aber relativ selten vor. Der neue 16bit Wert ist dann natürlich basis für folgende 8 bit "delta" samples.
Vorteile:
- Fast doppelt so viele Samples in der selben Flashgröße speicherbar wie wenn man alles als 16bit speichert.
- Implementierung benötigt kaum Rechenleistung
Nachteile:
- Die Länge des Datenbereichs lässt sich nicht anhand der Anzahl der Samples ermitteln, man braucht beide Werte unabhängig (weiteres Headerfield)
- Springen an eine bestimmte Sampleposition ist nur möglich, wenn man alle vorherigen Samples einliest, da die Beziehung Sampleoffset - Datenoffset nicht mehr linear ist.
