Ich nutze die FTDI FT2XX_NET.dll um Daten via USB aus einem angeschlossenen Gerät zu lesen.
Dabei gibt es mehrere Möglichkeiten die Daten aus dem Empfangspuffer zu holen.

FTDI.Read(byte[] dataBuffer, UInt32 numBytesToRead, ref UInt32 numBytesRead)

bzw.

FTDI. Read(out string dataBuffer, UInt32 numBytesToRead, ref UInt32 numBytesRead)

I.d.R. nutze ich einen String als dataBuffer, da die Daten als ASCII Zeichen vorliegen.
Über die empfangenen Daten bilde ich zeichenweise eine simple XOR Prüfsumme



Es gibt einen einzigen Fall, in dem ich die Daten nicht als ASCII, sondern (mutmaßlich, zumindest behauptet das Notepad++) als ANSI bekomme. Es handelt sich dabei um eine komprimierte Textdatei. Diese wird nicht entpackt sondern so wie sie ist die Prüfsumme darüber gebildet. Hierbei schlägt jetzt meine Prüfsummenbildung fehl, weil für Zeichen mit einem gesetzten MSB keine Entsprechung im ASCII String möglich ist. Es kommt zu keiner Fehlermeldung, aber die Prüfsumme ist am Ende falsch, weil z.B. 0x8B als 0x3F interpretiert wird.

Daher nutze ich an dieser Stelle den byte[] dataBuffer und



zur Prüfsummenbildung.

Das ist nicht so schick, weil ich die beiden Möglichkeiten unterscheiden muss.
Gibt es denn nicht eine Möglichkeit auf das Auslesen der empfangene Daten als byte[] Array zu verzichten und die einzelnen Zeichen des String so umzuwandeln, dass sie nicht als ASCII (max. 07F) sondern als Zeichen bis 0xFF zu verstehen sind?

@Haudruferzappeltnoch hast recht, btIntCheckSum = btCheckSum, mein Fehler.

Ich bin jetzt letzte Nacht noch mal in mich gegangen und kam zum Schluss, dass mein Vorhaben wohl zum Scheitern verurteilt ist.
Grund: wenn ich Daten mittels des ersten Snippets lese, bekomme ich einen String.
Alle darin enthaltenen Zeichen sind ASCII, d.h. max. 0x7F.
Enthalten die zu lesenden Daten aber z.B. 0x8A, kann das im String nicht abgebildet werden.
Daher wird an dieser Stelle 0x3F (?) eingetragen. Es ist also nicht möglich diesen String in Byte() zu wandeln und an der entsprechenden Stelle wieder das 0x8A zu bekommen.
Umgekehrt kann ich aus Byte() aber auch keinen sinnvollen String erzeugen, weil dort eben alles über 0x7F zu 0x3F wird.
Da ich in 99,9% aller Fälle einen ASCII String lese und benötige und nur in einem einzigen Fall Zeichen außerhalb ASCII vorkommen können, werde ich wohl die bisherige „Zweiwegelösung“ beibehalten und in diesem einen speziellen Fall Snippet 2 zum lesen verwenden.

Ah, sieh an, wieder was gelernt.
Ändert aber leider auch nichts an der Tatsache, dass in meinem empf. String für Zeichen außerhalb ASCII 0x3F(?) steht, was eine Umwandlung in Byte nicht ermöglicht.
Aus diesem Grund gibt es vermutlich auch die Möglichkeit die Daten direkt als Byte abzuholen.