Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

PIC32 - Komunikacja po RS232 nie działa tak jak należy przy 19200br

SowerOfWind 14 Sty 2016 10:51 3798 35
  • #1 14 Sty 2016 10:51
    SowerOfWind
    Poziom 17  

    Witam.

    Problem polega na tym, że z PIC'a do PC wysyłane są dane z prędkością 19200. Komunikacja potrafi działać prawidłowo przez wiele godzin i raz na pewien czas wkrada się błąd. Np. zamiast wysłać 522 wysyła 521 itp. Źródło problemu jest znane. Port COM w komputerze nie zawsze radzi sobie z synchronizacją, szczególnie w nowszych komputerach. Starsze nie mają tego typu problemu.

    Jak rozwiązać problem od strony uC?

    -Obecnie testuje rozwiązanie z 2 bitami stopu

    -Jak w inny sposób dosynchronizowywać komunikacje, czy to możliwe?

    0 29
  • #2 14 Sty 2016 11:01
    jankol-el
    Poziom 20  

    Może jakiś bit parzystości? CRC?

    0
  • #3 14 Sty 2016 11:25
    BlueDraco
    Specjalista - Mikrokontrolery

    Czy w strumieniu danych są przerwy? Ew. jak długie są paczki danych wysyłane kolejno bez odstępów? Proponuję skrócić do max 40..60 bajtów.

    0
  • #4 14 Sty 2016 11:52
    SowerOfWind
    Poziom 17  

    Bit parzystości jest zarezerwowany na późniejsze zakłócenia wynikające z eksploatacji. Dane są wysyłane bez przerwy bo tak w przyszłości będzie to pracować (kwestia kompatybilności wstecznej).

    To nie jest jakiś problem kluczowy, ale chciałbym go maksymalnie ograniczyć albo całkowicie wyeliminować. Testy wykazały, że problem (sprzętowo) na pewno leży po stronie komputera. I chcę programowo go wyeliminować.

    Na 99% rozwiążą go 2 bity stopu, ale zastanawiam się czy mogę zrobić jeszcze coś od strony uC.
    Nie jest to problem rezonatora uprzedzając podejrzenia kolegów, ponieważ w jego miejsce jest podłączony (prawie) idealny generator.

    0
  • #5 14 Sty 2016 16:43
    BlueDraco
    Specjalista - Mikrokontrolery

    Myślę, że 2 razy się mylisz. Odpowiedz dokładniej na pytania.

    Interfejs UART nie może działać poprawnie przy ciągłej transmisji danych - muszą być przerwy. To jest powód Twoich problemów, a nie wydumany feler PC ani jeden bit stopu.

    0
  • #6 14 Sty 2016 18:04
    94075
    Użytkownik usunął konto  
  • #7 14 Sty 2016 18:13
    BlueDraco
    Specjalista - Mikrokontrolery

    Tak, timingi - wystarczy spojrzeć.

    Po czym odbiornik może rozpoznać bit startu, gdy zostanie włączony po rozpoczęciu transmisji przez nadajnik?

    Co się stanie, gdy odbiornik będzie miał zegar o 1/n wolniejszy od nadajnika i zostanie przetransmitowanych n/2 bitów?

    0
  • #8 14 Sty 2016 20:08
    Marico
    Poziom 19  

    BlueDraco napisał:
    Tak, timingi - wystarczy spojrzeć.

    Po czym odbiornik może rozpoznać bit startu, gdy zostanie włączony po rozpoczęciu transmisji przez nadajnik?


    Przecież to oczywista oczywistość, nie sądzę aby problem autora był zwiazany z włączeniem się ad hoc odbiornika (w trakcie) co powoduje błędną transmisję. Błąd występuje w jej środku.
    Autor wątku użył sformułowania "komunikacja". Skoro to komunikacja to powinna to być
    świadoma, obustronna wymiana danych, przy której odebranie czegoś z błędem nie jest problemem, bo strona zawsze może poprosic o powtórzenie.Tak z reguły rozwiązuje się takie problemy.

    0
  • #9 14 Sty 2016 20:29
    BlueDraco
    Specjalista - Mikrokontrolery

    Problem Autora wynika zapewne z braku przerw w transmisji - łącze UART nie ma prawa poprawnie działać w takich warunkach - występuje ten drugi przypadek (pierwszy też).

    0
  • #10 14 Sty 2016 22:39
    SowerOfWind
    Poziom 17  

    Problem nie wyniki z braku przerw! Komunikacja działała przez wiele dni na komputerach starszego typu. Problem pojawiał się na nowszych płytach głównych.

    Nie ma potrzeby stosowania przerw, od tego jest bit startu aby rozpoznać kolejną ramkę. Brak przerw ma pośredni wpływ na błędy. Układ nie ma "czasu" się dosynchronizować, liczę na to, że przy 2 bitach stopu będzie miał czas to zrobić. W nocie dotyczącej UARTU do PIC32 jest mowa (a raczej jest schemat stanów logicznych), że synchronizacja trwa tyle co jeden bit, w przypadku rozsynchronizowania się układu (a przy relatywnie dużej prędkości - 19200 to się zdarza) czas na synchronizacje będzie pomiędzy bitem stopu i bitem startu.

    Obecnie trwają testy z dwoma bitami stopu.

    0
  • #11 14 Sty 2016 23:09
    94075
    Użytkownik usunął konto  
  • #12 14 Sty 2016 23:17
    BlueDraco
    Specjalista - Mikrokontrolery

    Kolego, obawiam się, że nie rozumiesz działania UART. Odbiornik rozpoznaje koniec słowa po zadanej liczbie bitów stopu. Jeśli ustawisz 2 bity stopu, to odbiornik będzie wymagał tych dwóch bitów i po którymś kolejnym słowie wykryje framing error zamiast bitu startu. Twój sposób rozwiązania problemu mógłby zadziałać, gdyby nadajnik nadawał z 2 bitami stopu, a odbiornik wymagał jednego. Przy komunikacji dwukierunkowej jest to niemożliwe, chyba że wyrzeźbisz własny UART w FPGA.

    Powtórzę: przerwy w transmisji trwające min. czas potrzebny na transmisję jednego słowa (raz na jakiś czas, np. co kilkadziesiąt słów) są niezbędne dla poprawnego działania łącza UART.

    Bit startu nie jest pomalowany na czerwono i niczym nie różni się od żadnego innego bitu o wartości 0. Pewne rozpoznanie bitu startu następuje wtedy, gdy przez 10 okresów bitów linia był w stanie nieaktywnym. W rzeczywistym świecie trudno jest zagwarantować, że urządzenia po obu stronach interfejsu włączą się w tej samej chwili i pomyślnie zasynchronizują, gdy jedno z nich nadaje ciągle, na który to problem ktoś na tym forum wpada średnio raz na miesiąc ("ATmega nadaje w pętli 'A', a PC odbiera jakąś dziwną wartość").

    Ten problem nie ma NIC wspólnego z szybkością transmisji - występuje jednakowo przy każdej szybkości.

    Możesz to łatwo zweryfikować wprowadzając przerwy, o których mówię. Myślę, że gdybyś to zrobił - nie miałbyś więcej problemów, o których piszesz.

    żeby komunikacja działała pewnie konieczne są przerwy i potwierdzenia zwrotne, najlepiej z jakąś kontrolą poprawności rekordów/ramek, np. przez sumę kontrolną lub CRC.

    żaden bit parzystości Ci nie pomoże.

    Twoja sugestia, że UARTy we współczesnych komputerach się mylą, a kiedyś były dobre, jest, delikatnie rzecz ujmując, mało realistyczna.

    Albert: resynchronizuje, ale w najbardziej optymistycznym przypadku tylko do 1/16 okresu bitu. Inaczej nie istniałoby takei pojęcie jak "framing error".

    0
  • #13 14 Sty 2016 23:32
    94075
    Użytkownik usunął konto  
  • #14 14 Sty 2016 23:42
    BlueDraco
    Specjalista - Mikrokontrolery

    To, czy używa się kontroli poprawności, nie ma związku z ciągłością transmisji, a prawdopodobieństwem wystąpienia i ew. przewidywanymi skutkami przekłamań transmitowanych danych. Masz potrzebę - to używasz. Do obsługi konsoli znakowej z poleceniami wpisywanymi ręcznie kontroli poprawności raczej nie trzeba.

    Po zakłóceniu ciągłej transmisji nie złapiesz już w sposób pewny bitu startu.

    0
  • #15 14 Sty 2016 23:58
    94075
    Użytkownik usunął konto  
  • #16 15 Sty 2016 00:47
    2675900
    Użytkownik usunął konto  
  • #17 15 Sty 2016 07:17
    94075
    Użytkownik usunął konto  
  • #18 15 Sty 2016 09:32
    BlueDraco
    Specjalista - Mikrokontrolery

    albertb napisał:
    BlueDraco napisał:

    Po zakłóceniu ciągłej transmisji nie złapiesz już w sposób pewny bitu startu

    Po zakłóceniu można robić setki różnych rzeczy. Zarówno przy USART jak i przy każdym innym protokole
    zarówno szeregowym jak i równoległym. W realnym świecie jak piszesz takie zakłócenia występują.
    Sądząc z poprzednich postów autor ma tego świadomość. Zauważył tylko, że częściej taka sytuacja ma miejsce z nowymi komputerami niż ze starszymi. I chciałby to wyrównać.


    Prosty przykład: Transmitujemy bez przerw długi ciąg bajtów o wartości 0x05, format 8n1. Następuje błąd - przekłamanie (utrata) jednego bitu startu. Pomyślcie, Koledzy, co się stanie i zauważcie, że oprogramowanie nie ma szans dowiedzieć się o tym, że cokolwiek się stało, gdyż będzie odbierało długaśny ciąg bajtów o zupełnie innej wartości bez sygnalizacji jakichkolwiek błędów przez UART. Nie ma więc w tym przypadku żadnego sposobu na resynchronizację. Kiedykolwiek - do końca świata będzie błędny odbiór bez sygnalizacji błędu.
    Gdyby ciąg danych nie był tak monotonny i byłaby w nim jakaś informacja kontrolna, to i tak resynchronizacja na właściwym bicie startu będzie kwestią czystego przypadku - nastąpi albo nie, a jeśli nastąpi, to nie wiadomo, po ilu ramkach.

    Gdyby po ramce danych był odstęp, to poprawna resynchronizacja nastąpi przy następnej ramce.

    0
  • #19 15 Sty 2016 09:39
    94075
    Użytkownik usunął konto  
  • #20 15 Sty 2016 09:49
    BlueDraco
    Specjalista - Mikrokontrolery

    Bo nie ma związku.

    Deterministycznych szans nie ma. Może się najwyżej udać przez przypadek, bo być może po którymś bajcie poprawnie załapiemy bit startu po kilku wcześniejszych framing error. W przypadku opisanym powyżej (ciąg bajtów o stałej wartości) nie nastąpi to nigdy.

    Zresztą - bijemy pianę. Jeśli moja diagnoza problemu jest słuszna, to wprowadzenie przerwy w transmisji co kilkadziesiąt bajtów trwajaącej nie krócej, niż transmisja całego bajtu rozwiąże problem błędów. Jeśli nie jest słuszna - to nie rozwiąże. Czy Autor wątku wykaże się odwagą i sprawdzi, czy będzie wymyślał argumenty?

    0
  • #21 15 Sty 2016 10:10
    94075
    Użytkownik usunął konto  
  • #22 15 Sty 2016 10:30
    BlueDraco
    Specjalista - Mikrokontrolery

    Niestety, ten, kto nadaje, nie wiem że był błąd. Jak już się dowie, wystarczy , że NIE nada jednego bajtu.

    0
  • #23 15 Sty 2016 14:51
    94075
    Użytkownik usunął konto  
  • #24 16 Sty 2016 14:47
    SowerOfWind
    Poziom 17  

    Przepraszam, trochę kolegów wprowadziłem w błąd. Otóż w prawdziwych warunkach pracy będzie to transmisja rzędu 1 ramka co 10 sekund. Nic szczególnego, kupa czasu na synchronizacje i możliwość 5 krotnego powtórzenia ramki w przypadku wykrycia błędu.

    Natomiast w fazie testów staramy się stworzyć ekstremalne warunki i chcemy aby układ działał poprawnie jak to tylko możliwe. Dlatego wysyłamy dane bez przerwy zwiększając i zmniejszając "zapełnienie ramki".


    albertb napisał:
    Do autora:
    1. Testowałeś przejściówki USB/RS232?
    2. Jeśli jak piszesz generator w PIC jest "idealny" to może w PC nie jest. Zmierz. W końcu to interfejs "legacy"
    3. 19200bps raczej trudno nazwać dużą prędkością.


    1. tak, działa bez zarzutu, aczkolwiek testy trwały krócej no i wykorzystanie tego typu rozwiązania odpada (tak jak pisałem kompatybilność wsteczna)

    2. Oczywiście, że w PC nie jest idealny ale tak jak już powiedziałem starsze komputery tolerowały ten rozrzut a nowsze niestety nie.

    3. Oczywiście, ale można nazwać to prędkością przy której omawiane problemy mogą już zaistnieć.

    BlueDraco napisał:
    Twoja sugestia, że UARTy we współczesnych komputerach się mylą, a kiedyś były dobre, jest, delikatnie rzecz ujmując, mało realistyczna.

    Niestety to nie jest sugestia tylko fakt potwierdzony eksperymentalnie. Nie wiem czy wynika to z traktowania po macoszemu UARTu czy występowanie czegoś innego w nowych pecetach mającego wpływ na UART.

    Precyzując problem. Sprzęt kiedyś pojedzie w teren i spotkają go wszystkie niemożliwe, wydumane i niespotykane dotąd zjawiska i stąd te restrykcje.

    Nota katalogowa dotycząca UARTu w PICu

    Chodzi mi o stronę 28, czy ktoś może mi wytłumaczyć jak działa Auto-Baud Support oraz Break Detect Sequence i czy mogę to w jakiś sposób wykorzystać? Czy ktoś to implementował?

    0
  • #25 16 Sty 2016 16:57
    2675900
    Użytkownik usunął konto  
  • #26 16 Sty 2016 20:02
    SowerOfWind
    Poziom 17  

    Tak jak pisałem, przepraszam za wprowadzenie w błąd, w praktyce będą przerwy.

    Dziękuję za podpowiedź związaną z algorytmem, zobaczę czy mogę go w jakiś sposób wykorzystać.

    Jeszcze jedno pytanie, czy czas synchronizacji trwa jeden bit tak jak to wynika z rysunku?

    0
  • #27 16 Sty 2016 20:10
    2675900
    Użytkownik usunął konto  
  • #28 16 Sty 2016 21:00
    BlueDraco
    Specjalista - Mikrokontrolery

    Do poprawnej transmisji przez UART wystarcza, że zegar nadajnika i odbiornika różnią się mniej niż 4%, POD WARUNKIEM, że są przerwy. Zwykle przyjmuje się, że zegary nie powinny się różnić bardziej niż o 2%. Nie sugerujesz chyba, że częstoliwość zegara w nowych PC jest odchylona od nominalnej o więcej niż 2%?

    Ramki nie powinny być dłuższe niż kilkadziesiąt bajtów. Jeśli dopuszaczasz zakłócenia - ramka powinnabyć zapezpieczona sumą kontrolną i potwierdzana przez odbiorcę (w tym czasie nadawca czeka na potwierdzenie, więc masz gotową przerwę w transmisji.

    Założę się, że w takim przypadku w warunkach "pokojowych" nie będziesz miał żadnych błędów transmisji, niezależnie od tego, jak nowego peceta weźmiesz, o ile twój RS232 nie wychodzi z przejściówki z fatalnym PL2303 albo lubianym przez wszystkich FT23x.

    0
  • #29 16 Sty 2016 21:06
    grko
    Poziom 33  

    @BlueDraco Co ile bajtów powinny być te przerwy? Ile powinna trwać?

    0
  • #30 16 Sty 2016 21:17
    94075
    Użytkownik usunął konto