Nadajnik wysyła bit po bicie wiadomość do odbiornika (np 100 bajtów = 800 bitów). W trakcie wysyłania oblicza (też bit po bicie) CRC w np rejestrze dwubajtowym. Następnie po wysłaniu w/w 800 bitów dołącza CRC jako już obliczoną zawartość rejestru dwubajtowego. Jest to więc idealna metoda przy transmisji sygnałów. Jest też metoda w której obliczane CRC "bajt po bajcie". Zrobi to więc 8 razy szybciej niż "bit po bicie". Metoda ta jest bardziej skomplikowana i wymaga użycia dużej pamięci ROM do czegoś tam. To ja się pytam. Po co ta szybkość? Po to żeby wcześniej obliczył CRC i czekał "bezprodukywnie" aż wyśle 800 bitów i dopiero potem dołączył zawartość CRC? A może metoda bajtowa używana jest do innych celów niż transmisja danych?

A może to tak należy wytłumaczyć? Metoda "bit po bicie" jest najszybsza i najlepsza, ale wymaga specjalnego "hardware'u". Jeżeli nie mamy takiej kości, to pozostaje nam tylko napisać program np w języku C. Wtedy obliczamy CRC bajt po bajcie. Tak będzie szybciej niz gdybyśmy w C obliczali bit po bicie.

Ja przyznam szczerze, że czytam to i w ogóle nie rozumiem tych wywodów o jakiejś szybkości, o "bit po bicie", o jakimś specjalnym hardware? o dużej pamięci ROM ? .... o co koledze chodzi ???? to jakieś totalnie nieporozumienie i widzę, że dalej rozwijane

Oczywiście, że CRC najczęściej oblicza się jako 8- , 16- lub 32-bitowe

nikt nigdy w życiu nie wysyła jakichś tam 800 bitów i nie oblicza CRC bit po bicie .... gdzie kolega takie rzeczy widział ? o czym tu w ogóle mowa - no chyba że ja czegoś nie wiem (też tak może być) .... ale to jakiś straszny koszmar

CRC można obliczać albo w locie i działa to ciut wolniej niż obliczanie z udziałem tablicowania, ale w większości wypadków dla prostych zastosowań i wolnych transmisji nie ma to żadnego znaczenia. Bierzesz sobie funkcje CRC8() lub CRC16() i obliczasz CRC dla swojego bufora który wysyłasz bajt po bajcie albo słowo po słowie. To tyle i tylko tyle - bez żadnych tam obliczeń crc bit po bicie na 800 bitach ...... nie wspomnę już że



100 kilobajtów to nigdy w życiu nie jest 800 bitów ... ale niech będzie , że to jakiś czeski błąd się koledze przydarzył.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

To jest właśnie obliczanie CRC "bit po bicie" ! Jeżeli Nadajnik jest wyposażony w układ obliczający CRC (taki trochę bardziej skomplikowany np 2 bajtowy rejestr przesuwny - cykliczny, nazywa się to chyba LFSR) to rejestr ten jest aktualizowany po wysłaniu każdego 1 bitu ( z tych 800 bitów). Po wysłaniu 800 bitów siedzi w nim już gotowe, obliczone CRC, które jako dodatkowe 2 bajty będą dołączone do wiadomości 800 bitowej.Już poprawiłem

No dobrze ale ten cały wątek to jakieś pytanie czy jakaś porada ? bo nijak nie mogę się połapać

co ma wspólnego to obliczanie CRC bit po bicie ? z tym wątkiem. A że niby funkcje CRC8, CRC16, CRC32 itp to nie obliczają bit po bicie ?

Jeśli kolega czegoś nie rozumie to proszę jasno zadać pytanie, ja chętnie pomogę jeśli będę w stanie .... no chyba że tu chodziło o jakąś poradę - ale jeśli tak to jaką ?

nikt nie odpisuje w tym wątku to postanowiłem coś odpowiedzieć żeby chociaż wyjaśnić o co tu chodzi ? po prostu

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

To wszystko przez ten termometr z niebieskiej książki (rozdz. 5.1.1) Zaintrygowało mnie , że w takim maleństwie o wyglądzie tranzystora, jest wykorzystana transmisja z wykrywaniem błędów poprzez wysłanie dodatkowego bajtu CRC. A ponieważ całe życie obijało mi się o uszy, że jest coś takiego jak CRC, to raz na zawsze, postanowiłem rozgryźć ten temat. Wydaje mi się że zrozumiałem "CRC w locie". Jest ono robione przez czysty hardware, i programista nawet nie zaprząta sobie głowy wykrywaniem błędów. Tzn zaprząta, ale tylko wtedy gdy hardware powie, że transmisja się nie udała.

Są też programy programy np. w C, które obliczają CRC. I tu jest robota dla programisty C. (w odróżnieniu od metody "w locie" ,gdzie CRC obliczane jest przez hardware).

Czyli są 2 metody zapobiegania błędom transmisji. Hardware'owa ("w locie") i software'owa - gdy nie ma hardware'u.
Tak jak w tym dowcipie o łapaniu szczurów - Można i tak, można i tak. Grzebałem internecie( np http://ep.com.pl/files/4641.pdf cykl pięciu artykułów), ale nikt wyraźnie tego nie podkreśla. Dlatego pytam się , czy tak jest.

no to kolega dość opacznie zrozumiał z tym CRC i nie chodzi mi tu o podstawy jego działania bo tu widać że kolega wie pewnie co i jak - tylko jeśli chodzi o ten termometr. Dlatego lepiej zawsze zadać pytanie i napisać konkretnie o co chodzi

Nawet ten jak kolega mówi układ wyglądający jak tranzystor to swego rodzaju mikrokontroler i próba wyprowadzania wywodów że tam w nim jakiś hardware coś oblicza CRC i że ja źle obliczy CRC to wtedy programista coś tam będzie musiał ....

nie nie nie nie

nie tędy droga, a sprawa posługiwania się CRC przy okazji tych czujników jest banalnie prosta....

każda transmisja tzn każda ramka zakończona jest sumą CRC, i żaden tam hardware nie informuje programisty że się coś udało czy nie udało, tylko programista ma koci obowiązek tę sumę CRC sprawdzać, a jak się ona nie zgadza to znaczy że nastąpił błąd - ale nie pomiaru tylko transmisji najczęściej. TO WSZYSTKO.

i nie ma tu nic do dociekań na temat hardwarowej czy softwerowej obsługi CRC bo to całkiem inna para kaloszy. W bibliotekach przedstawionych w książce są przy okazji przedstawione funkcje do obliczania CRC więc ma kolega wszystko pod ręką i jak chce wnikać np w szczegóły tej innej pary kaloszy - czyli jak to jest realizowane - to może sobie kolega tę funkcję przeanalizować a algorytm liczenia CRC w tych kostkach ma kolega pokazany w ich PDF'ie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]