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

[Atmega 16][Visual studio C#] Błędna komunikacja przez serial port.

adam: 23 Wrz 2018 18:59 1302 26
REKLAMA
  • #1 17456708
    adam:
    Poziom 12  
    Witam. Próbuję napisać program w języku c# (Windows form application) komunikujący się z procesorem atmega 16 przez serial port (przejściówka usb-uart na FT232RL.) Po stronie atmegi jest wyświetlacz na sterowniku ks108. Mój problem polega na tym że jeśli wysyłam przykładowo stringa "12345678" na wyświetlaczu dostaję tylko 3 pierwsze cyfry (123), jeśli wysyłam stringa z mniejszą liczbą znaków niż 3 wszystko działa. Testowałem na innym programie (Terminal v1,9b) i tam problem ten nie występuję (mogę wysyłać napisy o dowolnej długości) ,więc problem leży gdzieś w moim programie ale nie potrafi go zlokalizować.
    Poniżej wklejam kod z atmegi i z visual studio

    Akcja odpowiedzialna za otwarcie portu.
    Kod: C#
    Zaloguj się, aby zobaczyć kod


    Akcja odpowiedzialna za wysłanie danych
    Kod: C#
    Zaloguj się, aby zobaczyć kod


    Kod z atmegi odpowiedzialny za odbiór danych (myślę że tutaj jest ok bo wszystko działa na innym terminalu)
    Kod: C#
    Zaloguj się, aby zobaczyć kod
  • REKLAMA
  • #2 17456859
    tmf
    VIP Zasłużony dla elektroda
    Pokaż resztę kodu, dla AVR, bo ten fragment niewiele wyjaśnia. Obstawiam, że funkcja odbioru znaków się nie wyrabia - 3 znaki odbierze bo UART ma bufor, kolejne gubi. Jest też możliwość, że gdzieś nadpisujesz pamięć. Tylko reszta kodu to może wyjaśnić. Ew. wstaw małe opóźnienia pomiędzy wysyłką kolejnych znaków z PC i sprawdź czy wtedy jest ok. Jeśli tak - znaczy kod po stronie AVR gubi znaki bo się nie wyrabia.
  • REKLAMA
  • #3 17457292
    Konto nie istnieje
    Konto nie istnieje  
  • #4 17457359
    excray
    Poziom 41  
    Pobierz sobie "Virtual Serial Port Kit", zrób sobie wirtualną pętelkę i podejrzyj na PC czy to co wysyłasz ma sens. Pamiętaj, że WriteLine wysyła tekst z terminatorem LF. CR nie występuje wtedy w tym stringu więc warunek "if (ch == '\r')" nigdy nie będzie spełniony.
  • #5 17457631
    Konto nie istnieje
    Konto nie istnieje  
  • REKLAMA
  • #6 17457855
    adam:
    Poziom 12  
    Sprawdziłem w programie Device monitoring studio co się dzieje na porcie com jak wysyłam przez mój program i terminal.
    Z mojego programu (Visual studio)

    Logi z programu od chwili otwarcia portu poprzez wysłanie danych i zamknięcie portu.
    Kod: C#
    Zaloguj się, aby zobaczyć kod

    Screeny z programu:

    [Atmega 16][Visual studio C#] Błędna komunikacja przez serial port.

    [Atmega 16][Visual studio C#] Błędna komunikacja przez serial port.


    To samo wysłane przez terminal (ten na którym wszystko działa)
    Kod: C#
    Zaloguj się, aby zobaczyć kod


    [Atmega 16][Visual studio C#] Błędna komunikacja przez serial port.[Atmega 16][Visual studio C#] Błędna komunikacja przez serial port.


    Ustawienia terminala:
    [Atmega 16][Visual studio C#] Błędna komunikacja przez serial port.

    Reszta kodu z avmegi to w zasadzie samo ustawianie komunikacji i odbiór pojedynczego znaku:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Z tego co widzę to terminal wysyła na końcu 0x0D a mój program 0x0A, no i jest różnica w długości wysyłanych znaków (terminal wysyła tak jakby po 1 widać to w logach).
  • Pomocny post
    #7 17457920
    Konto nie istnieje
    Konto nie istnieje  
  • #8 17457956
    adam:
    Poziom 12  
    Ok to przerobię kod na avr tak żeby było na przerwaniach zrobione. Na razie nie będę ruszał kodu w C# bo raczej jest dobry ( teraz widzę że jest tak jak mówisz że odbieram jeden znak wyświetlam go i potem następne a to zajmuję za dużo czasu i gubię inne znaki) a terminal wysyła po 1 znaku powoli i dlatego zdążę odebrać je wszystkie. Dzięki za pomoc, napisze nowy kod, jak by coś nie działało to się odezwę :)
  • Pomocny post
    #9 17457972
    tmf
    VIP Zasłużony dla elektroda
    Pinczaiewicz napisał:
    To by tłumaczyło dlaczego odbierasz 3 znaki - @tmf miał rację. Odbierasz pierwszy i np wyświetlasz, w tym czasie przychodzą kolejne, AVR ma bufor na dwa znaki, więc dwa odbierzesz poprawnie, resztę gubisz. Niestety nie wiesz o tym, bo nie sprawdzasz w USARTReadChar() flagi przepełnienia :-(
    Odbieraj na przerwaniach, zrób sensowny bufor na dane a w programie głównym pobieraj dane z bufora i problemy znikną.

    Dlatego chciałem, aby autor pokazał istotne fragmenty kodu, bo podejrzewam, że odbiera znak i go wyświetla, co zajmuje sporo czasu. Można zrobić na przerwaniach (aczkolwiek przypuszczam, bez obrazy, że autor wpadnie tu w kolejne pułapki), a najprościej zrobić odbiór aż do znaku końca linii, czy innego sygnalizującego koniec ciągu znaków i dopiero wtedy to wyświetlać, a nie wyświetlać każdy znak z osobna.
  • #10 17458021
    adam:
    Poziom 12  
    Tak na szybko przerobiłem odbieranie stringa (na razie bez przerwań i pewnie nie do końca poprawnie ) działa to w ten sposób że w pętli while odbieram cały string a potem go wyświetlam, i jak na razie działa ok. Także pewnie tutaj leżał problem dzięki wielkie za pomoc.
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #11 17458121
    tmf
    VIP Zasłużony dla elektroda
    To jeszcze dodaj zabezpieczenie przed przekroczeniem długości stringa. Bo teraz jeśli PC wyśle długi string to możesz zapisać aż 256 bajtów, po czy string będzie nadpisywany.
  • #12 17458187
    JacekCz
    Poziom 42  
    Kod: C#
    Zaloguj się, aby zobaczyć kod


    Inicjowanie portu jest dość ubogie, np nie określa handshakingu. Jest to wiodący parametr dla nie-gubienia znaków. Piszę bez platformy C# więc nie powiem jak to brzmi, ale multum przykładów jest.
  • #13 17460048
    katakrowa
    Poziom 23  
    Problemów może być sporo ja bym jednak zaczął od zmodyfikowania kodu odpowiedzialnego za komunikację zarówno po stronie PC jak i AVR. Wiem, że to brzmi mało pocieszająco ale gwarantuję, że efekt końcowy będzie zadowalający. Po pierwsze zrób jakąś strukturę ramki, która ma "wyraźny" początek i koniec. Po to mamy do dyspozycji w tabeli ASCII znaki [STX] i [ETX], [EOT], [ACK], [NAK]. Transmisja szeregowa jest "stara jak świat" i nie bez powodu to wszystko wymyślono. Oczywiście nie ma obowiązku używania takich właśnie znaków ale chodzi o ideę.

    W chwili obecnej Twój kod działa na zasadzie "szczęśliwego przypadku". Teoretycznie jak na linii pokażą się zakłócenia to wpadamy w pętlę receive_text() i nigdy z niej nie wychodzimy... Być może nawet występują jakieś przepełnienia tablicy i "zwis" AVR. Zauważ, że wyjście z pętli masz tylko na określony znak - brakuje obsługi przepełnienie bufora lub/i timeout.
    Nie masz obsługi limitu długości ramki ani timeout'ów. Czyli praktycznie nigdy nie wiesz w jakim miejscu jesteś.

    Aby to wszystko jakoś poukładać...
    W AVR robisz globalny bufor ramki tablicę (array) o nazwie np.: received;
    Do tego dodajesz globalny wskaźnik (int) bieżącej pozycji w ramce uartPos.
    Odbieranie znaków niech następuje w przerwaniu lub jako nieblokujący kod w głównej pętli programu ( musi być wywoływany na tyle często by nadążył odbierać znaki przy ustalonej szybkości transmisji ).
    Odbiór polega na sprawdzeniu czy w buforze portu szeregowego jest a jeśli jest to wstawieniu go do tablicy received[uartPos] a następnie uartPos++ ;
    Pod tym robisz warunek czy przypadkiem uartPos nie jest większy niż max rozmiar ramki. Jeśli jest to zerujesz uartPos = 0; ( w ten sposób masz pewność, że nie "wyskoczysz za tablicę").

    Raz na jakiś czas uruchamiasz funkcję, która sprawdza dane w ramce i jeśli są niekompletne lub błędne to wysyłasz do PC znak np.: [NAK] i resetujesz wskaźnik pozycji.
    Wtedy PC wie, że coś poszło nie tak i ma przerwać / ponowić transmisję.

    Przykład takiej prostej transmisji znajdziesz w temacie: https://www.elektroda.pl/rtvforum/topic3433799.html ( bez timeout'ów bo zastosowana tam logika ich nie wymaga ).

    No i jeszcze kilka ogólnych praktycznych porad ...
    Aby upewnić się, że wszystko jest OK.
    1. Przed rozpoczęciem zabawy upewnij się, że port szeregowy Ci działa - zewrzyj PINY 2 i 3 w gnieździe portu, uruchom terminal i zobacz czy dane "wracają".
    2. Miałem styczność z portami na USB, które pozwoliły się zainicjować tylko 2, 3 razy a potem się wieszały - trzeba było ponownie wyjąć i włożyć do USB.
    3. Napisz na AVR prosty program "echo" aby mieć pewność, że parametry transmisji są dobrze wyliczone dla zastosowanego kwarcu - niedawno miałem sytuację, ze 2 attiny z różnych serii uruchomione na wewnętrznym oscylatorze 1MHz "nie dogadały" się bo tak duże były różnice czasowe ( WTF ) - po podłączeniu kwarcu było OK.
  • #14 17460076
    adam:
    Poziom 12  
    katakrowa napisał:
    Problemów może być sporo ja bym jednak zaczął od zmodyfikowania kodu odpowiedzialnego za komunikację zarówno po stronie PC jak i AVR. Wiem, że to brzmi mało pocieszająco ale gwarantuję, że efekt
    końcowy będzie zadowalający. Po pierwsze zrób jakąś strukturę ramki, która ma "wyraźny" początek i koniec. Po to mamy do dyspozycji w tabeli ASCII znaki [STX] i [ETX], [EOT], [ACK], [NAK]. Transmisja szeregowa jest "stara jak świat" i nie bez powodu to wszystko wymyślono. Oczywiście nie ma obowiązku używania takich właśnie znaków ale chodzi o ideę.

    W chwili obecnej Twój kod działa na zasadzie "szczęśliwego przypadku". Teoretycznie jak na linii pokażą się zakłócenia to wpadamy w pętlę receive_text() i nigdy z niej nie wychodzimy... Być może nawet występują jakieś przepełnienia tablicy i "zwis" AVR. Zauważ, że wyjście z pętli masz tylko na określony znak - brakuje obsługi przepełnienie bufora lub/i timeout.
    Nie masz obsługi limitu długości ramki ani timeout'ów. Czyli praktycznie nigdy nie wiesz w jakim miejscu jesteś.

    Aby to wszystko jakoś poukładać...
    W AVR robisz globalny bufor ramki tablicę (array) o nazwie np.: received;
    Do tego dodajesz globalny wskaźnik (int) bieżącej pozycji w ramce uartPos.
    Odbieranie znaków niech następuje w przerwaniu lub jako nieblokujący kod w głównej pętli programu ( musi być wywoływany na tyle często by nadążył odbierać znaki przy ustalonej szybkości transmisji ).
    Odbiór polega na sprawdzeniu czy w buforze portu szeregowego jest a jeśli jest to wstawieniu go do tablicy received[uartPos] a następnie uartPos++ ;
    Pod tym robisz warunek czy przypadkiem uartPos nie jest większy niż max rozmiar ramki. Jeśli jest to zerujesz uartPos = 0; ( w ten sposób masz pewność, że nie "wyskoczysz za tablicę").

    Raz na jakiś czas uruchamiasz funkcję, która sprawdza dane w ramce i jeśli są niekompletne lub błędne to wysyłasz do PC znak np.: [NAK] i resetujesz wskaźnik pozycji.
    Wtedy PC wie, że coś poszło nie tak i ma przerwać / ponowić transmisję.

    Przykład takiej prostej transmisji znajdziesz w temacie: https://www.elektroda.pl/rtvforum/topic3433799.html ( bez timeout'ów bo zastosowana tam logika ich nie wymaga ).

    No i jeszcze kilka ogólnych praktycznych porad ...
    Aby upewnić się, że wszystko jest OK.
    1. Przed rozpoczęciem zabawy upewnij się, że port szeregowy Ci działa - zewrzyj PINY 2 i 3 w gnieździe portu, uruchom terminal i zobacz czy dane "wracają".
    2. Miałem styczność z portami na USB, które pozwoliły się zainicjować tylko 2, 3 razy a potem się wieszały - trzeba było ponownie wyjąć i włożyć do USB.
    3. Napisz na AVR prosty program "echo" aby mieć pewność, że parametry transmisji są dobrze wyliczone dla zastosowanego kwarcu - niedawno miałem sytuację, ze 2 attiny z różnych serii uruchomione na wewnętrznym oscylatorze 1MHz "nie dogadały" się bo tak duże były różnice czasowe ( WTF ) - po podłączeniu kwarcu było OK.


    Dzięki za wskazówki ale nie napisałem najważniejszej rzeczy chyba. Cały program jaki tutaj próbuję napisać docelowo nie będzie komunikował się z Atmegą16 ale z Atemga 32u4 wraz z biblioteką LUFA (32u4 ma sprzętową obsługę usb), biblioteka jest tak skonfigurowana żeby po podłączeniu do PC atmega przedstawiała się jako wirtualny port com ( w tej bibliotece są już gotowe funkcje do nadawania i odbioru danych) , i jak do tej pory wszystko działało ok. Chwilowo użyłem Atmegi 16 bo nie mam pod ręką całej płytki z 32u4 i chciałem tylko sprawdzić czy to co napiszę na PC będzie dobrze działało (chodzi mi o samo wysyłanie danych), teraz widzę że mogłem sobie odpuścić zabawę z atmegą 16 bo zrobić na szybko poprawną komunikację nie jest tak łatwo (mogłem po prostu użyć programu do podglądu transmisji szeregowej). Także jak na razie myślę że po stronie PC muszę uzupełnić inicialiazje portu com, a reszta powinna już być ok.
  • #15 17460085
    tmf
    VIP Zasłużony dla elektroda
    katakrowa napisał:
    niedawno miałem sytuację, ze 2 attiny z różnych serii uruchomione na wewnętrznym oscylatorze 1MHz "nie dogadały" się bo tak duże były różnice czasowe ( WTF )

    To akurat twój błąd, bo producent podaje tolerancję wewnętrznego generatora i jasno z tego wynika, że nie powinien on być stosowany do taktowania transmisji UART. Reszta uwag jak najbardziej słuszna. Jednak, żeby przesadnie nie komplikować, IMHO dla tak prostych transmisji wystarczy dodanie timeouta - można go wykorzystać do resynchronizowania odbiornika.
    A jeszcze lepiej - skoro układ jest łączony przez przejściówkę USB-RS232 to większość rzeczy o których piszesz (kontrola transmisji danych) jest już realizowana przez protokół USB, jedynie właśnie detekcja początku danych by się przydała. Idąc dalej - po co robić konwerter USB-RS232, jeśli można od razu użyć procka z USB - np. z AVR ATMega z seri U, lub XMEGA z USB.
  • REKLAMA
  • #16 17460089
    katakrowa
    Poziom 23  
    adam: napisał:
    Chwilowo użyłem Atmegi 16 bo nie mam pod ręką całej płytki z 32u4


    Nadal nie zmienia to faktu, że musisz dodać zabezpieczenie przed przepełnieniem bufora odczytu danych ... To na 100% będzie powodowało Ci "zwiechy" uC. "Dobry stary" odkurzacz w okolicy urządzenia i zakłócenia przepełniają tablicę.
  • #17 17460100
    adam:
    Poziom 12  
    katakrowa napisał:
    adam: napisał:
    Chwilowo użyłem Atmegi 16 bo nie mam pod ręką całej płytki z 32u4


    Nadal nie zmienia to faktu, że musisz dodać zabezpieczenie przed przepełnieniem bufora odczytu danych ... To na 100% będzie powodowało Ci "zwiechy" uC. "Dobry stary" odkurzacz w okolicy urządzenia i zakłócenia przepełniają tablicę.

    No ale nie jest tak że to wszystko jest już zrobione w tej bibliotece ? (bo z tego co ją przeglądałem to chyba tak właśnie jest, wydaję się być dość dobrze napisana)
    Link
  • #19 17460109
    adam:
    Poziom 12  
    tmf napisał:
    @adam: Błąd masz w twoim kodzie - zwracałem ci na niego uwagę w poście #11.

    Owszem ale w poście #14 napisałem że nie mam zamiaru korzystać z atmegi 16 i Ft232RL ( to tylko na próbę było zrobione) więc odpada mi problem z pisaniem swojego programu.
    (Bo w bibliotece LUFA już wszystko jest z tego co mi się wydaję zabezpieczone)
    Tu np fragment konfiguracji gdzie widać deklaracje rozmiarów bufora.
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #20 17460119
    katakrowa
    Poziom 23  
    adam: napisał:
    No ale nie jest tak że to wszystko jest już zrobione w tej bibliotece ? (bo z tego co ją przeglądałem to chyba tak właśnie jest, wydaję się być dość dobrze napisana)


    A to zależy jak będziesz używał tej biblioteki bo jeśli użyjesz do odbierania danych algorytmu takiego jak w podanych przykładach na AVR to nawet najlepsza biblioteka Cię nie zabezpieczy. To, że biblioteka jest duża to nie znaczy, że odporna na "błędy użytkownika". Tam są takie same funkcje jak na AVR: http://www.fourwalledcubicle.com/files/LUFA/Doc/120730/html/_serial___a_v_r8_8h.html
    Pewnie będziesz używał Serial_ReceiveByte (void) więc zapewne swój błąd powielisz.
    Twój błąd nie jest na poziomie odbioru pojedynczego znaku tylko na poziomie obsługi ramki a ramki musisz obsłużyć sam ( przynajmniej dopóki nie skorzystasz z jakiegoś gotowego protokołu, do którego istnieją biblioteki ).

    Kod odbioru ramki powinien wyglądać przynajmniej tak:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod



    Nie zmienia to faktu, że ciągle jest to bardzo "słaby" kod obierający i ciągle nie wiesz w jakim miejscu jesteś.
  • #21 17460126
    tmf
    VIP Zasłużony dla elektroda
    Ja bym zamienił to maxsize na sizeof(string), warto by jeszcze dodać timeout, bo przypadkowy śmieć nie tylko spowoduje zwiechę programu (będzie się pętlił oczekując na 0x0a, ale także kolejny komunikat zostanie uszkodzony przez zalegający śmieć.
    adam: napisał:
    tmf napisał:
    @adam:: Błąd masz w twoim kodzie - zwracałem ci na niego uwagę w poście #11.


    Owszem ale w poście #14 napisałem że nie mam zamiaru korzystać z atmegi 16 i Ft232RL ( to tylko na próbę było zrobione) więc odpada mi problem z pisaniem swojego programu.
    (Bo w bibliotece LUFA już wszystko jest z tego co mi się wydaję zabezpieczone)

    Biblioteka realizuje poprawnie transmisję USB. Natomiast twój kod, jak widać wprowadza niebezpieczne rozwiązania, przed czym biblioteka cie nie uchroni.
  • #22 17460132
    adam:
    Poziom 12  
    Dobrze to napiszę program który zapisuję do tablicy dane i do tego uwzględnia te zabezpieczenia o których pisaliście i jak będzie gotowy to wkleję tutaj.
  • #23 17460145
    katakrowa
    Poziom 23  
    Aby sobie ułatwić życie dodaj jeszcze jakiś znak rozpoczynający transmisję, który zawsze resetuje wskaźnik pozycji ... To Ci mocno ułatwi sprawę w przypadku zakłóceń lub ramek "niedokończonych".
  • #24 17460242
    adam:
    Poziom 12  
    Ok jeszcze jedno pytanie, skoro będę korzystał z biblioteki LUFA i z funkcji np. CDC_Device_BytesReceived()
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    to mam zrobić funkcję "blokującą" ( na pętli while w pętli głównej) która będzie czekała na pojawienie się tego znaku o którym piszesz (początek transmisji ) i potem od razu będzie rozpoczynała odczyt danych i ładowanie ich do jakiejś tablicy (oczywiście z wszystkimi zabezpieczeniami itp)? Dobrze to rozumiem ?
  • #25 17460269
    tmf
    VIP Zasłużony dla elektroda
    adam: napisał:
    to mam zrobić funkcję "blokującą" ( na pętli while w pętli głównej) która będzie czekała na pojawienie się tego znaku o którym piszesz (początek transmisji )

    To zależy od tego co jeszcze ma robić program. Zauważ, że takie while z oczekiwaniem na znak zablokuje wykonywanie programu po odebraniu pierwszego znaku ramki, aż do jej zakończenia, lub timeoutu. W tym czasie program nic innego nie będzie mógł zrobić, jedyne co będzie działać to kod przerwań. Jeśli takie zachowanie jest dopuszczalne, to nie ma problemu, taki sposób kodowania ma tą zaletę, że jest prosty. Jeśli jednak program coś musi w międzyczasie robić to masz kilka opcji:
    - przerzucić to "coś" do przerwań,
    - lub w oparciu o przerwania zrobić odbiór ramki danych.
    Ta druga opcja jest IMHO sensowniejsza, w przerwaniach realizujesz odbiór kompletnych danych, po ich odebraniu tylko sygnalizujesz, że są i już nawet w pętli głównej analizujesz taką ramkę. Dzięki temu w pętli głównej nie masz oczekiwania na zakończenie transmisji.
    Jest jeszcze jedna opcja - zrobić maszynę stanu, w ten sposób można przepleś odbiór znaków z normalną realizacją programu.
  • #26 17460318
    adam:
    Poziom 12  
    Zasadniczo to pierwsza opcja ( bez przerwań ) mogła by być, ale pewnie lepiej było by zrobić na przerwaniach. Jeśli dobrze rozumiem to musiał bym użyć np. timera i w przerwaniu od niego sprawdzać czy znak który przyszedł ( i czy wg jakiś przyszedł- funkcja wtedy zwraca -1) jest równy temu co ma być, jeśli nie to wychodzę z przerwania a jeśli tak to zaczynam w jakiś sposób odbierać dane i ładować je do tablicy tak ? Bo o ile przy używaniu Uarta miałbym dostępne przerwanie od niego, to tutaj takowego chyba nie ma. Dobrze to rozumiem ?
  • #27 17460322
    katakrowa
    Poziom 23  
    kolega tmf przedstawił całą teorię i wystarczy się do niej zastosować.
    Ja mam jednak jeszcze jedną uwagę i poradę. Skoro nie wiesz czy masz zastosować kod blokujący czy nie to znaczy, że nie do końca rozumiesz program, który sam napisałeś.
    To jest objaw tak bardzo popularnego dzisiaj "nieprofesjonalnego" ( nie tylko wśród młodych programistów ) programowania, które nazywam programowanie przez zgadywanie.
    Proponuję byś odszedł od komputera i przeszedł się np. na spacer podczas którego wyobrazisz sobie jak lecą te bajty z komputera do kontrolera i wpadają do woreczka zwanego "buforem". Jak sobie to wyobrazisz to także zrozumiesz a jak zrozumiesz to będziesz wiedział co masz napisać i co jest potrzebne a co nie jest.
    Pomysłów na realizacje transmisji może być tysiące. Są oczywiście popularniejsze i mniej popularne to jaki zastosujesz zależy od potrzeb i umiejętności w doborze odpowiedniego ważne są także założenia całego projektu. Co jest serwerem a co jest klientem, czy wymagana jest odpowiedź czy nie, co się stanie gdy ramka nie dojdzie itp .. itd. Są przypadki kiedy ramkę możemy "olać" bo wiemy że za chwilę i tak przyjdzie następna ale bywa tak, że w ramce wysyłamy cenę i nie dość, że musi dojść do jeszcze musi być zweryfikowana dodatkowym CRC aby być pewnym, że cena jest bez przekłamań...
    Także jak widzisz możliwości i przypadków jest sporo a Ty jako programista i projektant tego układu musisz wiedzieć co układ ma robić jak się zachowywać i jakie narzędzia zastosować by zrealizować ten projekt.

    Myślę, że wszystkie porady już masz a teraz musisz w głowie sobie poukładać co i w jaki sposób tak naprawdę Twój program robić.
REKLAMA