Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[ Bascom ] Coś w rodzaju CRC dla przesyłanych stringów

01 Cze 2008 13:13 2419 4
  • Poziom 36  
    Witam.

    Buduję sobie urządzenia połączone ze sobą interfejsem RS485. Urządzenia przesyłają pomiędzy sobą informacje całymi stringami. Chciałbym zrobić coś w rodzaju CRC w celu wykrywania i eliminacji błędów transmisji.


    Co pomiędzy sobą przesyłają urządzenia?

    Urządzenie A wysyła do urządzenia B kilka informacji (stringów) kolejno po sobie. Na podstawie tych informacji urządzenie B składa sobie pewien nowy string (urządzenie A oprócz tego wysłało kilka innych informacji, ale chodzi o sprawdzenie poprawności tego najważniejszego stringu).


    Chcę to zrobić, w taki sposób, że:

    1. urządzenie A wysyła 4 stringi do urządzenia B
    2. urządzenie B odbiera stringi i tworzy na ich podstawie pewne słowo kodowe, np. 001.002.003.004

    (nie wiemy jednak czy ostateczna postać wygenerowanego słowa kodowego nie została przekłamana błędami transmisji, trzeba sprawdzić, czy słowo kodowe wygenerowane po stronie urządzania A i B są identyczne), dlatego:

    3. urządzenie B wysyła do urządzenia A żądanie przesłania kodu w rodzaju "CRCA" wygenerowanego przez urządzenie A na podstawie wysłanego przezeń wcześniej kodu.

    4. Urządzenie A odsyła wygenerowany przez siebie kod "CRCA".
    5. Urządzenie B na podstawie utworzonego przez siebie słowa kodowego, generuje kod "CRCB" i porównuje go z odebranym "CRCA".

    Pytanie moje jest takie. Jak na podstawie stringu (składnią przypominającego adres IP), np. 100.101.102.103 wygenerować kod "CRCA" o długości najlepiej 1 bajta (a więc liczbę od 0 do 255), która z wystarczającym poziomem ufności zaświadczy o tym, że stringi wysłany i odebrany (jeśli na ich podstawie generuje się to samo CRCA = CRCB) są takie same?

    Według jakiego algorytmu generować kody w rodzaju "CRC" dla stringów postaci: a.b.c.d gdzie liczby a, b, c, d są bajtami?
  • Poziom 28  
    Przeczytałem Twojego posta i prawie go zrozumiałem (tak mi się przynajmniej wydaje). Mam tylko jedno pytanie: Czy transmisja pomiędzy A i B ma być szyfrowana?
    Czy chodzi Ci tylko o zabezpieczenie ze względu na błędy transmisji?
    Moim skormnym zdaniem powinieneś na końcu każdego przesyłanego z A do B stringu wysyłać sumę kontrolną CRC (jedno lub jak chcesz jeszcze większego bezpieczeństwa to dwu bajtową). Akurat nie wiem jak to jest z BASCOMEM ale przeważnie każdy producent uC udostępnia procedurę napisaną w ASM liczącą CRC (w asm dlatego że jednak jest to dość czasochłonna procedura).
    B odbiera string wraz z CRC obliczonym przez A, następnie liczy własne CRC i porówuje je z tym które otrzymał wraz ze stringiem.

    Dodano po 5 [minuty]:

    Zamiast CRC możesz wykorzystać prostrze algorytmy, jak XOR kolejnych bajtów i sprawdzanie UARTOWEGO bitu parzystości każdego bajtu. Połączenie tych dwóch metod daje już spore bezpieczeństwo (taka metoda wykorzystywana jest w standarcie przemysłowym) dla krótkich kilkudziesięcio bajtowych telegramów.
  • Poziom 25  
    Dokładnie tak jak kolega wyżej napisał, CRC jest czasochłonne.
    Do zabezpieczenia transmisji pod względem błędów to jak DR_DEAD napisał, bit parzystości, xor.
    Można to zrobić tak jak jest w tagach RFID UNIQUE

    Code:
    bit bit bit bit bit_parzystosci
    
    bit bit bit bit bit_parzystosci_wiersza
    bit bit bit bit bit_parzystosci_wiersza
    bit bit bit bit bit_parzystosci_wiersza
    bit bit bit bit bit_parzystosci_wiersza
    bit bit bit bit bit_parzystosci_wiersza
    bit_parzystosci_kolumn x4


    Łatwe do wykonania na polach bitowych, szybkie, i stosunkowo bezpieczne.

    pozdrawiam
  • Poziom 25  
    CRC wcale nie musi byc czasochlonne! Jezeli tak zalezy koledze na szybkosci dzialania to moze obliczyc CRC za pomoca tablicy i kilku odwolan do niej. Jest to rozwiazanie o wiele szybsze niz wyliczanie CRC "matematycznie" a jedyna wada jest taka, ze potrzeba zarezerwowac 512 bajtow na tablice w pamieci programu (CRC16).

    www.tkdami.net/~roman72/pdf/dtr/dtr_sum_ctrl.pdf

    BF
  • Poziom 36  
    Dr_DEAD napisał:
    Przeczytałem Twojego posta i prawie go zrozumiałem (tak mi się przynajmniej wydaje). Mam tylko jedno pytanie: Czy transmisja pomiędzy A i B ma być szyfrowana?

    W pewnym sensie do tego się to sprowadza - taki efekt uboczny ;-)

    W sieci jest wiele urządzeń, można powiedzieć, że tworzę zupełnie nowy protokół transmisji danych na potrzeby tej sieci.

    Dane właściwe, na przykład "kod sterujący" przesyłany pomiędzy urządzeniami, jest wydzielany z całej "ramki" zawierającej informacje, adresowe, kontrolne, parametry itp. (a nawet przesłany w kilku takich ramkach).

    Mówimy więc o kontroli na ostatniej warstwie - czy z przesłanych informacji urządzeniu B udało się wydzielić / odtworzyć właściwą informację, jaką miało przekazać urządzenia A.

    Czyli tak ogólnie w całym protokole pomijana jest zabawa z prawdziwym CRC, weryfikacji ma natomiast zostać poddana istotna informacja, którą jest string składający się z 12 cyfr i 3 kropek, np. 101.102.103.104 po stronach obu urządzeń.

    Trzeba zastosować jakiś algorytm, który miałby właściwości protekcyjne lepsze (oszczędność) niż ponowne wysłanie całego stringu i jego porównanie.

    Byłoby dobrze, gdyby poprawność 4 przesłanych bajtów (rozdzielonych kropkami) dało się sprawdzić za pomocą jednego bajtu.