|
Anzeige
|
C++ zu C# Code konvertieren
Gast
#2704667
Hei Leute Ich versuche gerade eine C++ Awendung auf .Net umzuschreiben. Leider habe ich ein Problem mit dieser CRC Kalkulierung. Da sie etwas speziell ist, benötige ich Sie genau so wie im C++-File. Ich habe das ganze umgeschrieben nur irgendwie funktioniert das Ding nicht! Könnte mir vielleicht jemand sagen wo mein Fehler liegt. Ich seh' irgendwie den Wald vor lauter Bäumen nicht mehr.. Danke und Gruss Farin
Gast
#2704670
> StreamReader sr = new StreamReader(file); http://msdn.microsoft.com/de-de/library/system.io.streamreader%28v=vs.80%29.aspx Implementiert einen TextReader, der Zeichen aus einem Bytestream in einer bestimmten Codierung liest. Das ist bestimmt nicht was du willst. Du solltest einen binary Reader verwenden. http://msdn.microsoft.com/de-de/library/system.io.binaryreader.aspx
Gast
#2704679
Ok ich hab den StreamReader raus und den BinaryReader reingemacht.. Leider ist das Ergebnis noch immer nicht das Gleiche wie vom C++ File. Kannst du mir vielleicht noch einmal helfen? Danke und Gruss Farin
Gast
#2704703
Wieso benutzt du in der C++-Version 'unsigned int' und in der C#-Version 'UInt64'?
Gast
#2704709
Stimmt! Mein Fehler! Ich hab einen UInt32 draus gemacht. Erhalte aber noch immer das falsche Resultat...
Gast
#2704721
Noch ein Fehler du benutzt in der C++-Variante 'unsigned short fileData' und in der C#-Variante 'byte'. Das muss deshalb eher so aussehen
Gast
#2704736
Achja die Division durch 2 fliegt dann natürlich raus.
Gast
#2704744
Dies hat einen spezifischen Grund.. Ich weiss nicht was fread in der C++ Variante überhaupt ausliest. Er liest nach vorgabe unsigned char(8 bit) in ein unsigned short array(16 bit pro eintrag). Was macht der genau? Jeweils zwei chars pro short oder ein char pro short und dann shiften? Nach Zeile 32 im C#-Programm fehlt
Es ist aber nicht korrekt, bei ungerader Blockgröße einfach 0xFF-Bytes einzufügen (das ist im C++-Programm schon falsch):
Das muss man vermutlich am Ende der Datei machen, aber ganz sicher nicht in der Mitte, weil sonst das CRC-Ergebnis davon abhängt, wie die die Datei beim Einlesen gestückelt wird. Bei gewöhnlichen Dateien tritt der Fehler wahrscheinlich nicht in Erscheinung, da die fread- bzw. Read-Funktion bei jedem Aufruf bis auf den letzten die gewünschte Anzahl von Bytes (2048) lesen wird und 2048 eine gerade Zahl ist. Ist die Datenquelle aber keine Datei, sondern bspw. eine serielle Schnittstelle, wird die Funktion ziemlich sicher bei gleichen Daten jedesmal ein anderes Ergebnis liefern. Ich verstehe aber sowieso nicht, warum im Originalprogramm die Daten 16-bit-weise verarbeitet werden. Durch die Art und Weise, wie dies gemacht wird, hängt das Ergebnis nämlich zusätzlich von der Endianess der verwendeten Plattform ab. Das Originalprogramm ist also ziemlicher Murks. Wenn du dazu kompatibel bleiben musst, kannst du diesen Murks übernehmen. Wenn du aber eine ordentliche CRC berechnen möchtest, solltest du dir eine andere Vorlage suchen. Yalu X. schrieb: > Das Originalprogramm ist also ziemlicher Murks. Wenn du dazu kompatibel > bleiben musst, kannst du diesen Murks übernehmen. Wenn du aber eine > ordentliche CRC berechnen möchtest, solltest du dir eine andere Vorlage > suchen. Ergänzend: Es würde mich schon sehr wundern, wenn es in der umfangreichen .Net Bibliothek nicht schon eine fix&fertige CRC Berechnung gäbe.
Gast
#2704814
Es gibt alles fixfertig. Aber das Problem ist. Dieser Algorythmus wurde auf einer integrierten Schaltung verwendet. Und um diese Schaltung noch verwenden zu können muss mein Tool diese spezielle CRC auch so berechnen können. Ich weiss es ist nervig und ich würde jeden anderen Weg bevorzugen aber es geht nunmal einfach nicht anders...
Gast
#2704902
Ok Leute ich habs! Das Problem war effektiv das ushort/byte array in das ich die Daten kopiert habe. Ich habe das Kopieren der Daten nun folgendermassen realisiert und schon gehts perfekt wie ichs wollte:
Danke an alle Helfer. Ihr seid super! Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
