Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
tmf napisał:Zwykle same bajty CRC też się bierze pod uwagę, bo CRC ma takie właściwości, że CRC całego bloku łacznie z bajtami zawierającymi CRC daje 0 lub 0xFF (0xFFFF).
tmf napisał:Zwykle same bajty CRC też się bierze pod uwagę, bo CRC ma takie właściwości, że CRC całego bloku łacznie z bajtami zawierającymi CRC daje 0 lub 0xFF (0xFFFF).
atom1477 napisał:tmf napisał:Zwykle same bajty CRC też się bierze pod uwagę, bo CRC ma takie właściwości, że CRC całego bloku łacznie z bajtami zawierającymi CRC daje 0 lub 0xFF (0xFFFF).
Przecież to nie miało by sensu. Jak policzysz CRC bloku wraz z dołączonym CRC tego bloku?
Musiał być policzyć CRC bloku.
Dodać CRC bloku do końca bloku.
I ponownie policzyć CRC uzyzkując wynik równy 0 albo FFFF.
I co teraz? Transmitować/zapisywać do pliku blok i zawsze stałe CRC równe 0 albo FFFF?
Dołączanie CRC do bloku i liczenie z tego CRC ma zastosowanie dopiero przy odbiorze aby sprawdzić czy nie nastąpiło przekłamanie.
__Grzegorz__ napisał:atom:
masz dane do wysłania,
dodajesz CRC i ślesz to (dane + CRC)
odbiorca odbiera wszystko i tym samym algorytmem liczy CRC dla odebranego bloku danych (dane + CRC).
Jeżeli otrzymana wartość jest stała (z góry znana), nie było błędu w transmisji i dane (już bez CRC ) można mleć dalej...
asembler napisał:To ma chyba tak dzialac ze liczymy sume kontrolną dodajemy ją na koncu, a dopiero odbiornik przelicza sume kontrolną danych wraz z sumą kontrolną i otrzymuje 0 lub -1.
