uint16_t Array in uint8_t Array umsortieren
-
@SeppJ
Irre... ich schaffe es immer wieder relevante Details zu ignorieren
Trotzdem kann man das Datenmodell so aufbauen, man hat dann nur keinen vector zur Verfügung und muss dann halt in einuint8_tArray schreiben.
-
@DocShoe sagte in uint16_t Array in uint8_t Array umsortieren:
Was mich hier etwas verwirrt ist der wilde Mix aus uint8_t, uint16_t und uint32_t
ALSO ...
Die Daten kommen per SPI von einem EKG-Frontend, quasi ein 24-bit ADC (stark vereinfacht). Der STM32f469 der die Daten entgegen nimmt kann nur max. 16bit lesen und schreiben (8 kann er auch). Das heißt für ein 32bit Word wie 0x80000000 muss ich zwei 16bit Transfers machen und da ich das per DMA mache flutschen die Daten halt in ein uint16_t array.
Das ich die Daten dann beim sortieren in ein uint8_t array packe um dieses dann an die SD-Karte zu senden ist evtl. ungeschickt. Vielleicht kann ich auch gleich ein uint16_t array auf die Karte schreiben.
Ich kontempliere erstmal über eure Ansätze
-
Unabhängig deiner Frage drängt sich der Verdacht auf, dass du vielleicht zu sehr vereinfacht hast, vielelicht unabsichtlich. Denn: Wieso sind da magische Frameheader drin, wenn die Frames immer die gleiche Länge haben? Wozu die Marker 11,12,13, wenn diese immer gleich sind?
Bist du wirklich sicher, dass deine Annahmen richtig sind und diese Informationen getrost wegeworfen werden können? Denn wenn sie so unnötig wären, dann hätte man sie wahrscheinlich nicht eingebaut.
-
@pauledd sagte in uint16_t Array in uint8_t Array umsortieren:
EKG-Frontend
Wenn damit soetwas wie Frontend AD8232 für EKG-Herzfrequenzmesser gemeint ist, machen mir deine Fragen hier Angst.
-
@pauledd
Du orientierst dein Design am Übetragungsweg, das sollte man mMn nicht machen. Überleg´ dir ein Datenmodell, das deine Daten vernünftig repräsentiert, ohne durch irgendwelche Protokolleigenschaften eingeschränkt zu sein. Anschließend braucht du mind. einen Protokollhandler, der deine Daten im protokollspezifischen Format lesen und schreiben kann. Die Fummelei auf Telegrammebene würde ich so nicht machen.PS:
Schon deine Aufgabenbeschreibung ist falsch. Du willst nicht alle 0x11, 0x12, 0x13 aus den Daten entfernen. Deiner Beschreibung nach willst du alle 0x11, 0x12, 0x13 aus den Telegrammdaten entfernen, wenn sie die obersten 8 Bit eines DWORDs sind.
-
@SeppJ sagte in uint16_t Array in uint8_t Array umsortieren:
Wieso sind da magische Frameheader drin, wenn die Frames immer die gleiche Länge haben? Wozu die Marker 11,12,13, wenn diese immer gleich sind?
Die Header mit 0x80 zeigen an das der ADC die Daten fertig gesampled hat und ausgelesen werden können. 0x11 0x12 0x13 bezeichnen die jeweiligen EKG-Elektroden, nämlich LA, LL und RA. Die Anzahl und welche Elektroden ausgelesen werden sollen muss vor dem Transfer konfiguriert werden und für meine Anwendung reichen mir die drei (von fünf möglichen).
Datenaufbau:
http://p-bg.de/pics/Screenshot_20210505_142516.pngMitschnitt eines Transfers:
http://p-bg.de/pics/Screenshot_20210505_143730.pngBeschreibung der Daten Words:
http://p-bg.de/pics/Screenshot_20210505_145510.pngAber das geht schon viel zu weit... die Daten kommen nun mal so an und ich will die Binary Datei so klein wie möglich halten. Ich habe zuvor immer die ganzen 32bit (0x11......., 0x12........0x1300000) in einer Binary gespeichert und das klappte soweit ganz gut.
Also werfe ich den Word-Identifizierer und den Header weg und spare fast 500MB Daten wenn ich 24h Daten auf die SD-Karte logge...
-
@DocShoe sagte in uint16_t Array in uint8_t Array umsortieren:
Die Fummelei auf Telegrammebene würde ich so nicht machen.
Was meinst du mit Telegramm?
-
@manni66 sagte in uint16_t Array in uint8_t Array umsortieren:
Wenn damit soetwas wie Frontend AD8232 für EKG-Herzfrequenzmesser gemeint ist, machen mir deine Fragen hier Angst.
Keine Angst, das ganze wird nicht am echten Menschen getestet sondern nur simuliert
-
@pauledd sagte in uint16_t Array in uint8_t Array umsortieren:
Aber das geht schon viel zu weit... die Daten kommen nun mal so an und ich will die Binary Datei so klein wie möglich halten. Ich habe zuvor immer die ganzen 32bit (0x11......., 0x12........0x1300000) in einer Binary gespeichert und das klappte soweit ganz gut.
Also werfe ich den Word-Identifizierer und den Header weg und spare fast 500MB Daten wenn ich 24h Daten auf die SD-Karte logge...
Kompression?
-
@SeppJ sagte in uint16_t Array in uint8_t Array umsortieren:
Kompression?
Damit kenne ich mich absolut nicht aus und würde den Rahmen sprengen. Ich weiß auch nicht wieviel CPU Zeit Komprimierung beanspruchen würde da das ganze nicht Zeitunkritisch ist.
Der Speicher auf dem µC ist schon fast gänzlich für den Lese/Schreibpuffer ausgereizt und vom Timing her würde ich ungern noch in irgendwelchen zusätzlichen Funktionen CPU Zeit investieren.
Später ist evtl. noch geplant das ISHNE Binärformat für EKG Daten zu implementieren. Aber das ist nur eine Idee...
-
Ich meinte das nicht so, dass du selber Kompressionsalgoithmen implementieren sollst. Sondern, dass du fertige Standardkompressionsprogramme nutzen solltest. Die verkleinern deine Daten nochmals deutlich mehr als das, was du dir hier selber ausdenkst, und du sparst dabei massiv deine eigene (nicht kostenlose) Zeit, und vermeidest zudem auch alle vorstellbaren Fehler.
Aber wenn's wirklich ein Ressourcenbottleneck gibt, dann verwirf die Idee. Oder besser noch: Prüf es einmalig. Vielleicht verschätzt du dich ja. Wenn's nämlich doch reicht, dann gewinnst du viel.
-
@manni66 sagte in uint16_t Array in uint8_t Array umsortieren:
@pauledd sagte in uint16_t Array in uint8_t Array umsortieren:
EKG-Frontend
Wenn damit soetwas wie Frontend AD8232 für EKG-Herzfrequenzmesser gemeint ist, machen mir deine Fragen hier Angst.
+1
