|
|
|
Binärer Datenstrom als String mittels fwrite() |
|
| Cappaja |
Forum-Anfänger
|
 |
Beiträge: 18
|
|
|
|
Anmeldedatum: 11.03.11
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
 |
|
Verfasst am: 08.12.2011, 14:56
Titel: Binärer Datenstrom als String mittels fwrite()
|
 |
Hallo,
ich habe einen sehr langen Binärdatenstrom (pro Sekunde ca. 200.000 Binärstellen) als einen ganzen String. Die Funktionen dec2bin bzw. bin2dec welche zur Konversion genutzt werden, arbeiten mit Strings.
Einfach nur den String an fwrite übergeben liefert mir selbst bei ubit1 einen auf Bytelänge aufgefüllten String mit falschen Daten.
Die zweite Zeile ausgetauscht gegen die untere funktioniert zwar, allerdings muss ich zweimal konvertieren, was bei dem Datenaufkommen unsinnig lange braucht und vermieden werden sollte.
Daher ist meine Frage ob es irgendwie möglich ist den Binärdatenstrom als String zu belassen und als solchen wieder auszulesen!?
Mit freundlichen Grüßen
Cappaja
|
|
|
|
|
|
| Cappaja |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 18
|
|
|
|
Anmeldedatum: 11.03.11
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 08.12.2011, 15:14
Titel:
|
|
Inzwischen löse ich es folgendermaßen:
Binärdatenstrom als Char schreiben und beim ASCII-Wert den Offset abziehen. Allerdings wäre ich nach wie vor um eine direktere Lösung dankbar, falls es überhaupt geht.
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 08.12.2011, 17:29
Titel:
|
|
Hallo Cappaja,
Ein Binär-Datenstrom sollte man am besten als UINT8 speichern.
Ein CHAR belegt 16Bit, so dass man die Hälfte des Speicherplatzes verschwendet.
Mit "result-48" werden die Daten in DOUBLEs umgewandelt - dann benötigen sie 8 Byte pro Wert!
Gruß, Jan
|
|
|
|
| Cappaja |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 18
|
|
|
|
Anmeldedatum: 11.03.11
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 08.12.2011, 20:08
Titel:
|
|
Hallo Jan,
natürlich benötige ich durch die Subtraktion des Offsets eine Konvertierung von double nach string was bei der Datengröße stolze 38 Sekunden benötigt. Aber ein CHAR benötigt meines Wissens auch nur 8 Bit (http://www.mathworks.de/help/techdoc/ref/fwrite.html) und mittels UINT8 bleibt mir die Konvertierung von double nach string bei fread() auch nicht erspart.
Ich möchte mittels fwrite einen String übergeben und mittels fread einen String dementsprechend wieder auslesen können. Wenn es nicht anders möglich ist bleibt mir wohl nichts anderes übrig wie es in C zu lösen.
Grüße Cappaja
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 08.12.2011, 21:32
Titel:
|
|
Hallo Cappaja,
Ich kann Dir bei der Erkläreung, wann Du welchen Typ in welchen konvertierst, nicht folgen.
Ein CHAR benötigt auf jeden Fall 2 Bytes. Siehe:
DEC2BIN erzeugt unpraktischerweise einen String, also CHARs. Deshalb verzichtet man am besten darauf. Du kannst in den Sourcecode schauen, um eine Methode ohne die String-Konvertierung zu erstellen. Statt '1'er und '0'er als String, wären 1er und 0er als UINT8-Vektor wirklich praktischer.
"fread(fid, 'char')" gibt einen DOUBLE-Vektor zurück. Eine Konvertierung ist dann teuer. "fread(fid, '*uint8')" liest einen UINT8 ein und erzeugt einen UINT8-Vektor. Eine Konvertierung ist damit unnötig.
Wenn Du vorher unbedingt die Daten aus einem String schreiben musst (was ich aber eher vermeiden würde), erspart dies die temporäre Konvertierung:
Ich bin ziemlich sicher, dass Du während der gesamten Verarbeitung mit UINT8 arbeiten kannst.
Gruß, Jan
|
|
|
|
| Cappaja |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 18
|
|
|
|
Anmeldedatum: 11.03.11
|
|
|
|
Wohnort: ---
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 09.12.2011, 13:23
Titel:
|
|
| |
 |
 |
Hallo Jan,
ich habe ein Kompressionsmodul welches pro Sekunde ca. 20 mal die Funktion dec2bin() aufruft. Unterschiedliche Datenfelder unterschiedlichen Typs werden mit verschiedenen Kompressionsalgorithmen komprimiert. Der sich daraus ergebende Binärdatenstrom eines Datenfeldes wird mit dem der anderen zusammengefügt und mit weiteren Header-Informationen als ein Frame am besten in eine Binärdatei gespeichert. Mit dem Vorschlag die Daten als uint8 abzuspeichern kann ich dir soweit noch folgen, allerdings sollten sie ubit1 sein, da ich nicht byteweise dekodiere sondern angepasst an die Datenfelder für Header-Informationen und Subframes unterschiedlich lange auszulesende Codefolgen habe.
Wenn ich also vor der Übertragung meine Daten wie folgt konvertiere: '10100101010' => [ 1 0 1 0 0 1 0 1 0 1 0 ] dann bleibt mir rechnerisch nichts erspart zumal ich im Dekompressionsmodul wieder etliche male bin2dec() aufrufe.
Warum die Funktionen dec2bin bzw bin2dec mit Strings arbeiten ist mir sowieso schleiferhaft. Aber ich sehe schon das dieses Problem wohl nur durch eine eigens geschriebene bin2dec() Funktion gelöst werden kann. In jedem Fall muss ich immer mindestens auf einer Seite konvertieren, was mir für eine Echtzeitlösung einen Strich durch die Rechnung macht.
Grüße Cappaja
|
|
|
|
| Jan S |
Moderator
|
|
Beiträge: 11.057
|
|
|
|
Anmeldedatum: 08.07.10
|
|
|
|
Wohnort: Heidelberg
|
|
|
|
Version: 2009a, 2016b
|
|
|
|
|
|
|
Verfasst am: 09.12.2011, 14:19
Titel:
|
|
Hallo Cappaja,
Eine selbstgeschriebene BIN2DEC-Funktion ist eine gute Idee. Die kann dann gleich UINT8 Daten erzeugen. Innerhalb von Matlab gibt es kein UBIT1-Format.
Aber eine C-mex-Funktion könnte das effizient leisten. Dann wären die Daten zwar immer noch als UINT8 gespeichert, würden dann aber alle 8 Bits benutzen. Diese Daten könnte man dann schnell per FWRITE(Data, 'uint8') schreiben.
Wie wäre es mit: Logical2Bin und Bin2Logical, wobei "Logical" entweder ein String mit '0' und '1' oder ein UINT8 oder ein DOUBLE mit 0 und 1-Werten ist. "Bin" wäre dann ein UINT8-Datenstrom. Als zweiten Output benötigt man noch die Anzahl der Bits, damit man '01' und '001' auseinanderhalten kann.
Ich könnte das Programm dann gleich in die FEX setzen.
Gruß, Jan
|
|
|
|
|
|
|
Einstellungen und Berechtigungen
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2025
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
|
|
