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

Komunikacja szeregowa wykorzystująca UART i RS485

26 Sie 2011 16:03 4561 22
  • Poziom 9  
    Witam,

    chciałbym zbudować sterownik modułowy który mógłby być wykorzystywany w maszynach w warunkach przemysłowych. Postanowiłem że poszczególne moduły będą komunikowały się za pomocą RS485. Poszukuję więc wszelkich informacji na temat RS485. Już trochę znalazłem ale jakby ktoś znał jakieś ciekawe strony bądź książki to byłbym wdzięczny za linki.
    Do prototypu chciałbym wykorzystać Atmege (8 bądź 16 jak będzie taka potrzeba), dane wysyłać i odbierać poprzez moduł UART. Jeden master odpytywałby odpowiedniego slave'a, kumunikacja typu half-duplex. Nie jestem pewny co do połączenia wyprowadzeń TXD i RXD do MAX485. Załączyłem szkic schematu rozwiązania o jakim myślę. Nie narysowałem zasilania gdyż narazie chciałem się zapytać o samo podłączenie magistrali. Opierałem się na artykule w EP „Klocki” RS485 http://www.cyfronika.com.pl/kityavt3/avt530pdf.pdf

    Zastanawiałem się też czy wogóle atmega podoła tego typu zadaniu. Być może nie ma sensu wogóle budować prototypu na atmedze i od razu robić to na czymś szybszym (np LPC2106).

    Czy w ogóle dobrze rozumiem sens tej komunikacji (w sensie UART <-> RS485)? Za wszelkie podpowiedzi z góry dziękuje.
  • Moderator Mikrokontrolery Projektowanie
  • Poziom 9  
    Skoro nikt mi nie potwierdził że schemat jest dobrze to ja sam potwierdzę (jest dobrze, przetestowałem na żywo).
    Atmega16, zewnętrzny rezonator kwarcowy 16MHz. Rzeczywiście max to 1Mbps.

    Teraz kolejne pytanie.
    Transmisja asynchroniczna działa bez problemu, natomiast jak chcę przesłać dane wykorzystując transmisje synchroniczną to odbierane są krzaki...

    Tak inicjalizuje master'a:
    Kod: C
    Zaloguj się, aby zobaczyć kod



    tak inicjalizuję slave'a:
    Kod: C
    Zaloguj się, aby zobaczyć kod


    funkcja wysyłająca dane:
    Kod: C
    Zaloguj się, aby zobaczyć kod


    linie xck oby dwóch uC połączone

    master cyklicznie wysyła znak 'a', 'b', slave wyświetla go na LCD. Bez synchronizacji działa pięknie, z synchronizacją wogóle.

    Pozdrawiam
  • Poziom 15  
    Mam pytanie dotyczące UART i RS485 jak można zrobić taki układ:

    dwie atmegi, dwie diody i dwa przyciski.
    przycisk zapala diodę w przeciwnym uC przez RS485.
    Jak rozwiązać problem zamiany pary slave-master na master-slave niejako dynamicznie?

  • Poziom 26  
    Ja też się dołączę, szukałem na forum, google też i nie znalazłem żadnego kodu + schematu z zapaleniem diody na 2 atmegach, codzi mi o kod w c
  • Poziom 33  
    wojtekr napisał:

    Jak rozwiązać problem zamiany pary slave-master na master-slave niejako dynamicznie?


    Zastosować topologię sieci tzw. token-ring. Master przekazuje swoje prawa (i przestaje być wtedy masterem) do nadawania (żeton) następnemu węzłowi (odbiornikowi) i tak dalej i dalej w kółko. Równie dobrym a może prostszym rozwiązaniem byłoby zastosowanie RS422.
  • Poziom 15  
    Rozważałem jeszcze możliwość sterowania centralnego pinami kierunku 75176, natomiast kierunek transmisji w atmegach robić software'owo- i tak układy będą połączone skrętką więc są wolne linie. Odległości do 40m.

    Zaglądam właśnie do "Szeregowe interfejsy cyfrowe" P. Wojciech Milczarka i nie kumam jak 422 ma pomóc w przeciwieństwie do 485- był bym wdzięczny za krótki wykład gdyż są to na razie dla mnie zagadnienia mocno tajemnicze.
  • Moderator Mikrokontrolery Projektowanie
    Zauważ, że dla dwóch układów rozróżnienie master/slave jest dosyć sztuczne. Realizujesz po prostu interfejs jako full duplex i odpadają problemy ze sterowaniem linii. W tym przypadku łączysz je np. po RS485 z wykorzystaniem dwóch par, a nie jednej - jedna łączy nadajnik pierwszego układu z odbiornikiem drugiego, a druga - odwrotnie. To właśnie jest RS422. Takie połączenie jest możliwe tylko w przypadku dwóch układów, czyli tak jak ty masz.
    Sterowanie kierunkiem potrzebne jest tylko wtedy, gdy robisz half-duplex, czego robić nie musisz.
  • Poziom 15  
    A co w przypadku 3x atmega i 3x komplet dioda-przycisk? Bo założyłem (raczej niesłusznie), że dla dwóch układów sytuacja jest taka sama jak dla wielu i nie napisałem, że układ docelowo będzie miał ich 12- :(
  • Moderator Mikrokontrolery Projektowanie
    To sytuacja się komplikuje. Z natury musisz wszystko podłączyć do wspólnej magistrali i trzeba rozwiązać jakoś arbitraż. W takiej sytuacji najprościej zrobić jednego mastera kontrolującego transmisję, wszystkie transmisje pomiędzy slave odbywają się za pośrednictwem mastera. Inaczej czeka cię implementacj aprotokołu multimaster, która łatwa nie jest.
  • Poziom 15  
    Ale o ile rozumiem zasadę takiej transmisji to jest problem z wymuszaniem kierunku. Jeżeli master nasłuchuje a slave'y nadają to jak wysłać do slave'a sygnał, który ma być reakcją na to co on nadał?
  • Poziom 33  
    wojtekr napisał:
    Jeżeli master nasłuchuje a slave'y nadają to jak wysłać do slave'a sygnał, który ma być reakcją na to co on nadał?


    To nie master nasłuchuje a slave'y. Master odpytuje po kolei wszystkie slave'y. Jeżeli któryś slave ma coś "do zrobienia" master dostaje odpowiedź od niego i odpowiednio reaguje. Jeżeli jeden slave będzie chciał coś "zrobić" w drugim slave to najpierw zgłasza to masterowi a master odpowiednio steruje tym drugim slave. Taka topologia magistrali (z jednym masterem) powoduje że wszystkie slave'y bez pytania nie mają prawa "głosu". To jest najłatwiejsze do implementacji programowej.... wykorzystując np: MODBUS'a.
  • Poziom 15  
    czyli:
    1 master wysyła
    2 master zmienia na odbiór
    3 slave odbiera
    4 slave zmienia się na nadawanie
    5 slave wysyła
    6 slave zmienia się na odbiór
    7 master odbiera

    Czy jest potrzebna jakaś kontrola (synchronizacja) czasu przełączania się Tx/Rx poszczególnych par urządzeń?
  • Poziom 33  
    wojtekr napisał:

    Czy jest potrzebna jakaś kontrola (synchronizacja) czasu przełączania się Tx/Rx poszczególnych par urządzeń?


    Jeżeli protokół komunikacji jest dobrze "napisany" i zaimplementowany to nie trzeba nic synchronizować, jeżeli tak nie będzie, to będą problemy (np: odpowiedź od slave'a może nadejść za późno i wtedy jak master w tym czasie "zajmie" magistralę to dane są nieprawidłowe.).
    Pamiętaj że master wysyła zapytanie "na magistralę" i trafia ona do wszystkich slave'ów, więc dany slave musi wiedzieć czy zapytanie jest do niego czy nie.
    Domyślnie wszystkie urządzenia muszą być w stanie "odbiór". Podczas nadawania wiadomo że uC muszą przełączyć driver'y na "nadawanie".
    Proponuję implementację MODBUS'a RTU. Koniec przychodzącej ramki sprawdzasz przez przepełnienie timera (za każdym odebranym bajtem timer jest "przeładowywany"). Po czasie 3,5-4t czasu trwania przesłanie jednego bajtu timer się przepełni co jest informacją że cała ramka jest w buforze i można ją analizować. Jeżeli CRC z całej ramki jest zgodne oznacza że ramka jest OK. Jeżeli pierwszy bajt != adresu to dane "nas" nie dotyczą, ustawiamy wskaźnik danych na początek bufora odczytu i czekamy na następne ramki.
  • Poziom 15  
    A można linie sterujące wszystkich 12 szt. SN751 podłączyć do jednego portu uC i dane wysyłać do wszystkich, nasłuchiwać od wszystkich ale nadaje tylko ten slave, którego adres będzie w bajtach wysłanych od mastera? Inaczej potrzebował bym 12 linii I/O lub jakiegoś expandera
  • Poziom 33  
    wojtekr napisał:
    A można linie sterujące wszystkich 12 szt. SN751 podłączyć do jednego portu uC i dane wysyłać do wszystkich, nasłuchiwać od wszystkich ale nadaje tylko ten slave, którego adres będzie w bajtach wysłanych od mastera? Inaczej potrzebował bym 12 linii I/O lub jakiegoś expandera


    Chyba nie rozumiesz zasady działania RS485. Każde urządzenie na magistrali (magistrala to żyły A i B) RS485 ma swój SN75176 (czy tam coś podobnego). Wszystkie linie A łączymy ze sobą i analogicznie linie B. Nie potrzeba Ci 12szt. driver'ów do mastera.
  • Poziom 15  
    Planowałem zrobić tak, że przy uC jest 12 SN751 i 12 AB do każdego slave z SN751. Dzięki temu uzyskuję topologię gwiazdy i mogę umiejscowić 12 slave'ów w dowolnych kierunkach od mastera. I wtedy jak rozumiem magistralą są linie pomiędzy uC i 12 SN751. Czyli coś w stylu huba RS485.

    Ale rozumiem, że powinno wyglądać to tak, że rozgałęzienie jest na liniach AB (czyli na całość idzie 12(S)+1(M) układów SN751) a przełączanie z odbieranie slave do nadawania slave jest uzależnione od adresu w zapytaniu mastera?

    Czy tu tez można zrobić gwiazdę- to znaczy jak można oddalić SN751 od magistrali RS485?
  • Poziom 33  
    wojtekr napisał:
    Ale rozumiem, że powinno wyglądać to tak, że rozgałęzienie jest na liniach AB (czyli na całość idzie 12(S)+1(M) układów SN751)


    Dokładnie tak. Stosowanie 12 driverów osobno do każdego slave'a może i jest dobre bo gdy coś będzie nie tak ze slave'm i zablokuje magistralę to zablokuje ją tylko sam dla siebie. Z drugiej strony rzadko kiedy takie sytuacje się zdarzają więc dokładanie następnych driver'ów podraża koszty (zakup elementów, większa płytka, wydajniejsze zasilanie etc.). Co do przełączania to tak jak pisałem wyżej czyli: urządzenie/uC przełącza driver tylko w momencie jak coś chce wysłać. Reasumując, jak master wysyła zapytanie to przełącza driver i wysyła dane, te dane trafiają do wszystkich slave'ów. Odpowiada tylko ten slave którego adres zgadza się z zapytaniem, reszta ignoruje zapytanie i czeka na następne.
  • Poziom 15  
    a co można zrobić aby temat był niezawodny- poza watchdog'ami w układach master i slave. Całością będzie sterował linux przez ethernet więc może jakiś dodatkowy reseter zasilania master i slave'ów? Jak wygląda to w rozwiązaniach przemysłowych?
  • Poziom 33  
    Jeżeli algorytm programu obsługi transmisji jest dobrze napisany to nic nie trzeba dodatkowo zabezpieczać. Pomijam sytuację gdzie wskutek np: jakiegoś przepięcia siada któryś z driver'ów SN75176 i blokuje całą magistralę....ale wtedy wiadomo że stało się coś poważnego i zdalnie tego naprawić nie można. Należy również pamiętać przy projektowaniu aby driver był automatycznie sprzętowo wysterowany na odbiór. Jeżeli magistrala będzie przebiegać w "ciężkim" środowisku można również pomyśleć o optoizolacji. Jak daleko będą oddalone slave'y od mastera?
  • Poziom 15  
    według informacji zawartych w sekcji: Multiple Cables dokumentacji:
    http://www.maxim-ic.com/app-notes/index.mvp/id/763
    nie powinno się rozgałęziać sygnałów AB. Więc chyba jedyne wyjście to do 12 slave'ów dać 12 układów S751 czyli po parze na slave'a. Pytanie co dać w ramach expandera portów żeby nie blokować 12 portów uC do sterowania kierunkiem transmisji?
  • Poziom 33  
    wojtekr napisał:
    według informacji zawartych w sekcji: Multiple Cables dokumentacji:http://www.maxim-ic.com/app-notes/index.mvp/id/763
    nie powinno się rozgałęziać sygnałów AB.


    No nie przesadzajmy :). Na pewno ma to znaczenie ale przy dłuższych odcinkach i szybszych transferach (których na AVR i tak się nie osiągnie). Przy 40-50m na upartego możnaby i zwykłego TTL puścić.