Checksumme bestimmen (wahrscheinlich CRC8)

Hast Recht... Habe ich jetzt auch gemacht. Aber das Problem ist, dass 
ich für den oberen Fall 0xC7 bekomme. Für den zweiten Fall keine Lösung 
und für den 3. Fall 0x5B...

Also eine einfache CRC Berechnung scheint es doch nicht zu sein.

Zuumindest bei den Seriellen Protokollen mit denen
ich üblicherweise zu tun habe kommt die Checksumme nach ETX.
Dort wird das Paket ohne STX, aber mit ETX über simples XOR
der Bytes mit einer "Checksumme" (BCC) am Ende versehen.
Also:

1

STX XX XX XX XX ETX BCC

> Woher soll das "Protokoll" erkenen, welcher der 02er der Start ist.

Start kann ja nur das erste STX sein. Danach sucht man ja
üblicherweise nach dem ETX. Hat sein Paket zusammen, zieht
die Checksumme, und vergleicht sie mit der Checksumme
des Paketes.

Wenn die Checksumme wirklich Teil des Paketes ist, dann muss
verhindert werden, dass diese den Wert ETX annimmt.
Entweder über spezielles Escaping oder indem man die Checksumme
hinter das ETX schiebt.

Tiramisu schrieb:
> Das Uebertragungsprotokoll waere ziemlich vermurkst,
> wenn die bisherigen Hypothesen so stimmen.

Warum vorhandene 02 / 03 des Frames nicht Escaped werden ist mir auch 
ein Rätsel, aber ist halt so...

Eine komplette Nachricht sieht so aus:

<STX> <Kommando> <Payload-Länge> <Payload> <CRC> <ETX>

Wobei das niederwertigste Bit des Kommandos immer die Datenrichtung 
angibt.

Durch das zeitliche Verhalten (immer ca. 1 Sekunde Pause zwischen den 
Telegrammen) sollten die oben gezeigten Telegramme schon richtig 
dargestellt sein. Durch STX, Länge, CRC und ETX ist die Syncronisation 
wohl relativ sicher. (auch ohne Escape).

Im Anhang ist mal ein längerer Trace. Die beiden Kommunikationspartner 
scheinen im Request / Respone Verfahren zu kommunizieren.

Die Berechnungen erfolgen im übrigen auf einem STM32F103

Ja. Ich habe den kompletten Frame ja schon um 8:35 Uhr beschrieben:

Fabian H. schrieb:
> Eine komplette Nachricht sieht so aus:
>
> <STX> <Kommando> <Payload-Länge> <Payload> <CRC> <ETX>
>
> Wobei das niederwertigste Bit des Kommandos immer die Datenrichtung
> angibt.

Es geht mir jedoch um die Prüfsummen-Berechnung.

Und Du konntest früher mal lesen. :-P

Aber nu prüfe ich erstmal, ob es sich um Dallas CRC8 handelt, denn ich 
habe inzwischen alle Permutationen von Polynomen und Initialwerten 
durchprobiert...

Flo schrieb:
> Nur CRC8 mit Dallas/Maxim Polynom nicht :-)

Das scheint es tatsächlich zu sein... :-) ... Nun muss ich erst einmal 
Ursachenforschung betreiben, warum ich nicht selbst darauf gekommen 
bin.... ;-)

Vielen Dank!

Vielen Dank, Flo!
Irgendwo hatte sich wohl in meine CRC-Berechnung ein Fehler 
eingeschlichen. (ich denke mal, falsche Bit-Order), aber es lässt sich 
jetzt nicht mehr genau sagen... Egal.

Um diesen Thread ordentlich abzuschließen, hier die Zusammenfassung:

- Die CRC wird über den kompletten Frame ohne STX und ETX berechnet.
- Es wird das Dallas/Maxim Polynom (DOW) verwendet.
- Der folgende Code berechnet die richtige CRC:

1

    public class Crc

2

    {

3

        public static byte Calc(byte[] data)

4

        {

5

            byte crc = 0;

6

            byte inbyte;

7

            byte mix;

8

9

            for (byte i = 0; i < data.Length; i++)

10

            {

11

                inbyte = data[i];

12

                for (byte j = 0; j < 8; j++)

13

                {

14

                    mix = (byte)((crc ^ inbyte) & 0x01);

15

                    crc >>= 1;

16

                    if (mix != 0)

17

                        crc ^= 0x8C;

18

                    inbyte >>= 1;

19

                }

20

            }

21

            return crc;

22

        }

23

    }

Vielen Dank auch an alle anderen, die sich ebenfalls beteiligt haben!