Skocz do zawartości

[Bascom] CRC32 z sumy wartości wyrazów 0...255


mesmariusz

Pomocna odpowiedź

Witam. Poniższy program oblicza sumę kolejnych wyrazów od 0 do 255, a następnie wylicza CRC32 z tej sumy.

#include <boost/crc.hpp>
#include <boost/lexical_cast.hpp>
#include <string>
#include <iostream>
#include <algorithm>

int main()
{
  int licznik = 0;
  int suma = 0;

  for ( licznik = 0; licznik <= 255; licznik++ )
   {
       suma = suma + licznik ;
       std::cout << "Wyraz: " << licznik << " --> Suma: " << suma << std::endl;

   }

  std::string str = boost::lexical_cast<std::string>(suma);
  boost::crc_32_type crc32;
  crc32 = std::for_each(str.begin(), str.end(), crc32);
  std::cout << "CRC32: " << crc32() << std::endl;
  system( "PAUSE" );
}

Wynik działania jest następujący:

http://pastebin.com/cErnR8K6

Chciałbym podobny efekt uzyskać w języku BASCOM AVR. Znajdzie się ktoś, kto pomoże?

Dodam, że w języku BASCOM AVR istnieje gotowa funkcja Crc32(), ale to coś, co wylicza do niczego się nie nadaje (nie do końca wiadomo, co wylicza, w każdym razie wyniki się nie pokrywają).

Dziękuję

Link do komentarza
Share on other sites

Przede wszystkim liczenie sumy ciągu arytmetycznego przez sumowanie kolejnych wyrazów to robi się w podstawówce i to tylko przez co mniej lotne dzieciaki. Ludzie znają lepszy sposób chyba od czasów Archimedesa:

http://matematyka.pisz.pl/strona/264.html

Po drugie CRC to zwykłe dzielenie wielomianów. Nie ma czegoś takiego jak nie nadające się wyniki. Nie wiesz tylko jakiego wielomianu BASCOM używa, może akurat dobrego tylko niestandardowego, innego niż skądinąd rewelacyjna biblioteka boost. Może to Ci pomoże:

http://www.hackersdelight.org/crc.pdf

Masz tu trochę teorii (przeczytaj, warto), ale i algorytm standardowego CRC32 plus wielomiany do typowych 8- i 16-bitowych. Jeśli pisałeś coś w BASCOMie, to sobie poradzisz.

Po co masz liczyć wielomian aż 32-bitowy z tak małej porcji informacji jak liczba 16-bitowa? Może w zadaniu było policzenie CRC32 dla całego ciągu (np. przesyłanych) liczb 0-255, a nie tylko ich sumy? To miałoby sens.

Link do komentarza
Share on other sites

CRC32 nie ma jednej słusznej definicji. Spójrz w opis użytej przez Ciebie funkcji w C++ jaki wielomian wykorzystuje do obliczenia CRC32 i wtedy zaimplementuj to tak samo.

Na necie są różne skrypty javascript itd. które pozwalają Tobie wybrać wielomian i policzyć z tego CRC32. W ten sposób łatwo sprawdzisz czy masz dobry wielomian.

Link do komentarza
Share on other sites

Chodzi o to, że to co wylicza c++ z boost jest zgodne z tym, co zwracają kalkulatory online (np. http://www.lammertbies.nl/comm/info/crc-calculation.html czy https://www.tools4noobs.com/online_php_functions/crc32/ )

To co oblicza Bascom (wynik CRC32) nie wiadomo jak działa. To co zwraca ta funkcja jest różne od tego co zwracają kalkulatory online czy C++ z biblioteką boost (więc nie mogę funkcji wbudowanej w Bascom-a użyć, bo to co policzy się po stronie uC nie będzie zgodne z tym, co policzy się na PC). Z dokumentacji Bascom-a do funkcji crc32() też niewiele wynika. Wszystko wskazuje na to, że musiałbym (w Bascom-ie) taką funkcję napisać sam. Problem w tym, że na prawdę nie chcę w tą całą teorię się zagłębiać (kiedyś poświęciłem na to 2 dni, ale jakoś nie chce to do mnie przemówić). Nie czuję tematu na tyle mocno, by go jeszcze implementować w jakimś rozwiązaniu.

Na potwierdzenie wklejam materiały, z których korzystałem:

http://forum.atnel.pl/post42077.html

http://forum.atnel.pl/topic3556.html

Jestem layouterem pracującym w korporacji od ośmiu do kilkunastu godzina na dobę, w domu 2 dzieci, żona, remonty i tysiąc innych spraw na głowie - zwyczajnie nie mam w tych warunkach serca do wyższej matematyki. Szukam rozwiązania. Sprawdzonego, działającego. Takiego, które dałoby się bezboleśnie zaimplementować.

Potrzebuję przesyłać 256 bajtowe bloki danych (chcę sobie napisać bootloader dla AVR 644P) i sprawdzić ich poprawność po stronie odbiornika (mikrokontrolera) przed zapisaniem ich do pamięci flash (pamięć mikrokontrolera zapisywana jest stronami - w jednym kroku zapisywana jest cała strona (256 słów) do pamięci flash - a chciałbym, się upewnić czy dane są poprawne stąd potrzeba wykonania CRC i decyzji o zapisie lub retransmisji).

Samą procedurę selfprogramingu ogarnąłem działa. Zapisuję sobie flash bezpośrednio z mikrokontrolera (tyle, że póki co, zamiast autentycznego programu jako słowa na stronie pamięci zapisuję kolejne wartości).

Teraz chciałbym zadbać o niezawodność / kontrolę CRC i wreszcie zacząć zapisywać do pamięci flash ATmega644P prawdziwy firmware.

Proszę o pomoc, ponieważ wiem, że nie mam warunków by zająć się tym zupełnie samemu (będzie to czekało na mnie kolejne miesiące albo i dłużej). Z waszą pomocą być może uda mi się ruszyć z miejsca nieco szybciej.

Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

To ja czegoś nie rozumiem. Jesteś dorosłym człowiekiem, masz wykształcenie techniczne i nawet pracujesz w branży. Masz dużo zajęć - jak każdy posiadający dom i rodzinę - to normalne. I na szczęście masz też swoje hobby. Piszesz sobie jakieś kodziki na małe AVR. To też jest super, trzeba mieć jakś odskocznię żeby nie zwariować i od czasu do czasu zresetować mózg. Niestety utknąłeś na poziomie BASCOM - współczujemy, ale to nie jest sytuacja permanentna. Zawsze możesz nauczyć się innego języka programowania jeśli ten Cię ogranicza - a wyraźnie tak jest. Hobby to jest przyjemność i pasja. A Ty nam tu piszesz, że nie masz czasu i chęci zagłębiać się w swoje zainteresowania i żeby napisać Ci funkcję CRC, chociaż dostałeś jakieś gotowce w C i masz na talerzu całą teorię. Co więcej, jako człowiek z branży wiesz na pewno, że w sieci można znaleźć gotowe wzorce takich funkcji w stu różnych językach programowania. Wymyśliłeś sobie napisanie bootloadera? Super - jest tego pełno, ale Ty masz własny - Twój wybór, dziwimy się, ale trudno. CRC Cię przerasta? To zrób arytmetyczną 32-bitową sumę kontrolną lub XOR - słabsze, ale też zabezpieczają. Może przesyłaj dane w formacie IntelHex? Znakowy więc ponad 2x wolniejszy niż binarny, ale dzięki wieloletniemu standardowi generuje go mnóstwo programów (także bez problemu sam napiszesz generator i parser) a wbudowane sumy i sztywny format rekordu także są niezłym zabezpieczeniem. Jeżeli korzystasz z portu RS232, to dodaj bit parzystości do przesyłanych bajtów i sprawdzaj wszystkie flagi błędów UARTa - on sam potrafi wykryć parę ciekawych problemów z transmisją. Po prostu myśl a zobaczysz piękno, czyż właśnie to nie jest esencją naszych pasji? Nie chce Ci się poświęcić dwóch dni na funkcję której potrzebujesz? 🤯

"Proszę o pomoc, ponieważ wiem, że nie mam warunków by zająć się tym zupełnie samemu (będzie to czekało na mnie kolejne miesiące albo i dłużej)."

No to będzie czekało. Nam się nie spieszy i nie zależy nam, by Twój program miał lepsze kontrole. Nikt na niego nie czeka, a jeśli chcesz mieć coś zrobione inaczej niż jest teraz, zrób to.. Tak to działa. A może ktoś ma napisać BASCOMowe CRC32 za Ciebie? WTF? Skąd Ty się chłopie urwałeś, żeby prosić o pomoc z takiego powodu?

A może robisz to za pieniądze i robota Cię przerosła? Bo jeśli jest to propozycja pracy i chcesz się podzielić zarobkami, to nie ten dział.

Link do komentarza
Share on other sites

No to będzie czekało, świat się z tego powodu nie skończy. Może kiedyś ruszę z tematem (po prostu fajnie byłoby dokończyć co się kiedyś zaczęło). Może rzeczywiście nie ma sensu na siłę robić tego w Bascomie, w końcu wsad i bootloader to dwie niezależne sprawy. Nie lubię, kiedy ktoś mnie ocenia, dorabia jakieś durne teorie pisane na kolanie. Nie znasz, człowieka, nie pisz. Nie pastw się nad nim, tak jak i on nie pastwi się nad tobą. Nie masz ochoty pomóc, powiedz, że nie pomożesz. Tłumaczyć się nie potrzebujesz. Ale wiadra pomyj na tego kogoś również wylewać nie musisz.

Link do komentarza
Share on other sites

"Może kiedyś ruszę z tematem.."

Super, napisz gdy napotkasz problemy w implementacji. Chętnie pomożemy. Nawet w BASCOMie 🙂 Ale coś zrób.

Nikt nie lubi ocen, szczególnie negatywnych - to naturalne - ja też nie (choć wyrosłem z etapu głębokiego przejmowania się nimi), ale gdzie takie widzisz w moim poście? Nie piszę przecież, że jesteś leniem, spryciarzem czy kosmitą. Ja tylko nie rozumiem Twojego nastawienia do własnego hobby albo może specyficznego pojmowaniu idei Forum internetowego.

Pomyj?? Chyba lepszy jest jeden zimny prysznic i wychodzisz zdrowy (jeśli tylko wyciągniesz wnioski i umiesz na siebie spojrzeć z dystansu) niż takie naiwne, ciepłe kluchy jakie zaprezentowałeś. Tu chłopaki kończący ledwo 15 lat mają w sobie więcej iskry i zapału niż Ty. Może kluczem w tej sytuacji jest przemyślana odpowiedź na dość osobiste pytanie: po co to robię? Nie musisz odpisywać 🙂

Link do komentarza
Share on other sites

Kiedy miałem 15 lat też miałem "iskrę". Teraz co najwyżej marzy mi się zamknięcie kilku starych tematów. Trochę za stary jestem na "zimne prysznice". Ale dziękuję za dobre chęci. Implementacja czegoś, co się dobrze rozumie, to pikuś. Nie sądzę bym na takim etapie miał jakieś problemy.

Link do komentarza
Share on other sites

Liczenie CRC z wartości sumy wyrazów jest według mnie średnio trafionym pomysłem. Równie dobrze można by przesyłać tą sumę (albo lepiej, wyliczyć ją tak jak to jest w wspomnianym wyżej IntelHex), i na jej podstawie weryfikować poprawność danych.

Link do komentarza
Share on other sites

Liczenie CRC z wartości sumy wyrazów jest według mnie średnio trafionym pomysłem. Równie dobrze można by przesyłać tą sumę (albo lepiej, wyliczyć ją tak jak to jest w wspomnianym wyżej IntelHex), i na jej podstawie weryfikować poprawność danych.

Fajnie jest, kiedy kod bootloadera zajmuje minimum pamięci (generalnie bootloader zajmuje flash, który mógłby być przeznaczony na kod programu docelowego). Im mniejszy bootloader, tym lepiej. Dlatego jego funkcjonalność chciałbym ograniczyć do minimum. Bootloader ma umieć odebrać i rozpoznać kody sterujące (PC mówi mikrokontrolerowi jakie dane wyśle, m. in. która to strona pamięci) oraz 256 bajtowe serie danych (bo strona pamięci tego mikrokontrolera mieści 128 dwu bajtowych słów). Seria danych w postaci kolejnych bajtów ładuje bufor tymczasowy, ostatecznie bootloader ma sprawdzić poprawność danych, które trafiły do bufora i podjąć decyzję o zapisie tak załadowanego bufora do pamięci flash lub o retransmisji całej strony (256 bajtów). Wydaje mi się, że w tym celu należy zsumować wszystkie otrzymane bajty i policzyć CRC z tej wartości, a następnie porównać z policzoną w analogiczny sposób sumą CRC przez aplikację na PC). Suma obliczona przez aplikację na PC z 256 bajtów danych do wysłania, wysłana na końcu jako informacja nadmiarowa powinna zgadzać się z sumą CRC obliczoną przez bootloader po odebraniu tej serii danych. Zapis strony do flash wykonywany jest pojedynczą instrukcją maszynową. Wszystkie czynności należy powtórzyć dla pozostałych stron. W tym mikrokontrolerze jest ich 256.

Widać więc, że nie ma tu mowy o przesłaniu całości kodu (czy to IntelHex, czy to bin) do jakiegoś tymczasowego bufora (w końcu mamy do czynienia z mikrokontrolerem z ograniczonymi zasobami, a nie z drugim PC). Można by ewentualnie wysyłać mniejsze porcje danych i częściej wysyłać sumy kontrolne (256 bajtową stronę pamięci podzielić na mniejsze porcje) ale to raczej tylko zwiększy ilość nadmiarowych danych a tym samym czas programowania. W przypadku wykrycia błędu trzeba będzie przesłać ponownie aż 256 bajtów (całą stronę) ale zakładając, że błędy wystąpią rzadko, nie powinno okazać się to nazbyt uciążliwe.

Tak ja to widzę. Tak widziałem realizowane przykłady (np. ten z MCS). Tak też to działa na logikę biorąc po przeczytaniu i dogłębnym przepracowaniu dokumentacji Atmela ( http://www.atmel.com/images/doc1644.pdf ). Nota Atmela nie sugeruje sposobu kodowania CRC - zostawia pole do popisu programiście. Tym razem jednak padło na "programistę" nie mającego wielkiej wiedzy czy umiejętności w zakresie CRC (mnie).

Jeśli piszę nieprawdę (zaprezentowaną filozofię kodowania CRC należałoby w tym przypadku zmienić / poprawić) to ja się nie kłócę - przyjmuję postawę pilnego ucznia. Być może, jak ktoś zauważył CRC32 nie jest potrzebne (a może nawet nie jest wskazane?). Byś może lepiej zastosować CRC16 albo CRC8? Jeśli tak, to słucham z wielką uwagą. To dla mnie grzązki, niełatwy temat.

Przepraszam, jeśli kogoś irytuję swoją niewiedzą, no niestety nie jest kompletna. Jest, jak jest. W tej materii doświadczeń mi brak. Ale zadanie z samego bootloadera (zwanego przez inżynierów z Atmela "selfprograming") odrobiłem w całości, ślęcząc długo nad notą, i doprowadzając finalnie do tego, że potrafię teraz zapisać flash z poziomu bootloadera (jak, na razie kolejnymi wartościami, ale na tym etapie było dla mnie ważne to, bym nauczył się wrzucać wartości które chcę, pod adresy które chcę, na konkretnych stronach). I temat też nie był łatwy. Ale to jest już za mną. Zadanie odrobione. Być może (paradoksalnie) posługiwanie się CRC jest nawet prostsze niż obsługa bootloadera (wcale bym się nie zdziwił). Ale jednak pozostaje zadaniem, przez które trudno mi przejść. Z różnych powodów. Tych najbardziej trywialnych również (i wcale nie chodzi o lenistwo... ;-/ ).

Link do komentarza
Share on other sites

To może zacznijmy od początku. Wiemy już co chcesz zabezpieczać, jak rozumiem są to dane (wszystko jedno co niosą) dla programu bootloadera, który wpisze je do pamięci FLASH procesora. Pytania:

1. Przez jakie medium chcesz to przesyłać? Od tego zależy jaką kontrolę poprawności możesz i powinieneś zastosować. Czy to jest USB, RS232, radio czy jeszcze coś innego.

2. Jak wygląda Twój system? Gdzie te dane powstają i w jaki sposób trafiają do bootloadera? Który odcinek tej drogi chcesz zabezpieczać i przed czym?

3. Jakie zastosowanie ma lub może mieć ten system? Czy to jest zabawka, narzędzie dla hobbystów czy jakiś prawdziwy sprzęt np. komercyjny?

Projekt protokołu komunikacyjnego nie jest decyzją 5-sekundową, bo istnieje duża liczba czynników, wymagań i ograniczeń. Masz ograniczenia i specyfikę samego kanału komunikacyjnego, układów interfejsowych, wymagania na moc obliczeniową i pasmo czyli szybkość przesyłania danych. Na czym Ci zależy? Na czasie? Na pamięci? Na wykrywaniu ilu błędnych bitów? Jak rozłożonych? Skoro protokół działa w obecnej formie, dlaczego uważasz, że powinieneś zrobić kontrolę a jeśli już, to dlaczego nie próbowałeś prostszych rozwiązań? Dostałeś już tu kilka nazw, poczytałeś o tym? Znajdź też coś o tzw. odległości Hamminga (Hamming distance) - to kluczowa tutaj definicja i od tego de facto zależy jakiej kontroli powinieneś użyć. Poczytaj ogólnie o kodach kontrolnych i/lub korekcyjnych. Może zaczniesz mówić językiem, którego tutaj należy używać, bo inaczej to będzie zgadywanie, robienie na czuja lub sztuka dla sztuki.

Link do komentarza
Share on other sites

1. Przez jakie medium chcesz to przesyłać? Od tego zależy jaką kontrolę poprawności możesz i powinieneś zastosować. Czy to jest USB, RS232, radio czy jeszcze coś innego.

Jest to kilka urządzeń połączonych w sieci RS485, bez sterowania kierunkiem transmisji (pojedynczy MAX485). Komunikacja half-dupleks w konfiguracji master-slave. Urządzenia mają swoje adresy, na zapytanie odpowiada jedno wybrane urządzenie. Wszystkie urządzenia pracują u mnie w domu (domek, własność). Nie muszę więc spełniać żadnych wymogów certyfikacyjnych. Chętnie rozwijałbym tę swoją sieć (dopisywał nowe funkcjonalności) ale ponieważ urządzenia muszą ze sobą dobrze współpracować, zmiana firmware-u wiąże się z koniecznością przeprogramowania kilku urządzeń (bieganiem z programatorem ISP po całym mieszkaniu). Warunki (czasowe / rodzinne / pracowe / materialne) są takie jakie są. Po pewnym czasie dotarło do mnie, że w obecnej formie nie jestem w stanie rozwijać projektu. Przestałem więc się łudzić, że tą drogą jest szansa coś dalej robić. Porzuciłem prace nad systemem, a raczej postawiłem sam sobie ultimatum: "chłopie, albo zaimplementujesz bootloader i zdalne programowanie, albo nici z czegokolwiek". I rzeczywiście od tamtej pory (już chyba 2 lata) nie rozwinąłem żadnej innej funkcjonalności. Zamiast tego cały czas (strzępki czasu, co kilka tygodni) poświęciłem na zgłębienie tematu bootloadera. Teraz przyszła kolej na CRC, który nie ukrywam zdołował mnie na tyle, że najchętniej użyłbym gotowych bibliotek, działających tak samo po stronie uC jak i PC (najwyraźniej muszę pożegnać się z Bascomem, bo na jego systemową bibliotekę CRC liczyć nie mogę).

Padło pytanie, dlaczego w ogóle idę w CRC, dlaczego nie zrobię bez weryfikacji transmisji. Ano dlatego, że po pierwsze, tak mnie uczono, po drugie wszędzie mi tak piszą, że bez CRC ani rusz / CRC to podstawa. I wierzę. Dlatego bez CRC nawet nie próbowałem. Co prawda cała obecna transmisja pomiędzy urządzeniami lata bez CRC i wszystko działa. Ale czy za każdym razem i zawsze w 100 procentach za pierwszym razem - tu głowy nie dam. Teraz już nie idzie o wykonywanie zdalnych poleceń, ale o jednorazowe przesłanie dużej ilości danych i zaprogramowanie tymi danymi mikrokontrolera. Jeśli zaprogramuję procka przekłamanym wsadem, to co prawda tragedii nie będzie (bootloader nie jest nadpisywany) ale prawdopodobnie nie zaloguję się już wtedy zdalnie do urządzenia a więc nie będę mógł wykonać na nim zdalnej akcji, która zrealizuje skok do bootloadera. Innymi słowy znów będę się musiał fizycznie zjawić w pobliżu urządzenia, a przecież tego właśnie próbuję uniknąć. Jeśli bootloader ruszy, i zdalne programowanie stanie się rzeczywistością, dopiero wtedy będę miał jakiekolwiek szanse zabrać się za dalszy rozwój projektu. Ów kilkukrotnie wspomniany projekt to nic ani tajnego, ani mega błyskotliwego. Ot sterowanie urządzeniami elektrycznymi w domu. Taka tam ambicja z dzieciństwa.

2. Jak wygląda Twój system? Gdzie te dane powstają i w jaki sposób trafiają do bootloadera? Który odcinek tej drogi chcesz zabezpieczać i przed czym?

3. Jakie zastosowanie ma lub może mieć ten system? Czy to jest zabawka, narzędzie dla hobbystów czy jakiś prawdziwy sprzęt np. komercyjny?

Zdaje się, że udało mi się odpowiedzieć wyżej.

Na czym Ci zależy? Na czasie? Na pamięci?

Zależy mi na w miarę szybkim oraz pewnym (stabilnym) programowaniu 64kB flash mikrokontrolera. Obecnie zwykła transmisja hula na 4800 baud, i nie sądzę, by szybsza była potrzebna.

Na wykrywaniu ilu błędnych bitów? Jak rozłożonych? Skoro protokół działa w obecnej formie, dlaczego uważasz, że powinieneś zrobić kontrolę a jeśli już, to dlaczego nie próbowałeś prostszych rozwiązań? Dostałeś już tu kilka nazw, poczytałeś o tym? Znajdź też coś o tzw. odległości Hamminga (Hamming distance) - to kluczowa tutaj definicja i od tego de facto zależy jakiej kontroli powinieneś użyć. Poczytaj ogólnie o kodach kontrolnych i/lub korekcyjnych. Może zaczniesz mówić językiem, którego tutaj należy używać, bo inaczej to będzie zgadywanie, robienie na czuja lub sztuka dla sztuki.

Na część pytań odpowiedziałem wcześniej. Oczywiście cenię sobie wskazane rozwiązania, i doczytam zgodnie z sugestiami. Na pytania: "Na wykrywaniu ilu błędnych bitów? Jak rozłożonych?" pozostaje mi odpowiedzieć tylko: "pojęcia nie mam", chcę tylko by mikrokontroler pewnie się programował, bym co chwila nie zaliczał wpadek, że programowanie poszło "w krzaki" i urządzenie po upgrade "znowu nie wstaje".

Nie wiem, na ile to, co napisałem wyznacza horyzont, ile nowego wnosi, jedno jest pewne bardzo cenię sobie każdą pomocną sugestię.

Link do komentarza
Share on other sites

OK, to już coś wiadomo. Skoro coś tam jednak o teletransmisji słyszałeś to na pewno także pamiętasz, że organizacja takich systemów jest wielopoziomowa. Są na to normy i tony opracowań a najbardziej znanym i obowiązującym standardem jest tzw. Model OSI. Piszę o tym by przypomnieć Ci, że to co chcesz teraz zrobić jest wychodzeniem przed orkiestrę jeśli nie zrobiłeś wszystkiego co mogłeś zdziałać wcześniej (niżej wg modelu OSI). Chodzi mi w szczególności o warstwy: fizyczną i łącza danych.

Skoro już wiemy, że masz UART na RS485 (gratuluję tego domowego systemu, naprawdę) to napisz nam jak tutaj zadbałeś o spójność danych. UART przesyła bajt danych, ale oprócz tego (jak już wspomniałem gdzieś wcześniej) może robić parę innych pożytecznych rzeczy. Przede wszystkim nadajnik może opatrywać wysyłane bajty w bit parzystości. Odbiornik może (i powinien) ją sprawdzać - masz do tego specjalną flagę błędu. Czy obsługujesz parzystość? To podstawowa kontrola poprawności przesyłanych bajtów, masz ją zupełnie za darmo i grzechem jest z tego nie skorzystać. Kolejna fajna właściwość UARTa to sztywny format ramki. Oprócz 8/9 bitów informacyjnych (8 danych + ew.parzystość) nadajnik wysyła tzw. bit startu i 1 lub 2 bity stopu. Odbiornik może (a u Ciebie powinien) to sprawdzać. Gdzieś w rejestrach UARTa masz kolejną flagę - jej ustawienie oznacza, że odbiornik wykrył tzw. błąd ramki czyli brak bitu stopu. Oznacza to jakąś masakrę na linii przesyłowej co praktycznie z definicji powinno wykluczać odebrane dane jako coś sensownego. Taka kaszana w torze przesyłowym może bardzo łatwo zajść właśnie w RS485, gdy dwóch na raz próbuje nadawać.

Jeżeli to już za Tobą, masz kolejną warstwę - łącza danych - czyli przesyłane ramki. Opowiedz nam o nich. Jak je skonstruowałeś, jak wyglądają ich pola i czy strona odbiorcza ma szansę już teraz - bez CRC - zauważyć, że ramka nie jest pełna, przyszła w części lub w podobny sposób jest uszkodzona. Dopiero gdy tak podstawowe rzeczy jak nagłówek ramki, licznik długości, pole danych i znacznik końca są prawidłowe, można zabierać się za test samej zawartości poprzez liczenie jakiegoś kodu kontrolnego. Czy robisz to wszystko w swoich programach?

BTW: Kiepsko, że nie zadbałeś o jakiś sprzętowy mechanizm wymuszania na wszystkich węzłach wejścia w stan RESET i startu bootloadera. Wystarczyło np. sprzętowo wykrywać stan BREAK na czas dłuższy niż ileśtam ms. Taka sytuacja normalnie nigdy nie ma miejsca, a miałbyś wygodny sposób sprowadzania porządku w systemie i restartu każdego węzła. Teraz musisz wierzyć, że napisany program jest przynajmniej na tle dobry, by pozwolił na wejście do bootloadera. Marne to rozwiązanie.

BTW2: CRC32 to o wiele za silny mechanizm w Twoim przypadku. O ile pamiętam zapewnia on odległość Hamminga na poziomie 6 dla strumieni danych do kilkunastu kilobitów. Twoje 256 bajtów (2Kbity) spokojnie zabezpieczysz dużo szybszym i krótszym CRC16 a nawet 16-bitową sumą. Ale o tym warto myśleć dopiero gdy będziesz całkowicie nadzorował poprawność pracy samego odbiornika UART i składnię ramek na wyższej warstwie.

Link do komentarza
Share on other sites

mesmariusz, jeśli masz czas i chęci to możesz podjąć się studiowania telekomunikacji. Wtedy dowiesz się wszystkiego o kodowaniach, modelu OSI/ISO, itd. Oczywiście fajna zabawa, ale absolutnie nie niezbędna do tego co robisz. Skoro chcesz po prostu napisać bootloader, najlepiej zobacz jak to robią inni. Standardem jest AVRdude i protokół, STK500v2, jego opis znajdziesz tutaj: http://www.atmel.com/images/doc2591.pdf Suma kontrolna znacznie łatwiejsza do obliczenia niż CRC32 - zwykła suma XOR wszystkich bajtów. Skoro w ten protokół działa i jest powszechnie używany, to może nie musisz wynajdywać własnej wersji koła? Co więcej po stronie PC znajdziesz już gotowy program (wspomniany avrdude na przykład). Możesz spokojnie zostać przy bascomie, ale gdybyś jednak chciał pobawić się w C to masz do dyspozycji gotowe bootloader-y, jak chociażby https://github.com/Optiboot/optiboot

Link do komentarza
Share on other sites

mesmariusz, jeśli masz czas i chęci to możesz podjąć się studiowania telekomunikacji. Wtedy dowiesz się wszystkiego o kodowaniach, modelu OSI/ISO, itd. Oczywiście fajna zabawa, ale absolutnie nie niezbędna do tego co robisz. Skoro chcesz po prostu napisać bootloader, najlepiej zobacz jak to robią inni. Standardem jest AVRdude i protokół, STK500v2, jego opis znajdziesz tutaj: http://www.atmel.com/images/doc2591.pdf Suma kontrolna znacznie łatwiejsza do obliczenia niż CRC32 - zwykła suma XOR wszystkich bajtów. Skoro w ten protokół działa i jest powszechnie używany, to może nie musisz wynajdywać własnej wersji koła? Co więcej po stronie PC znajdziesz już gotowy program (wspomniany avrdude na przykład). Możesz spokojnie zostać przy bascomie, ale gdybyś jednak chciał pobawić się w C to masz do dyspozycji gotowe bootloader-y, jak chociażby https://github.com/Optiboot/optiboot

STK500, podobnie jak AVRdude kojarzyły mi się zawsze z ISP, czyli programowaniem szeregowym. Z drugiej strony originalny STK500 (zaimplementowany na płytce rozwojowej Atmela, na jakimś bootloaderze rzeczywiście bazował).

Na początku (zanim zabrałem się za naukę bootloadera od podstaw) założyłem, że "a, przecież wystarczy podejrzeć przykład z Bascoma i wszystko stanie się jasne".

http://www.mcselec.com/index.php?option=com_content&task=view&id=159

http://www.mcselec.com/index.php?option=com_docman&task=doc_download&gid=153&Itemid=54

http://avrhelp.mcselec.com/index.html?mcsbootloader.htm

Analizowałem kod dostępny pod adresem:

http://avrhelp.mcselec.com/index.html?mcsbootloader.htm

Nie stało się jasne. Przeciwnie. Rodziło się coraz więcej niejasności. Po wielu zmarnowanych godzinach domyślania się "co autor miał na myśli" zrozumiałem, że łatwiej będzie od podstaw poznać zasady działania i całą teorię bootloadera AVR, i napisać go od początku samemu. Tak też się stało.

Co do cudzych bootloaderów... Rozważałem np. ten: https://www.chip45.com/avr_bootloader_atmega_xmega_chip45boot2.php

Jest jednak powód dla którego obawiałem / obawiam się zdać na "cudzy" bootloader. Mam do czynienia z siecią RS485. Co prawda nie kontroluję kierunku transmisji (przypomnienie: half-duplex), zamiast tego nadajnik po skończeniu nadawania natychmiast (automatycznie) przełącza się w tryb odbioru. Założyłem, że wcześniej czy później będę musiał rozważyć ingerencję w sprzęt i obsłużyć takim bootloaderem pin obsługujący kierunek transmisji. Gotowych bootloaderów wspierających RS485 (sterowanie kierunkiem transmisji) nie ma już tak wiele. A takiego, który pozwoliłby na ustawienie / skonfigurowanie dowolnego pinu mikrokontrolera, jako pin sterujący kierunkiem transmisji zdaje się, że nie ma żadnego.

Konkluzja jest taka, że podejrzenie czyjegoś rozwiązania (i pełne jego zrozumienie) wcale nie musi być prostsze niż podjęcie się tematu od podstaw. Czytanie uniwersalnego, zawiłego kodu z zaimplementowanymi "jakimiś" mechanizmami CRC może okazać się drogą przez mękę i wieść donikąd. W przypadku przykładu http://avrhelp.mcselec.com/index.html?mcsbootloader.htm na stronie http://wiki.mcselec.com/bavr/MCS_Bootloader dowiadujemy się, że w tym bootloaderze mamy do czynienia z protokołem x-modem, co dużo wyjaśnia (dlaczego strona pamięci jest tam dzielona na kolejne, jeszcze mniejsze kawałki: https://pl.wikipedia.org/wiki/XMODEM ). Ale i przyjęcie tego faktu, i próba zrozumienia kodu samplowego bez znajomości głębszej teorii dotyczącej bootloadera AVR ( http://www.atmel.com/images/doc1644.pdf ) zawiodła mnie początkowo donikąd.

W którymś momencie stwierdziłem, że może kolejne dzielenie stron na 128 bajtowe bloki (XMODEM) może być zbędną komplikacją, że może warto zamiast 128 bajtowych bloków wysłać do mikrokontrolera całą 256 bajtową stronę i na takim "bloku" wykonać jakieś podstawowe operacje CRC (tudzież sum kontrolnych, xorowania itp.) - stąd też pomysł, by na siłę nie iść w gotowe rozwiązania, by sobie skomplikowany temat uprościć. Po prostu nabrałem przekonania, że brnięcie na siłę w czyjeś rozwiązania wcale nie musi niczego ułatwiać, może sprawę nieźle skomplikować. Być może to błędne przekonanie.

Link do komentarza
Share on other sites

Bądź aktywny - zaloguj się lub utwórz konto!

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto w ~20 sekund!

Zarejestruj nowe konto, to proste!

Zarejestruj się »

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się »
×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.