logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[Atmega32][C] Własna ramka danych

m3 26 Cze 2010 18:30 5288 30
  • #1 8234460
    m3
    Poziom 12  
    Witam, chciałbym zrealizować własną ramkę danych, ale za bardzo nie wiem jak się za to zabrać. Dużo szukałem, ale nie ma nic konkretnego. ;/ Chce w niej przesyłać dane, informacje o ilości danych, CRC i jeszcze kilka innych informacji, bit stopu i startu. Wszystkie dane będę wysyłać po UARTcie. Macie jakieś pomysły jak to zrobić?
  • #2 8234494
    _Robak_
    Poziom 33  
    Hmm bit startu i stopu? Tym zajmuje się UART co najwyżej całe bajty możesz wysyłać, ja np. korzystam z bardzo prostej ramki:
    [adres docelowy] [komenda] [ilość bajtów danych] [dane] [checksuma]
    Zamiast checksumy możesz dać dwa bajty CRC i będzie ok.
  • #3 8234509
    m3
    Poziom 12  
    No może przesadziłem z tymi bitami startu i stopu. Masz racje, można zamiast tego dać jakiś znak startu i znak stopu, każdy powtórzony 2 razy żeby nie było wątpliwości gdzie jest granica ramki.

    A pokazałbyś w jaki sposób to zakodowałeś?
  • #4 8234658
    _Robak_
    Poziom 33  
    Zakodowałeś rozumiem że chodzi o kod?;) W każdym razie wkleić go tu nie wkleję bo jest własnością firmy w której pracowałem, ale jest to tak banalne do zaimplementowania że chyba kolega powinien w parę chwil sobie poradzić;)
  • #5 8235458
    AVRowiec
    Poziom 18  
    Sklejasz jakiegoś stringa a potem znak po znaku wysyłasz...
  • #6 8235771
    markosik20
    Poziom 33  
    _Robak_ napisał:
    ..ja np. korzystam z bardzo prostej ramki:
    [adres docelowy] [komenda] [ilość bajtów danych] [dane] [checksuma]
    Zamiast checksumy możesz dać dwa bajty CRC i będzie ok.


    Dobrze jest dołączyć jeszcze [STX][.........][ETX][CR][LF] ..bo wtedy taką ramkę łatwiej analizować w odbiorniku.
  • #8 8236106
    markosik20
    Poziom 33  
    Łatwiej i szybciej :wink:.

    "Łapiąc" tylko koniec ramki mamy pewność że skoro jest koniec to i cała ramka jest w buforze i można zacząć ją analizować. W szybkich transmisjach jest to istotne (przełączamy się na inny bufor i wtedy można analizować ramkę a w tym samym czasie odbierać następną).
    Bez ustalonych znaków końca ramki nie wiemy jak długa ona będzie i sprowadza się to do tego że trzeba za każdym odebranym znakiem analizować wszystko co wcześniej odebrane.
    Ostatnio implementowałem MODBUS'a ASCII i RTU gdzie to drugie nie posiada znaczników końca ramki. Mając w sieci 10 urządzeń gdzie master obiega je wszystkie w 1sec brakowało czasu na pozostałe obliczenia ( w tym obsługa LCD).
  • #9 8236190
    tmf
    VIP Zasłużony dla elektroda
    Trudno się z tym zgodzić. Jeśli po adresie kolejnym polem jest size to z góry wiemy ile znaków jest do odebrania. Taka detekcja końca ramki jest IMHO bez sensu (albo czegoś tu nie rozumiem), bo przecież w ciągu danych mogą się znaleźć takie same znaki.
  • #10 8236331
    _Robak_
    Poziom 33  
    Tak jak pisze tmf, po to jest ilość bajtów danych, zawsze wiesz ile cała ramka ma mieć bajtów. Znak końca ramki może pokryć się z danymi i będzie klops, chyba że wiemy jaki zakres mają dane, ale to nie jest wtedy uniwersalne rozwiązanie.
  • #11 8236338
    markosik20
    Poziom 33  
    tmf napisał:
    Trudno się z tym zgodzić. Jeśli po adresie kolejnym polem jest size to z góry wiemy ile znaków jest do odebrania. Taka detekcja końca ramki jest IMHO bez sensu (albo czegoś tu nie rozumiem), bo przecież w ciągu danych mogą się znaleźć takie same znaki.


    A co jeśli te dane nie dotrą? Ile czasu przyjąć na reset liczników? Jeżeli nawet wychwycimy trzy kolejne takie same bajty oznaczające koniec ramki to przecież i tak to później jest weryfikowane i ewentualnie odrzucane.
    Jeżeli mamy dane o rozmiarze ramki to jest to jeden bajt (co z błędem tego bajtu?), łapiąc sekwencje bajtów wystarczy żeby jeden z nich był niepoprawny. Weź prostą sytuację:
    Włączasz urządzenie w sieć, urządzenie odbiera swój adres (ale jest to jakiś przypadkowy bajt), potem czyta pole size, ustawia licznik i czeka. Dane przyszły ale jednego brak więc po JAKIMŚ czasie resetuje liczniki i czeka na swój adres. Wszystko jest "cacy" dopóki ramki "lecą" z wyraźnym odstępem czasowym , bo w przypadku gdy jedna ramka "idzie" zaraz za drugą (odstęp 3.5T) to metodą eksperymentalną trzeba dopierać te czasy. I takie zsynchronizowanie urządzeń może trochę potrwać, zwłaszcza przy transmisjach liczonych w setkach kbit/sec. To wszystko jest do zrobienia i pracuje poprawnie (sęk w tym że jeżeli nasza Atmega ma dużo innych rzeczy do zrobienia to zaczyna się robić "kocioł" ).
  • #12 8236376
    _Robak_
    Poziom 33  
    Tylko tak samo można źle odebrać bajt z ilością bajtów danych jak i bajt końca ramki;)
  • #13 8236449
    markosik20
    Poziom 33  
    _Robak_ napisał:
    Tylko tak samo można źle odebrać bajt z ilością bajtów danych jak i bajt końca ramki;)


    Tylko bajtów końca ramki jest 2-3 a bajt z ilością danych jeden (gdzie jest większe prawdopodobieństwo błędu?). Zresztą, ja tam nikogo nie będę przekonywał, niech każdy sobie implementuje algorytm jak uważa.
  • #14 8236694
    uuidgen
    Poziom 12  
    Jeżeli zakłada się, że dane mogą zaginać po drodze to konieczne jest wyróżnienie STARTU ramki i odpowiednie "escape" tego startu w danych.

    Czyli np zaczynamy ramkę bajtem 0b10101010 to wtedy w treści ramki zamiast wysyłać 0b10101010 wysyłamy 0b01010101 0b10101010 a zamiast 0b01010101 wysyłamy 0b01010101 0b01010101.
    Sama konstrukcja ramki jest często sensowna w postaci:
    [HEAD][ADRES][DANE STAŁE][ROZMIAR DODATKOWYCH DANYCH][SUMA KONTROLNA]<DANE DODATKOWE><SUMA KONTROLNA DANYCH>

    W ten sposób dopuszczamy zarówno ramki kontrolne jak i ramki przesyłające dowolną porcję danych. Jeżeli nagłówek jest niepoprawny to po prostu ignorujemy całą resztę co ułatwia obsługę.

    Jeżeli nie ma konieczności komunikacji z urządzeniami, które tego nie obsługują to wygodne jest ustawienie transmisji na 9bitów i wyróżnienie nagłówka zapalonym 9 bitem a danych zgaszonym. Odpada konieczność obsłużenia bajtu początku ramki a rozpoznanie początku ramki ogranicza się do zliczenia ile było porcji danych z zapalonym bitem (potem oczywiście liczymy sumę kontrolną).
  • #15 8236835
    markosik20
    Poziom 33  
    uuidgen napisał:
    Jeżeli zakłada się, że dane mogą zaginać po drodze to konieczne jest wyróżnienie STARTU ramki i odpowiednie "escape" tego startu w danych.


    A jak zaginą ostatnie bajty, to co wtedy?. Nie ma sensu dokładać następnych zabezpieczeń...bo do tego wystarczy jedno CRC na całą ramkę.
    Niech autor sprawdzi jak wyglądają ramki protokołu MODBUS który jest stosowany z powodzeniem w przemyśle. Myślę że jest on najbardziej uniwersalny.
  • #16 8236941
    m3
    Poziom 12  
    Witam, ale rozgorzała dyskusja :) ale to dobrze :)

    Ostatecznie moja ramka będzie wyglądać tak:

    [start][ilość danych][dane][CRC16][stop]
    czyli tak jak zaproponował _Robak_ (oprócz CRC16).

    Natomiast pole [dane] będzie zawierać polecenie, parametry, ich wartości itd.

    Dzięki wszystkim za dyskusję i pomoc.
  • #17 8237044
    tmf
    VIP Zasłużony dla elektroda
    Na błędy w polu size jest proste zabezpieczenie. Cały header (adres, size, cośtam jeszcze co potrzebne) zabezpiecza się swoim CRC. Wtedy odbiornik odbiera zawsze 4 bajty, sprawdza ich poprawność i potem odbiera wskazaną porcję danych. Żadnych wyróżnień nie trzeba robić. Tak jak pisze uuidgen, jeśli dane mogą zaginąć to robi się znacznik początku a nie końca pakietu. Na RS232 najprościej to zrobić stosując transfer 9-bitów przy starcie (wiele procesorów ma specjalny tryb, w którym odbiera taką ramkę jako specjalną, np. AVR mają MPCM), a reszta danych leci normalnie. Odciąża to też odbiorniki, do których pakiet nie jest przeznaczony - ignorują bajty 8-bitowe, reagują tylko na adresy.
  • #18 8237854
    markosik20
    Poziom 33  
    tmf napisał:
    Tak jak pisze uuidgen, jeśli dane mogą zaginąć to robi się znacznik początku a nie końca pakietu.


    A co Ci da znacznik początku jak fizycznie nie odbierzesz reszty? Chyba bardziej logiczne jest że mając znacznik końca ramki w buforze powinny znajdować się wcześniejsze dane?. Równocześnie wiele szybciej jesteśmy to w stanie zweryfikować (bo operujemy na RAM'ie....nie na dopiero co przychodzących bajtach). Rozmawiamy tutaj o bardzo skrajnych przypadkach bo na 99% jak wszystko jest dobrze zrobione to transmisja "leci" bez zakłóceń.
  • #19 8238068
    tmf
    VIP Zasłużony dla elektroda
    Jeśli nie odbiorę reszty to wcześniej się dowiem, że coś jest nie tak, niż czekając na jakieś znaczniki końca. Zresztą w znanych protokołach jest to rozwiązane tak jak piszę, co jest najlepszym dowodem na to, że tak po prostu jest najlepiej. We wszystkich protokołach wireless jest preambuła, a nie "postambuła". W protokołach przewodowych typu ethernet również jest preambuła, a nie znaczniki końca.
  • #20 8238198
    markosik20
    Poziom 33  
    tmf napisał:
    Jeśli nie odbiorę reszty to wcześniej się dowiem, że coś jest nie tak, niż czekając na jakieś znaczniki końca.


    Czyli analizujesz cały czas odbierane dane...jak uC ma dużo czasu to wiadomo nie ma problemu. Nie jesteś jasnowidzem i nie wiesz co dostaniesz (no chyba że masz z góry narzuconą długość ramki, rodzaj danych etc. i postawiane CRC co drugi bajt :wink:)

    tmf napisał:
    We wszystkich protokołach wireless jest preambuła, a nie "postambuła". W protokołach przewodowych typu ethernet również jest preambuła, a nie znaczniki końca.


    Nie myl interfejsu fizycznego z protokołem. Te preambuły używane są do synchronizacji nadajnika z odbiornikiem i nie mają nic wspólnego z przesyłanymi ramkami danych (podobnie jak automatyczny bit stopu w RS232...hmm ciekawe po co jak jest bit startu?). Stosowanie znacznika startu z bajtem size jest tak samo popularne jak kończenie znacznikiem końca np:[CR][LF] (mowa o ASYNCHRONICZNYM RS232). Czasami urządzenia wysyłające dane nie liczą ilości danych tylko je wysyłają kończąc je znacznikiem końca (prawie wszystkie moduły GSM (popularne SIM300 i podobne)). MODUBUS ASCII też posiada znaczniki końca, RTU już nie, popularny 3964 Siemensa też "idzie" ze znacznikami końca. Nie krytykuje implementacji algorytmu podobnego do MODBUS RTU ([adres][size][dane][CRC]) ale nie zawsze jest to najlepsza i optymalna metoda.
  • #21 8238314
    tmf
    VIP Zasłużony dla elektroda
    Nic nie analizuję. Odbieram stały początek ramki składający się z adresu i pola określającego długość reszty danych. Dzięki temu wiem ile ich mam jeszcze odebrać. Jeśli jestem paranoikiem to dodatkowo opatruję to CRC, dzięki czemu wiem, że header jest ok. Cały pakiet kończy się CRC, jeśli liczę je na bieżąco to prawidłowa ramka musi dać w wyniku CRC=0. Dzięki temu nie ma opóźnień na przetwarzanie danych ramki. Nigdzie nie widzę tu obciążenia dla procesora.
    Co do preambuły. Oczywiście są one wykorzystywane do synchronizacji odbiornika. A ta synchronizacja potrzebna jest do odbioru ramki. Stąd też preambułę można traktować jako część ramki danych. Np. w popularnych transceiverach RFMxxx jest to wykorzystywane do selekcji odbiornika. Odbiorniki o innej ustawionej preambule ignorują dalszy pakiet danych.
    Co do RS232 to bit startu jest potrzebny (to analogia do preambuły) do synchronizacji odbiornika. Ale bit stopu już niczemu nie służy - często wykorzystuje się go do innych celów (np. wyróżnienie w ramce danych o adresie - wspomniane rozszerzenie MPCM). Znaczniki końca są potrzebne wyłącznie przy wysyłaniu danych o nieogreślonej z góry długości - np. klawiatura. Można wysyłać po jednym znaku, co daje duży overhead, albo w miarę jak znaki są wpisywane - wtedy koniec porcji sensownie jest zaopatrzyć specjalnym kodem, np. CR/LF.
  • #22 8238415
    markosik20
    Poziom 33  
    tmf napisał:
    Nic nie analizuję. Odbieram stały początek ramki składający się z adresu i pola określającego długość reszty danych. Dzięki temu wiem ile ich mam jeszcze odebrać. Jeśli jestem paranoikiem to dodatkowo opatruję to CRC, dzięki czemu wiem, że header jest ok. Cały pakiet kończy się CRC, jeśli liczę je na bieżąco to prawidłowa ramka musi dać w wyniku CRC=0. Dzięki temu nie ma opóźnień na przetwarzanie danych ramki. Nigdzie nie widzę tu obciążenia dla procesora.


    Z tym obciążeniem to nie masz racji, jak ktoś liczy takty by uC się "wyrobił" to ma znaczenie.

    W przypadku wykrywania początku ramki
    1. Sprawdzasz czy nagłówek jest odebrany i prawidłowy (czyli pierwszy raz analizujesz dane).
    2. Jak odebrany to:
    - za każdym bajtem liczysz CRC (opcjonalnie) lub
    - ładujesz dane do bufora zwiększając licznik ;
    - jak licznik==długość ramki analizujesz dane (drugi raz);
    - jak licznik<= długość ramki i czas zostaje przekroczony wszystko resetujesz;


    W przypadku wykrywania końca ramki
    1. Ładujesz dane do bufora dopóki napotkasz koniec ramki (if na dwóch bajtach) lub skończy się bufor (jak się skończy to wiadomo..wskaźniki na początek bufora i dalej odbieranie);
    2. Jak masz koniec analizujesz dane (i nie ważne ile tego jest), po prostu cofasz wskaźnik szukając początku ramki...i masz całą ramkę.

    Obie metody skuteczne i prawidłowe lecz ta pierwsza niestety potrzebuje "ciut" więcej czasu uC na obsługę przerwania.
  • #23 8238593
    mirekk36
    Poziom 42  
    Ja też zdecydowanie preferuję metodę rozpoznawania końca ramki, dzięki czemu już gdzieś np w pętli głównej można na spokojnie obsługiwać dane , które nadleciały, a w międzyczasie ładnie do bufora może wpaść jeszcze dziesięć innych ramek jeśli jest duży ruch w sieci.

    Dokładnie jak pisze markosik20 - na końcu CRLF wywołuje mi ładnie zdarzenie czy też zwiększa licznik ramek do obróbki. Dodatkowo ja akurat większość danych wysyłam jako znaki ASCII, np w HEXie dzięki czemu super łatwo rozpoznawać CRLF.
  • #24 8239014
    tmf
    VIP Zasłużony dla elektroda
    ad1. Sprawdzenie CRC 4 bajtów nie trwa długo, nieprawdaż? W dodatku robimy to jednokrotnie.
    ad2. Policzenie CRC dla jednego bajtu, trwa jeszcze krócej, nieprawdaż?
    Zaczeliśmy od UARTA, więc spójrzmy na fakty. Wysłanie 1 bajta danych przez UART, nawet przy 115kbps trwa 86us, dla procesora to wieczność. Między kolejnymi bajtami mamy tyle czasu, że wskazane przez ciebie obliczenia są bez znaczenia. Poza tym nie wydłużają one znacząco czasu obsługi przerwania. liczenie CRC to raptem pare taktów, porównanie czy nie mamy końca pakietu nic nie obciąża, bo ty też musisz takie porównanie zrobić. Przecież nie znając z góry długości pakietu musisz za każdym razem sprawdzać, czy zapisując nie przekroczysz pojemności bufora. Musisz też poświęcić sporo czasu na analizę, czy nie otrzymałeś znacznika końca. Też przecież musisz to robić po odebraniu każdego znaku. A jeśli dla ciebie istotny jest każdy takt to znaczy, że wybrałeś zły procesor, czyli projekt w założeniach jest do du... Chyba, że piszesz wyłącznie w assemblerze, bo w C czy Bascomie liczenie taktów jest niemożliwe.
    Ale jeszcze raz wrócę do mojego argumentu - dlaczego jest tak mało profesjonalnych implementacji wykorzystujących metodę poszukiwania znaczników końca?
  • #25 8239156
    markosik20
    Poziom 33  
    tmf napisał:
    Ale jeszcze raz wrócę do mojego argumentu - dlaczego jest tak mało profesjonalnych implementacji wykorzystujących metodę poszukiwania znaczników końca?


    Jak mało ? Przecież podałem przykłady, pracuję w branży wagarskiej i tutaj prawie każdy miernik wysyła ramkę ze znakiem końca. Dlaczego nie możesz zrozumieć że istnieją takie i takie implementacje, wszędzie gdzie pisze się aplikacje na PC'ta łatwiej się analizuje odbierane dane posiadając znaczniki końca i początku.
    Dobry przykład podał mirekk36, mając [CR][LF] na końcu łatwiej analizować transmisję , podsłuchując ją na PC (nie lecą bezsensowne znaki tylko ładnie ułożone ramki). Nie upieram się że ramkę trzeba sprawdzać od końca ale umieszczenie chociażby tych [CR][LF] dużo pomaga przy szukaniu błędów lub diagnostyki.

    Przykład:

    
    
    //uart.poz_znaku_odbioru jest 5bitowy;
    
    ISR(USART_RXC_vect)
    {
    	uart.buf_odbioru[++uart.poz_znaku_odbioru] = UDR;
    
    
    	if(	uart.buf_odbioru[uart.poz_znaku_odbioru]==0x0A &&
    		uart.buf_odbioru[uart.poz_znaku_odbioru-1]==0x0D )
    	{
    		uart.flagi_UARTA.dane_przyszly=1;
    	}
    
    }
  • #26 8239258
    tmf
    VIP Zasłużony dla elektroda
    CRLF pomaga o ile wysyłasz dane w formacie ASCII, jeśli to jest raw binary data to i tak nic nie podglądniesz, bo będziesz miał krzaczki, albo co gorsze terminal zinterpretuje to jako znaki kontrolne. Nie mówię, że czekanie na znak końca nie ma sensu - tylko, że ten sens jest ograniczony do sytuacji, w których z góry nie wiadomo ile znaków zostanie wysłanych. Piszesz o wagach, akurat te elektroniczne, które mam wysyłają stałe ramki, np. zawsze jest to 20 bajtów. A zobacz inne urządzenia - GeniBus, eBus, profibus, CAN, LIN z rozwiązań przemysłowych - żadne nie bazuje na detekcji końca.
    Co do twojego kodu - jest on wrażliwy na buffer overrun, więc trzeba dodać jeszcze kilka warunków. No i pokaż teraz drugą część kodu - iterakcje przez wszystkie wartości bufora, żeby znaleźć koniec poprzedniej ramki. A na końcu dla koneserów - to się nadaje tylko przy wysyłce danych w formacie ASCII, jeśli wyślesz dane binarne, to takie szukanie końca jest OKDR. A przecież mówiłeś o liczeniu taktów - konwersja na ASCII i potem odwrotnie trochę zajmuje czasu, same dane "puchną" więc trzeba ich wysłać więcej niż gdyby były w postaci binarnej, czyli większe obciążenie szyny, czyli znowu dodatkowy nakład na odbiór nadmiarowych danych. Trochę to sprzeczne z koncepcja liczenia każdego taktu.
  • #27 8239306
    _Robak_
    Poziom 33  
    Akurat bit stopu jest o tyle ważny, że bez niego mogłoby nie być przerwy ,stanem wysokim na linii, pomiędzy ramkami.
  • #28 8239483
    markosik20
    Poziom 33  
    tmf napisał:
    A zobacz inne urządzenia - GeniBus, eBus, profibus, CAN, LIN z rozwiązań przemysłowych - żadne nie bazuje na detekcji końca.


    Racja, jak pisałem są różne rozwiązania.

    tmf napisał:

    Co do twojego kodu - jest on wrażliwy na buffer overrun


    No nie za bardzo, gdyż bufor jest większy od iteracji wskaźnika (zapis będzie "w kółko").

    tmf napisał:

    No i pokaż teraz drugą część kodu - iterakcje przez wszystkie wartości bufora, żeby znaleźć koniec poprzedniej ramki.


    Akurat komunikację mam tak dopasowaną czasowo że pierwszy bajt w ramce znajduje się zawsze na pierwszym bajcie bufora. Po policzeniu CRC z całości, sprawdzany jest adres, rodzaj kodu i wykonywana jest odpowiednia instrukcja.
    Jeżeli chodzi o iterację i szukanie początku ramki to robię to na trochę szybszym uC (STM32 + SIM300).

    tmf napisał:
    A na końcu dla koneserów - to się nadaje tylko przy wysyłce danych w formacie ASCII, jeśli wyślesz dane binarne, to takie szukanie końca jest OKDR.


    Masz rację , ale znakami ASCII można w czytelny sposób porozgraniczać dane binarne w sekcje. Dodatkowo gdy wykorzystujemy soft na PC do współpracy, składanie np: float'ów jest dosyć skompliowane więc ASCII tutaj pasuje idealnie.
    Konstruowałem swój algorytm pod kątem łatwej diagnostyki magistrali przez podpięcie się do niej PC'tem. Widać wtedy jak na dłoni które urządzenie "szaleje" lub w którym momencie występują zakłócenia.
  • #29 8239599
    tmf
    VIP Zasłużony dla elektroda
    markosik20 napisał:
    tmf napisał:

    Co do twojego kodu - jest on wrażliwy na buffer overrun


    No nie za bardzo, gdyż bufor jest większy od iteracji wskaźnika (zapis będzie "w kółko").


    Czyli bufor ma co najmniej 256 bajtów. Oczywiście nie wyjdziesz poza taki bufor, ale overrun będzie w tym wypadku polegał na nadpisaniu danych na początku bufora. Też źle.

    markosik20 napisał:
    tmf napisał:
    A na końcu dla koneserów - to się nadaje tylko przy wysyłce danych w formacie ASCII, jeśli wyślesz dane binarne, to takie szukanie końca jest OKDR.


    Masz rację , ale znakami ASCII można w czytelny sposób porozgraniczać dane binarne w sekcje. Dodatkowo gdy wykorzystujemy soft na PC do współpracy, składanie np: float'ów jest dosyć skompliowane więc ASCII tutaj pasuje idealnie.


    Tak, tylko jeśli zastosujesz tagi do rozgraniczenia danych binarnych to kod interpretujący ramkę się bardzo skomplikuje - będziesz musiał w przerwaniu wyszukiwać tagu, sprawdzać flagę oznaczającą taki blok itd. Innym rozwiązaniem jest wyescapowanie danych binarnych. Prostsze w interpretacji ale z kolei duża nadmiarowość.
  • #30 8239657
    markosik20
    Poziom 33  
    tmf napisał:
    Czyli bufor ma co najmniej 256 bajtów.


    Wskaźnik/licznik nie musi być 8-bitowy.

    tmf napisał:
    ...jeśli zastosujesz tagi do rozgraniczenia danych binarnych to kod interpretujący ramkę się bardzo skomplikuje - będziesz musiał w przerwaniu wyszukiwać tagu, sprawdzać flagę oznaczającą taki blok itd.


    Niekoniecznie w przerwaniu, wystarczy w main bo jak jest za mało "czasu" to w trakcie analizy ramki można przełączyć bufor i w tym samym czasie odbierać następną ramkę.
REKLAMA