Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Błędy w komunikacji szeregowej RS232

marciano8 09 Sie 2017 21:33 336 12
  • #1 09 Sie 2017 21:33
    marciano8
    Poziom 8  

    Dzień dobry.

    Zwracam się do Was bo zapewne cześć osób zna i stosuje rozwiązanie problemu z którym walczę.
    Jak radzicie sobie z błędami w transmisji danych w komunikacji szeregowej RS232?

    Szukając informacji o błędach występujących w komunikacji szeregowej znalazłem informację, że uzyskanie błędu na poziomie 0 % jest sprawą złożoną i że gdy procent błędów wynosi 1-2 % to poziom ten uznaje się za zadowalający.
    A teraz przykładowo: mam mikrokontroler który steruje procesem i przez RS232 przesyłam z PC wartości zadane do tego mikrokonteolera jako strumień ASCII a mikrokontroler to odczytuje i zapisuje sobie jako kolejne wartości zadane w czasie (nie chodzi mi tu o sterowanie w czasie rzeczywistym za pośrednictwem RS232 bo mikrokontroler robi to tak, że zapisuje sobie cały zadany przebieg z PC a sterować zaczyna dopiero po zapisaniu go).
    Jak teraz rozumieć, że 2 % błędu jest poziomem akceptowalnym? Jeżeli wysyłam strumień danych, np. 1000 próbek zadanego przebiegu i teraz 2 % z nich jest błędne a gdzieś zostanie odczytany krzaczek zamiast poprawnej wartości liczbowej to taki sterownik a wraz z nim cały proces utyka. Dla mnie (i na pewno dla was też) jest to nie do zaakceptowania.

    I tu rodzi się moje pytanie bo może o czymś nie wiem:
    W jaki sposób rozwiązujecie problem polegający na tym, że do 2 % przesłanych danych może być błędnych gdy chcecie przesyłać dane bezbłędne? Przesyłacie je dwa razy i porównujecie? Sprawdzacie czy przesłane wartości są liczbami i w przypadku krzaczków wznawiacie transmisję? Jak sobie z tym radzicie? Czy jest jakieś rozwiązanie sprzętowe które samo sprawdza poprawność transmisji i ponawia wysyłanie gdy wystąpi błąd? Czy jest to jakoś związane z kontrolą parzystości (u mnie włączanie i wyłączanie kontroli parzystości nie miało wpływu na błędy w komunikacji)?

    Proszę o Waszą pomoc i pozdrawiam,
    M.

  • #3 09 Sie 2017 21:45
    dondu
    Moderator Mikrokontrolery Projektowanie

    Skąd te informacje?
    Jak wygląda tor transmisyjny?
    Jak wygląda ramka danych?
    ...

    Innymi słowy piszesz o teoretycznych problemach, a nie o konkretnym przypadku.
    Jeśli wszystko rozwiążesz prawidłowo, to błędy może będą liczone w promilach lub jeszcze mniejszych jednostkach.

  • #4 09 Sie 2017 22:21
    marciano8
    Poziom 8  

    dondu napisał:
    Skąd te informacje?
    Jak wygląda tor transmisyjny?
    Jak wygląda ramka danych?
    ...

    Innymi słowy piszesz o teoretycznych problemach, a nie o konkretnym przypadku.
    Jeśli wszystko rozwiążesz prawidłowo, to błędy może będą liczone w promilach lub jeszcze mniejszych jednostkach.


    Promilach? Myślałem, że te 1-2 % to coś z czym należy się pogodzić.

    Konkretny przypadek jest taki:
    Mam STM32F4 DISC1 (z programem napisanym w C#.NETMF), który odbiera dane z aplikacji Windowsa (napisanej w C#.NET). Aplikacja wysyła zadany przebieg czasowy a STM32 go odczytuje i zapisuje w tablicy. Następnie zgodnie z zadanym przebiegiem czasowym ma sterować procesem. STM32 jest widziany jako wirtualny port COM. Prędkość transmisji - próbowałem 9600 oraz 19200 i w obu przypadkach zdarzały się błędy. Objawiało się to tym że w wysłanym ciągu danych pojawiła się np. kropka zamiast zera i cały przebieg był niepoprawny a proces utykał bo nie potrafił dokonać działania arytmetycznego na "1.0.123". Włączałem kontrolę parzystości (Even) ale działało to tak samo jak przy wyłączonej tj. zdarzały się "wartości" typu "1.0.123", które sprawiały że proces utykał.

    Piszę to w C# i korzystam tam z gotowych poleceń typu "serialPort2.Write()", "serialPort2.Read()". Przesyłam to portem który jest skonfigurowany następująco: Liczba bitów na sekundę: 9600, Bity danych: 8, Parzystość: Brak, Sterowanie przepływem: Brak.
    Próbowałem też z 19200 bps i ustawiałem Parzystość: Parzyste ale bez poprawy. Zdarza się, że jak wysyłam taki przebieg do co jakiś czas wkrada się coś typu "1.0.123".

    Czy znacie koledzy jakieś mądre rozwiązania o których nie wiem? Kontrola poprawności transmisji realizowana procesowo przez sam protokół? Albo jakieś metody mniej prostackie od napisania programu na uC, który po zakończeniu odbierania będzie sprawdzał wszystkie liczby po kolei i wymuszał retransmisję jeżeli stwierdzi, że jakiś element nie jest poprawną liczbą?

    Dodano po 12 [minuty]:

    electronics_design napisał:
    Kontrola parzystości i retransmisja? Jeżeli wystąpi max 2 razy na 100 próbek to nie zwolni to znacznie transmisji. Gotowe elementy w środowiskach (SerialPort itd) mają możliwość kontroli parzystości, tak samo peryferia w mikrokontrolerach.


    Gdy ustawiałem kontrolę parzystości (Even) w konfiguracji portu w aplikacji, mikrokontrolerze i w windowsie to problem i tak występował. Czasami wkradały sie wartości takie jak "1.0.456".

  • Pomocny post
    #5 09 Sie 2017 23:23
    jnk0le
    Poziom 17  

    Te "2 % błędu" oznacza raczej niedopasowanie rzeczywistego baudrate dwóch urządzeń.

  • Pomocny post
    #6 09 Sie 2017 23:29
    JacekCz
    Poziom 32  

    jnk0le napisał:
    Te "2 % błędu" oznacza raczej niedopasowanie rzeczywistego baudrate dwóch urządzeń.


    Tez mam wrażenie, że zasłyszane w literaturze procenty, do pozwolenie na niezgodność zegarów (clocków),, mogą się różnić, byle w ciągu bajtu i bitów kontrolnych nie urosło więcej niz kawałek bita. Jeśli bajt danych z bitami to 11-13 elementów, łączny błąd clockowania (błąd baud rate) powinien być znacznie niższy niż pól bitu.
    Mówimy o transmisji asynchronicznej, gdzie nie ma odtwarzania z sygnału jego podstawowego zegara

    Użytkowa stopa błędów 2% (w sensie błędów parzystości) de facto by uniemożliwiła transmisję żadnej dłuższej ramki, taka stopa zabija tranmisję tego typu

  • Pomocny post
    #7 10 Sie 2017 00:57
    Piotrus_999
    Poziom 39  

    marciano8 napisał:
    Mam STM32F4 DISC1 (z programem napisanym w C#.NETMF), który odbiera dane z aplikacji Windowsa (napisanej w C#.NET). Aplikacja wysyła zadany przebieg czasowy a STM32 go odczytuje i zapisuje w tablicy. Następnie zgodnie z zadanym przebiegiem czasowym ma sterować procesem. STM32 jest widziany jako wirtualny port COM. Prędkość transmisji - próbowałem 9600 oraz 19200 i w obu przypadkach zdarzały się błędy. Objawiało się to tym że w wysłanym ciągu danych pojawiła się np. kropka zamiast zera i cały przebieg był niepoprawny a proces utykał bo nie potrafił dokonać działania arytmetycznego na "1.0.123". Włączałem kontrolę parzystości (Even) ale działało to tak samo jak przy wyłączonej tj. zdarzały się "wartości" typu "1.0.123", które sprawiały że proces utykał.
    Rozumiem że robiłeś to przez jakąś przjściówkę VCOM na FTDI albo CH. Ja na obydwu testowałem przez ponad tydzień przy prędkości 1200000 i nie miałem ani jednego błednego bajtu. Transmisja z C# do i z uC. Długość pakietu zmienna do 64k bajtów. CRC do sprawdzania. Pakiet był potem zwracany i porównywany. Szczerze powiedziawszy robiłem to głownie dla przetestowania BW w C# i strumieni asynchronicznych bo zwykły serial w C# sie nie wyrabiał. czyli stopa błedu < 0.00000000013778660%. Jezeli używałeś przejściówki to miałeś coś zwalone w konfiguracji UART-a

    Jezeli używałeś V-COM-a z STLINK-a to problem jest w nim bo jest delikatnie mówiąc schrzaniony i nadaje się tylko do wysyłania komunikatów przy debugowaniu.

  • #8 10 Sie 2017 12:45
    marciano8
    Poziom 8  

    Piotrus_999 napisał:

    Jezeli używałeś V-COM-a z STLINK-a to problem jest w nim bo jest delikatnie mówiąc schrzaniony i nadaje się tylko do wysyłania komunikatów przy debugowaniu.


    Dokładnie. Używam V-COM-a z STLINK-a. Bardzo Ci dziękuję za tę informację. A dlaczego jest delikatnie mówiąc schrzaniony i nie nadaje się do wysyłania danych? Jaki jest w nim problem i co z nim nie tak?

  • Pomocny post
    #9 10 Sie 2017 13:38
    arturt134
    Poziom 26  

    Tak jak pisali Koledzy wcześniej, te 2% błędu oznacza niedopasowanie częstotliwości zegarów i jako takie może być pominięte. Niemniej jednak przy transmisji danych może dojść do chwilowych zakłóceń sygnału, co spowoduje powstanie "krzaków".
    Aby temu zaradzić można zastosować kontrolę CRC dla ramki danych, transmisję z potwierdzeniem i retransmisją w razie braku potwierdzenia.

    Dużo zależy też od medium. Na przykład przy transmisji danych przez modem GPRS dodatkowo należy się liczyć z "rwaniem" ramki danych, tzn. odstępy między fragmentami ramki danych mogą wynosić nawet kilka sekund. W takim przypadku, oprogramowanie musi być przygotowane na "składanie" takich porwanych ramek.

  • Pomocny post
    #10 10 Sie 2017 13:45
    Piotrus_999
    Poziom 39  

    marciano8 napisał:
    A dlaczego jest delikatnie mówiąc schrzaniony i nie nadaje się do wysyłania danych? Jaki jest w nim problem i co z nim nie tak?
    Weź debugger i poszukaj błedów :). Ja nie jestem z STM-a. Sami pewnie nie przywiazują do tego szczególnej wagi bo to nie jest urządzenie komunikacyjne tylko taki dodatek do ułatwienia debugowania. Wystarcza jak działa "jakoś". Kup przejściówkę za parę złotych

  • Pomocny post
    #11 10 Sie 2017 14:22
    JacekCz
    Poziom 32  

    arturt134 napisał:
    Tak jak pisali Koledzy wcześniej, te 2% błędu oznacza niedopasowanie częstotliwości zegarów i jako takie może być pominięte. Niemniej jednak przy transmisji danych może dojść do chwilowych zakłóceń sygnału, co spowoduje powstanie "krzaków".
    Aby temu zaradzić można zastosować kontrolę CRC dla ramki danych, transmisję z potwierdzeniem i retransmisją w razie braku potwierdzenia.

    Dużo zależy też od medium. Na przykład przy transmisji danych przez modem GPRS dodatkowo należy się liczyć z "rwaniem" ramki danych, tzn. odstępy między fragmentami ramki danych mogą wynosić nawet kilka sekund. W takim przypadku, oprogramowanie musi być przygotowane na "składanie" takich porwanych ramek.


    żeby dopełnić od strony teoretycznej, jeśli stopa błedów jest większa, a po drugie w zalezności od ich charakteru (np pochodzące od zakłóceń elektrycznych są grupami, rysa na CDROM niszczy bezpowrotnie część 'bliskich' bajtów i znowu w dość dalekim bloku itd, tu słusznie wspominasz o czasie, o innym rodowodzie inaczej) ... są całkiem ambitne sposoby radzenia sobie.

    Ale trzeba mieć zrozumienie przyczyny błędów (tu mówię o reakcji 'softwarowca' czy 'telekomunisty', bo 'elektronik' też zareaguje po swojemu).

    EDIT na błędy 'logiczne', czyli jak tu się sugeruje coś w chipie spieprzone, albo źle użyte oprogramowanie, NIE JEST lekarstwem redundancja danych. Zwykle jak mamy kłopoty z niedopracowaniem+złożoność, to zwiększenie złożoności nie jest lekarstwem

    marciano8 napisał:
    ... sterowanie w czasie rzeczywistym za pośrednictwem RS232 bo mikrokontroler robi to tak, że zapisuje sobie cały zadany przebieg z PC a sterować zaczyna dopiero po zapisaniu go).


    Nie wyobrażam sobie inaczej, tylko tak jest profesjonalnie. Bo co, jak drugi bajt w ramce już był uszkodzony, a my wytworzyliśmy jakis skutek.

    To rodzi problemy (o czym pośrednio pisał @arturt134) gdy ostattnie bajty ramki się dużo spózniają

  • Pomocny post
    #12 10 Sie 2017 14:34
    arturt134
    Poziom 26  

    Jeżeli przyczyną błędów jet spieprzony chip, to na to była już podana rada wcześniej - kup przejściówkę za kilka złotych. Niemniej jednak wymiana przejściówki nie zabezpieczy przed innymi źródłami błędów - o tym właśnie piszę.....

  • #13 10 Sie 2017 15:22
    marciano8
    Poziom 8  

    Bardzo Wam wszystkim dziękuję za pomoc.

 Szukaj w ofercie
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME