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

[c] Jak sprawdzić odbiór danych na RS485 bez zakłócania transmisji?

Andrzej.Woo 18 Lut 2012 23:59 3330 20
REKLAMA
  • #1 10565645
    Andrzej.Woo
    Poziom 9  
    Jak sprawdzić, czy kontroler odbiera aktualnie dane, czy nie? Nie chodzi o jeden bajt, tylko chcę wysłać dane ale nie chcę "przeszkadzać" przerywając ew. odbiór.
  • REKLAMA
  • #2 10565913
    RomanFilipecki
    Poziom 18  
    Może najprościej zasygnalizować odbiór zmieniając stan jakiegoś wolnego portu w procedurze obsługi uart? A dalej oscyloskop, próbnik stanów logicznych, miernik.
    Roman
  • REKLAMA
  • #3 10566042
    Andrzej.Woo
    Poziom 9  
    To jest RS485 czyli ma tylko 2 druty i oba sygnałowe, a w dodatku transmisja jest asynchroniczna. Układ cały czas jest nastawiony na odbiór (co nie znaczy, że odbiera), ale od czasu do czasu musi coś nadać. Chodzi o to, żeby nie przełączał na nadawanie jeśli w buforze odczytu jest jakiś nieprzeczytany bajt, a rejestr jest w trakcie odbierania następnego. Tryb master-slave czyli odpytywanie nie wchodzi w grę.
  • REKLAMA
  • #4 10566147
    kamyczek
    Poziom 38  
    Może warto poświęcić chwilę na odebranie potwierdzenia . Sprawa jest dość prosta wysyłasz bajt oznaczający początek ramki potem kilka bajtów danych i jakąś sumę , potem czekasz na odp. jeśli suma ok to jedna wartość jeśli źle ,to wysyłasz jeszcze raz dane . Albo nadajesz jeden i czekasz na zwrócenie tego samego bajtu ...
  • #5 10566335
    Andrzej.Woo
    Poziom 9  
    To jest tylko obejście problemu, a nie rozwiązanie. Wyjaśnię może więc łopatologicznie o co mi chodzi.

    uC generuje 3 przerwania:
    SIG_UART_DATA - po każdym nadanym bajcie, UDR gotowy do ponownego zapisu
    SIG_UART_TRANS - po zakończeniu transmisji nadawania, wykorzystywane w celu przełączenia się na odczyt RS485
    SIG_UART_RECV - po każdym odebranym bajcie, UDR gotowy do odczytu

    Brakuje mi możliwości sprawdzenia czy rejestr przesuwny odbiornika jest w trakcie odbioru danych czy może stoi i nic nie odbiera. Chciałbym, żeby program nie wcinał się z wysyłaniem danych w momencie kiedy rejestr odbioru jest aktywny i właśnie coś odbiera.

    Potwierdzanie komend to normalna rzecz i to już dawno mam zaimplementowane w protokole komunikacyjnym. Chodzi tylko o to, żeby układ wstrzymał się z nadawaniem na czas zakończenia odbierania. Od tego są bufory danych, żeby mógł poczekać. Brakuje mi tylko czwartego przerwania/flagi - odpowiednika przerwania SIG_UART_TRANS (Transfer Complete) dla odbioru. To, że odebrałem jeden bajt nie oznacza, że nie nadchodzi właśnie następny i mogę się wciąć z transmisją. Pakiety danych są dosyć długie po kilkaset bajtów z tym, że uC nadaje sam z siebie dane (mały bufor) do komputera i w międzyczasie nasłuchuje czy nie przyszły nowe rozkazy. Danych jest zbyt dużo (i są zbyt ważne) by je potwierdzać po stronie PC (przez uC są potwierdzane).

    [c] Jak sprawdzić odbiór danych na RS485 bez zakłócania transmisji?
  • #6 10566739
    Konto nie istnieje
    Konto nie istnieje  
  • #7 10566961
    Andrzej.Woo
    Poziom 9  
    Hm... not so fast. Na linii Rx cały czas utrzymuje się stan wysoki, a w czasie odbioru - niski. Fazę dałoby się odwrócić, ale jest to tylko półśrodek.
    Mnie interesuje bardziej flaga w rejestrze która będzie mnie informować o aktywności rejestru szeregowego odbierającego dane, a nie o gotowości UDR.
  • #8 10567168
    Konto nie istnieje
    Konto nie istnieje  
  • #9 10567718
    Andrzej.Woo
    Poziom 9  
    Przerwanie Overflow (to ono generuje transmisję niepotwierdzaną) i oby dwa piny INT0 i INT1 są już zajęte w uC.
  • #10 10567970
    Mundi1970
    Poziom 24  
    Andrzej.Woo napisał:
    Potwierdzanie komend to normalna rzecz i to już dawno mam zaimplementowane w protokole komunikacyjnym. ............... To, że odebrałem jeden bajt nie oznacza, że nie nadchodzi właśnie następny i mogę się wciąć z transmisją.

    Wydaje mi się że wysyłający dane, można podać ilość wysyłanych bajtów na początku transmisji. Na podstawie tej wartości jesteś wstanie określić koniec transmisji :).
  • #11 10568396
    RomanFilipecki
    Poziom 18  
    Jeśli używasz 485 to masz transmisję Half Duplex. Ile masz masterów w sieci 485?. Jeśli masz jednego to slave odpowiada na zapytanie mastera i problem nie ma prawa wystąpić.
    Master ustala momenty zapytań a przez to odpowiedzi.
    Jeśli więcej to rywalizacja jak w starym eth.
    Roman
  • #12 10568697
    Konto nie istnieje
    Poziom 1  
  • #13 10569209
    Andrzej.Woo
    Poziom 9  
    Gdyby to była typowa transmisja RS485, to nie miałbym żadnych wątpliwości i na forum nie szukałbym pomocy. Napisałem wyraźnie, że typowy tryb odpytywania master-slave nie wchodzi w grę, ale spodziewałem się, że i tak znajdą się tacy, do których ta informacja nie dotarła.

    atom1477 napisał:
    To na Twój problem ne ma rozwiązania.
    Taka już jest natura RS485.

    Mylisz się. Wystarczyłoby przerwanie/flaga pochodząca od uC która informowałaby, że rejestr szeregowy jest w trakcie przyjmowania danych. Przerwanie mówiące o gotowości odebranych danych to dla mnie za mało. Dane idą przecież strumieniem, więc wielkim problemem nie byłoby przełączenie odpowiedniej flagi po 2 dodatkowych cyklach zegara taktującego transmisję jeśli nie pojawia się bit startu nowej ramki.

    Pomysł Saabotaz jest dla mnie jedynym wyjściem z tej sytuacji, ale trzeba dostosować czas po którym ZAJĘTOŚĆ zostaje wyłączona do parametrów transmisji. Miałem nadzieję, że dzieje się to sprzętowo i nie trzeba będzie ręcznie kombinować.

    Jest to system mieszany kiedy jedna strona nadaje ciągle (99%), a przy okazji w wolnym czasie ten sam kanał transmisji wykorzystywany jest do przesłania dodatkowych rozkazów (1%). Master-slave odpada ze względu na ograniczenia w wielkości bufora uC, a to on jest źródłem danych. Poza tym po drodze może pojawić się kanał ethernetowy który wprowadzi dodatkowe dość duże opóźnienia i bufor nadawczy mógłby dość szybko się przepełnić jeśli w rozsądnym czasie nie napłynełoby potwierdzenie. Rozkazy od strony PC przychodzą rzadko, więc poczekanie chwilę na dokończenie odbioru nie przepełni bufora nadawania.
  • #14 10569382
    Konto nie istnieje
    Konto nie istnieje  
  • #15 10569952
    Andrzej.Woo
    Poziom 9  
    Saabotaz napisał:
    Andrzej - jeśli masz transmisję o stałej szybkości to w czym problem obliczyć wartość dla TCNT0 tak aby przepełnienie nastąpiło po czasie o długości 1,5 bajtu?

    Własnie nad tym siedzę :) Akurat używam już jednego RTC, ale są jeszcze dwa do wykorzystania więc damy radę. Muszę wykombinować wzór dla prescaler'a uwzględniający F_CPU, baudrate, ilość bitów etc. Damy radę. Podzielę się informacją o tym jak o działa.

    Dzięki za podsunięcie pomysłu.
  • #16 10570049
    Konto nie istnieje
    Poziom 1  
  • REKLAMA
  • #17 10570301
    Andrzej.Woo
    Poziom 9  
    Trochę pomyliłeś które urządzenie do czego służy (zajętość jest dokładnie odwrotna). owszem może się teoretycznie zdarzyć, że PC zacznie nadawać w tym samym momencie co uC ale... uwzględniając to co ja wiem, a wy nie wiecie temat okazuje się możliwy do obejścia.
    1. uC nadaje strumień dokładnie co 10 ms
    2. transmisja ustawiona jest na 230kbps czyli wystarczająco szybko
    3. długość strumienia to od 0-250 bajtów.
    4. PC potrzebuje od czasu do czasu (raz na kilka minut) zapytać się o inne kontrolne parametry, ale tylko na własne potrzeby, więc wciska pojedyncze rozkazy pomiędzy automatyczną transmisję danych
    5. Rozchodzi się o to, żeby ew. uC wstrzymał się na krótką chwilę z nadawaniem głównego strumienia jeśli PC nadaje właśnie jakiś rozkaz.
    6. w niektórych implementacjach najniższą warstwę komunikacyjną załatwia buforowany kontroler Ethernet-RS485/422 który automatycznie wykrywa ew. konflikty. Niestety jego zastosowanie wyklucza relację master-slave bo opóźnienia wykonania rozkazów mogą dochodzić do kilku sekund.

    Tyle powinno wystarczyć dla tych którzy czują niedosyt i oczekują dokładnego tłumaczenia i wyjasnainia "a po co mi to?"
  • #18 10570878
    Konto nie istnieje
    Poziom 1  
  • #19 10570887
    RomanFilipecki
    Poziom 18  
    Przepraszam ale Twoja komunikacja wygląda nieco chaotycznie. Wprowadzenie sztywnej reguły sterowania uprości Twoje zadanie. Piszesz że uc wysyła paczkę o długości od 0 do 250 bajtów co 10 ms. Może zamiast krótkiej paczki wysłać zapytanie do pc o treści "czy masz coś do powiedzenia" i w ten sposób załatwić problem?

    Roman
  • #20 10571061
    Andrzej.Woo
    Poziom 9  
    atom1477 napisał:
    A, no to było tak od razu napisać a nie atakować mnie za to co napisałem (bo cóż innego mogłem napisać skoro nie podałeś szczegółów).

    Ja potrzebowałem prostej informacji którą dość dokładnie wyłożyłem, a nie "rady" zmieniającej koncepcję całości. Wstęp byłby za długi i imho niepotrzebny. Ograniczyłem się tylko do tego co mnie interesuje. Master-slave został odrzucony i tego każdy uczestnik wątku powinien się trzymać (warunki graniczne). Mam nadzieję, że nikt z tego powodu nie poczuł się "urażony".

    RomanFilipecki napisał:
    Przepraszam ale Twoja komunikacja wygląda nieco chaotycznie.

    Tam nie ma żadnego chaosu! Jest urządzenie które ciągle nadaje informacje - i tak się robi. Po co ciągnąć jeszcze 2 druty przez pół kilometra i budować jeszcze jeden kontroler, żeby otrzymywać raz na jakiś czas dodatkowe kontrolne informacje na wyraźne żądanie. Zmiana parametrów kontrolera i tak następuje poprzez wysłanie komunikatu zatrzymania ciągłej transmisji, a potem ponownego jej włączenia. Nikt nie będzie jednak tego robił ręcznie.

    Bit parzystości w transmisji czy zastosowanie CRC też wyłącznie zwiększa prawdopodobienstwo wykrycia błędu - pewności nigdy nie ma. Czekając na zakończenie nadawania przez PC znacząco zwiększam prawdopodobieństwo uniknięcia konfliktu nadawania - pewności nigdy nie będę miał.

    Typowe rozwiązania są do typowych problemów. Po to każdy z nas kształcił się na inżyniera, żeby radził sobie również z tymi nietuzinkowymi i mógł poprawnie zastosować rozwiązania wykraczające w sposób bezpieczny poza ów standard.
  • #21 10637582
    Andrzej.Woo
    Poziom 9  
    Za radą kolegi Saabotaz zrobiłem opóźnienie przełączania się w tryb nadawania po zakończonym odbiorze bajtu. Rozwiązanie problemu wygląda następująco:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Działa doskonale, brak jest zakleszczeń czy innych zakłóceń transmisji.
REKLAMA