MAX485 i Raspberry Pi

[cyryllo]

marek1707, Cieszę się że jesteś taki obeznany w temacie i mądry - szacun.

Naprawdę podłączyłeś nowo objawiony RTS do wejścia DI transceivera?

Przepraszam miało być do DE

Jestem administratorem systemów unix i potrafię tez programować a elektronika interesuję się z pasji od jakiegoś pół roku. Zaczynałem od prostych rzeczy.

Przygotowałem już płytkę dla KLIENTA wraz z oprogramowaniem z użyciem usb<>RS485. Kwestia tego, że chciałem sprawdzić czy można podpiąć się bezpośrednio pod piny UART na malinie bez używania USB. Zazwyczaj korzystam z gotowców (gotowych modułów) bo jest łatwiej i prościej zwłaszcza na początku. I tak robię to za kasę ale nie jest to towar końcowy, bo nie czuję się na tyle dobry w tym temacie aby wcisnąć coś takiego klientowi. Moim zadaniem jest sprawdzenie możliwości czy RPi podoła kilku zadaniom. Mam już wszystko co trzeba ,ale chciałem być bardziej dociekliwy i sprawdzić czy można użyć układu do 485 i się połączyć. W kolejnym etapie będzie już projekt płytki końcowej i do tego na pewno będę polecał jakiegoś specjalistę. Jeśli czujesz się na sile to mogę Cie polecić.

Sam często pomagam początkującym na forach głownie IT i nie mówię im aby dali sobie spokój czy nie nadają się do tego. Sami o tym zdecydują. Myślę że twoja wiedza i doświadczenie na takie błahe dla ciebie pytania działają negatywnie i masz do tego prawo. Tak czy siak i tak dziękuję za poświęcony czas i podpowiedzi.

Oczywiście przeczytałem podane przez ciebie artykuły

A zleceniodawcą jest sam elektronikiem, tyle tylko że nie ma doświadczenia z programowanie i systemami i od tego głownie mu jestem potrzebny.

[marek1707]

Widzisz, nie martwi mnie to, że czegoś nie wiesz bo to normalne, nie można być dobrym we wszystkim. Ja nie mam pojęcia o programowaniu w Javie, Phytonie, o robieniu nowoczesnych stron internetowych ani o konstrukcji wtryskiwaczy w moim samochodzie. Irytuje mnie jednak brak postępu. Popatrz: tydzień temu napisałeś o kupnie MAX485 i problemach z jego podłączeniem a wczoraj piszesz o następnym scalaku i post jest w bardzo podobnym tonie. Jak mam rozumieć zupełnie na oślep podłączane do Maliny druty i wciąż te same pytania? To znaczy, że albo niczego przez ten tydzień nie przeczytałeś albo nie zrozumiałeś. Potrafisz przedłożyć jakieś inne, trzecie wytłumaczenie? Zamiast rozkminiać sposób działania transceivera i całej trójstanowej, różnicowej magistrali RS485 na poziomie warstwy fizycznej, błądzisz jak dziecko we mgle. Gdyby to, co przeczytałeś dotało do Ciebie, podłączyłbyś układ w 5 minut a dzisiaj zadawał już pytania na poziomie zaawansowanym: Jak zmierzyć impedancję kabla?, Jak dobrać terminator? Jak spwodować, by w okresach nieaktywności nadajnika odbiorniki widziały stan SPACE? itp a być może byłoby już coś o wykrywaniu konfliktów itp. A tu nic, przedszkole. To co ja mam myśleć? Czy Twoja półroczna elektronika opiera się na metodzie prób i błędów? To nie są jakieś badania naukowe gdzie wynik może być nieprzewidywalny i czasem łut szczęścia doprowadza do sukcesu. To trywialny układ sprzętowy, wystarczy skopiować istniejące rozwiazania. Podłączyłeś RTS i co, przesłałeś ramkę danych? Doszedł ostatni bajt? Doszło cokolwiek? Nic nie wiemy. Nie opisujesz szczegółowo ani układu badanego, ani wyników Twoich eksperymentów, tylko swoje odczucia:

"Wydaje mi się że RTS nie steruje do końca..",
"Chciał bym aby transmisja była wykrywana i automatycznie puszczała"

"Zaś RO przez rezystor do GND"

Rozumiesz coś z tego??? A przecież to tylko cytaty z jednego postu. Komunikacja zamiast szumu.

Zamiast przypadkowego zlepku zdań napisz kilka porządnych odpowiedzi na kilka pytań:

Czy podłączyłeś transceiver dokładnie tak jak opisałem? Jeżeli nie, to jak? Dawaj schemat całości ze wszystkimi opornikami i kondensatorami, zasilaniami - to jest język elektroniki. Nie ma rzeczy nieważnych. Jaki masz kabel? Jaki będzie w docelowej aplikacji? Jak długi, jaki typ? Jakie przewidujesz prędkości? Czy masz terminatory? Rezystory asymetryzujące linie RS485 lub podciagające jakieś sygnały po stronie Maliny? Wszystko.

Acha, i nie polecaj mnie nikomu, proszę.

[cyryllo]

Użyłem jednak MAX3485 ze względu na to, że UART maliny działa pod 3,3V i nie zaleca się używania z wyższym napięciem.

Podłączyłem tak

RO (pin 1) -> RXD UARTa,

/RE (pin 2) <-stałe zero (GND)

DE (pin 3) <- RTS na pinie 31 Raspberry pi (z właczona opcja ALT3 - UART0_RTS)

DI (pin 4) <-TXD UARTa

oraz zasilanie do Pin 5 i 8 (GND, (3,3v)

Przy takim podłączeniu mam tylko możliwość zapisu/ustawienia rejestrów.

Próbowałem i łączyłem również /RE z DE <- RTS ale wtedy nie miałem żadnej komunikacji brak możliwości ustawienia rejestru

Użyty kable to zwykłe telefoniczne (również docelowo). długość 2 m.

Jakie przewidujesz prędkości?

nie większą niż 9600kb/s

Czy masz terminatory?

po stronie maliny nie

Rezystory asymetryzujące linie RS485 lub podciagające jakieś sygnały po stronie Maliny?

Nie

MAX3485 połączony jest linią A (pin 6) i B (pin 7) do płytki sterującej ogrzewaniem domowym. Płytka wygląda mi na konwerter z rs323 na rs 485.

A od niej kablem ze złączem telefonicznym 4 żyłowym podłączone jest do płytki z mikrokontrolerem , czujnikami i przekaźnikami (nie mojej płytki).

[marek1707]

Super, to nareszcie obaj wiemy o czym mówimy

Z mojego punktu widzenia połączenia Malina-transceiver są OK z dokładnością do polaryzacji sygnału RTS. Jeżeli jesteś pewien, że podczas nadawania Malina wystawia tam stan wysoki a gdy skończą się jej znaki i nadajnik zamiera - stan niski, jest dobrze. Możesz to sprawdzić miernikiem. Wyslij np. ciąg 1000 znaków co powinno przy 9600 (chyba jednak bitów/s a nie kb/s) zająć ok. 1 sekundy a w tym czasie zmierz na RTS napięcie. Powinno być bliskie 3.3V podczas nadawania i spaść do zera po zakończeniu transmisji.

Teraz musisz sprawdzić co znajduje się na płytce "przeciwnika". Podłącz jej zasilanie, podłącz (-) miernika do jej masy i zmierz napięcia na obu liniach RS485 w czasie, gdy płytka niczego nie nadaje a kabel jest odpięty od Twojego MAXa. Po pierwsze między liniami RS485 może być opornik terminujący - ma zwykle ok. 120-150 omów i przy tak krótkim kablu i małej szybkości transmisji nie będzie potrzebny. Jeżeli jest, trudno, niech zostanie. Jeżeli nie ma, też OK. Dużo ważniejsze w tym przypadku są oporniki desymetryzujące linie transmisyjne. Żaby sprawdzić czy coś takiego masz, zmierz napięcia na obu liniach interfejsu płytki. Gdy nadajnik płytki nie pracuje, nikt tymi liniami nie steruje więc napięcia powinny być prawie równe - choć nie dokładnie. Zmierz i napisz jakie one są. Na linii A powinno być delikatnie wyższe. To powinna być różnica 0.1-0.2V ale nie mniejsza. Większa jest OK. Dzięki tej utrzymującej się w stanie pasywnym różnicy, oba odbiorniki będą odbierały stan nieaktywny (SPACE, czyli jedynkę na wejściu UARTa) podczas gdy nikt nie nadaje. To ważne, żeby nie odbierać śmieci między transmisjami całych ramek. Tu masz prosty schemat podłączenia tych oporników, gdyby ich nie było. Wystarczy je zrobić po jendej stronie linii. Ten na środku (R3) to terminator. Już o nim pisałem:

Ponieważ masz /DE na stałe podłączone do stanu niskiego, odbiornik Maliny powinien dostawać to samo co nadajnik nadaje. Możesz zupełnie spokojnie bez podłączania do obcej płytki to sprawdzić. Wyślij z Maliny jakiś znany ciąg znaków i sprawdź, czy dokładnie to samo odebrałeś. Czy liczba znaków się zgadza, czy są identyczne itp. Jeżeli tak, to komunikację w dwie strony Malina-transceiver masz zrobioną. Teraz możesz podpiąć zieloną płytkę i sprawdzić, czy coś do niej dochodzi. Nie znam protokołu który tam obowiązuje ale zwykle jest to jakiś ciąg polecenia i ciąg odpowiedzi. Wyslij jakieś polecenie i sprawdź czy coś odpowiedziała. Dla pewności możesz podpierać się miernikiem, choć to marny sposób. Nadajnik wysyła w linię A dokładnie to samo co przychodzi z UARTa a w linię B stan odwrotny. Przy nadawaniu długich ciągów możesz mierzyć napięcia na liniach i zorientować się, czy zmieniają się sensownie. Ten rysunek (z Wikipedii zresztą) powinien wyjaśnić sprawę:

O sukcesach melduj, porażki rozwiązuj we własnym zakresie.

Żartowałem.

Jedno małe pytanie kontrolne: o co chodzi z tymi rejestrami? Co to znaczy: "Przy takim podłączeniu mam tylko możliwość zapisu/ustawienia rejestrów". A przy innym podłączeniu masz jakieś inne możliwości? Jakich rejestrów? Sterujących UARTem w Malinie? Przecież one "nie widzą" transceivera RS485 więc jaki jest związek tych rejestrów z kabelkami???

[cyryllo]

Jedno małe pytanie kontrolne: o co chodzi z tymi rejestrami? Co to znaczy: "Przy takim podłączeniu mam tylko możliwość zapisu/ustawienia rejestrów". A przy innym podłączeniu masz jakieś inne możliwości? Jakich rejestrów? Sterujących UARTem w Malinie? Przecież one "nie widzą" transceivera RS485 więc jaki jest związek tych rejestrów z kabelkami???

Z rejestrami chodzi o to że mikrokontroler zapisuje np wartości temperatur z czujników właśnie do rejestru o danym adresie w Pamięci. W tym rejestrze są też zapisywane wartości warunkowe np wartość minimalnej temperatury wody zaś kolejny trzyma np maksymalna temperaturę wody itd. Nie wiem jakiego typu jest ta pamięć ale znam adresy tych rejestrów w pamięci i wiem, które można odczytać, a które zmieniać i odczytywać równocześnie. I właśnie komunikuje się przez rs485 w celu odczytania i zapisu tych wartości. Tak przynajmniej ja to rozumiem

[marek1707]

Zaraz, zaraz, zaczynam jarzyć Czyli są to "rejestry" w procesorze na zielonej płytce? Czyli już po drugiej stronie kabelka! I jeśli piszesz, że możesz je zapisywć to oznacza, że transmisja przechodzi w jednym kierunku a jeśli możesz je pisać/czytać to w obu? Eureka... Rajciu, w życiu nie widziałem tak zakręconego sposobu opisu.

No dobra, czy to znaczy, że komunikacja działa tylko w jedną stronę? No to miernik do ręki i sprawdzasz działanie RTS. Bo jeśli umiesz nadawać całe ramki to znaczy, że na pewno w czasie nadawania RTS jest wysoki ale czy opada na 0? Sprawdź to. Jeżeli opada, to czy kompletnie nic nie odbierasz (ani znaku?) czy jednak coś, ale nie wygląda to na prawidłową ramkę i w związku z tym jest łykane przez jakieś niższe warstwy protokołu a Tobie dostarczany jest komunikat np. timeout lub checksum error?

Mam wrażenie, że posługujesz się protkołem typu Modbus bo tam są właśnie taki "rejestry" w urządzeniach poprzez jakąs biliotekę która robi tak dużo, że nie masz wcale bezpośredniego kontaktu z UARTem i nie jesteś w stanie wysłać dokładnie tego co potrzebujesz do testów łącza ani też nie wiesz tak naprawdę co się z odbiornikiem dzieje po wysłaniu polecenia odczytu "rejestru". Czy tak?

[cyryllo]

3xTAK

Tak połączenie jest w jednym kierunku (diody świecą przy komunikacji na tamtej płytce)

Tak dostaję checksum error.

Tak używam protokołu modbus-a za pomocą C i libmodbus.

Jak będę w domu to sprawdzę miernikiem pin z RTS i dam znać.

[marek1707]

Niepokoją mnie jeszcze dwie rzeczy (a chyba nawet więcej):

1. Napis na zielonej płytce "RS485 OUT". Czyżby obok drugiego złącza był napis "RS485 IN"? Jeżeli tak, to czy to oznacza, że płytka jest jakoś "zezworkowana" na pracę 2-przewodową skoro już Ci to działało z PC - jak rozumiem, także w wersji 2-drutowej? Dwa osobne złącza RS485 In/OUT wskazują bowiem na interfejs 4-przewodowy.

2. Czy masz wspólną masę między urządzeniami. Napisałeś o połączeniu tylko liniami A i B albo coś przeoczyłem.

W protokole Modbus ramki idą w systemie półdupleksowym: jedna (zapytanie) od Mastera do zaadresowanego Slave'a i odpowiedź (potwierdzająca, że wszystko poszło OK lub też, że nie) w kierunku przeciwnym. Między ramkami powinno być min. kilka milisekund odstępu właśnie po to, by jeden miał czas "zwolnić" szynę a drugi bezkonfliktowo ją "zająć". W tym czasie Master powinien więc wycofać swoje RTS odblokowujące jego nadajnik a Slave - gdy już będzie gotowy z odpowiedzią, odpalić swój i wysłać odpowiedź. W Malinie nie ma fajnego, sprzętowego RTS a już na pewno nie działa ono w ten sposób. Jak zrozumiałem dokumentację, włączenie sprzętowej obsługi RTS powoduje, że staje się ono de facto sygnałem RTR (Ready-to-Receive) i nie ma nic wspólnego z żądaniem nadawania. Kompletna kaszana, szkoda.

Biblioteka libmodbus musi więc robić to programowo i teraz pytanie: jak? Skąd ona wie na którym pinie I/O ma wystawić załączanie nadajnika RS485? Czy jakoś jej to przekazałeś? A może po prostu ustawia "na siłę" wyjście RTS UARTa poprzez jego rejestr sterujący a to, już odpowiednio mapowane przez wybraną konfigurację PIO trafia na używany przez Ciebie pin?

I po drugie: czy włączyłeś tryb

modbus_rtu_set_rts(DBUS_RTU_RTS_UP)?

Być może o tym coś pisałeś, przepraszam, jakoś to do mnie nie dotarło.

Acha, i po trzecie: Być może zachodzi sytuacja, w której znaki odbierane w trakcie nadawania z powrotem przez UART Maliny jakoś "ogłupiają" bibliotekę - choć wydaje się to nieprawdopodobne, traktuje ona swoje własne zapytanie jak błędną odpowiedź? Być może wywalanie na śmieci własnego zapytania odbywa się poprzez przestawienie na tryb RS485:

modbus_rtu_set_serial_mode(MODBUS_RTU_RS485)

ale dokumenacja jaką mam jest tak uboga, że nic więcej nie mogę z niej wyczytać. Gdyby tak było, trzeba będzie jednak zewrzeć DE z /RE i tym samym blokować własny odbiornik podczas nadawania zapytania.

EDIT: I ostatnie, najsmutniejsze przypuszczenie jest takie, że Modbus ze swoimi wymaganiami czasowymi i programowo sterowanym wyjściem RTS na malinowym Linuxie działać nie będzie. Jak się okazuje, nie Ty pierwszy masz z tym protokołem problemy z powodu zbyt dużych opóźnień wprowadzanych przez system. Czytałem raporty użytkowników w których to działało lub nie, w zależności od liczby innych zadań współbieżnie pracujących w systemie i ich priorytetów. Wyjście RTS było zbyt późno zerowane po nadaniu ramki i "wchodziło" na odpowiedź, niszcząc jeden lub kilka pierwszych jej znaków. Wtedy jedynym wyjściem jest rzeczywiście "wsparcie sprzętowe" w postaci przerzutnika monostabilnego. Zgroza, mając 800MHz procesor nie nadążamy za zdarzeniem w 1ms... Ręce opadają.

[cyryllo]

Zmierzyłem wczoraj linie a i b

A ma 2.84V, zaś B 1,43V

Sprawdziłem również RTS hardware-owy na malinie ale niestety nie zmienia się dlatego nie ma komunikacji. Cały czas jest 0V (Na forum RPi inni maja ten sam problem). Jak podniosę ręcznie pin 31 to działa tylko TX

marek1707,

ad1. Tak jest tam również RS485 IN

Komunikację dobrą mam na USB<>RS485 z RPi podłączam tylko kable A i B bez wspólnej masy. Z tym donglem działa bardzo dobrze. Nie musiałem martwić się o przełączanie RTS/kierunku, na USB<>RS485 działa to automatycznie.

modbus_rtu_set_rts(MODBUS_RTU_RTS_UP) nie mogę włączyć bo przy kompilacji dostaję informacje

error: ‘MODBUS_RTU_RTS_UP’ undeclared (first use in this function)
simple_client.c:44:31: note: each undeclared identifier is reported only once for each function it appears in

A zainkludowane mam:

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <modbus.h>
#include <modbus-rtu.h>

[OldSkull]

cyryllo, a jesteś w stanie sprawdzić czy obsługa RTS w ogóle jest włączona w programie? Czy zmienia się podczas otwarcia portu?

[cyryllo]

cyryllo, a jesteś w stanie sprawdzić czy obsługa RTS w ogóle jest włączona w programie? Czy zmienia się podczas otwarcia portu?

Wygląda na to że nie działa. Wygląda na to że muszę włączyć, ale nie mogę skompilować programu jw.

[marek1707]

Fajnie, że sterowanie kierunkiem w ogóle działa - zrobiłeś interfejs RS-485 Niestety problem leży po stronie ułomnego oprogramowania.

Przydałaby się informacja skąd masz bibliotekę, bo jak widzę jest kilka możliwości. Np. tutaj:

http://www.modbusdriver.com/doc/libmbusmaster/modbus.html

piszą tak:

The protocol does not define a physical network layer. Modbus works on different physical network layers. The ASCII and RTU protocol operate on RS 232, RS 422 and RS 485 physical networks

co napawa nadzieją, ale za chwilę jest już gleba:

To utilise the multi-drop feature of Modbus, you need a multi-point network like RS 485. In order to access a RS 485 network, you will need a protocol converter which automatically switches between sending and transmitting operation

bo to oznacza, że ta biblioteka Modbus nie zajmuje się warstwą fizyczną i co najwyżej korzysta w wysyłania/odbierania pojedynczych znaków. Kontrola kierunku transmisji w dwuprzewodowej magistrali RS485 jest pozostawiona do implementacji we własnym zakresie. Otwartym tekstem napisali, że potrzebny jest konwerter samodzielnie wykrywający i ustawiający kierunek transmisji.

Jeżeli w Twoich plikach .h nie ma odpowiedniej stałej to znaczy, że jest tak samo - nie przewidziano sterowania kierunkiem transmisji.

Inny przykład Modbus'a jest dokładnie odwrotny:

https://github.com/stephane/libmodbus/blob/master/doc/modbus_rtu_set_rts.txt

co oznacza, że może być tak i tak. Natychmiast powstaje następne pytanie: jak odpowiednia funkcja biblioteczna komunikuje się z pinem RTS bo przecież nie wie jaki UART jest w tym konkretnym systemie i jak do stanu RTS się dobrać. Jeżeli jest jakaś pośrednia warstwa drivera UARTa, która taką usługę udostępnia, to OK.

Jeżeli jesteś zdecydowany używać tej biblioteki którą masz, to wypada ją załatać jeśli czujesz się na siłach lub.. zrobić sprzętową kontrolę kierunku transmisji - nie pierwszy raz trzeba będzie poprawiać kiepskie oprogramowanie wstawką sprzętową Oburzonych programistów śpieszę pocieszyć, że odwrotne przypadki zdarzają się równie często

Jeżeli masz 555 lub jakiś przerzutnik Schmitta z serii 74.. np. 74x14 lub 74xx132 to możesz to zrobić od ręki.

[cyryllo]

Przydałaby się informacja skąd masz bibliotekę

Biblioteka oficjalna z repozytorów libmodbus

Jeżeli masz 555 lub jakiś przerzutnik Schmitta z serii 74.. np. 74x14 lub 74xx132 to możesz to zrobić od ręki.

Mam NE555 i chyba z serii 74 tez

[ Dodano: 06-12-2013, 00:25 ]

Poczytałem trochę o układzie 555 i mam pytani czy o moich potrzeb ze serowaniem mam go podłączyć w trybie mnostablinym czy bistabilnym?

Nie wiem czy dobrze zrozumiałem, że stan bistabilny zapamętuje stan i go utrzymuje aż się nie zmieni na inny?

[marek1707]

555 może pracować w trzech podstawowych trybach a Tobie potrzebny jest monostabilny. W tej konfiguracji każde zbocze opadające podane na wejście TRIG będzie wyzwalało generację impulsu wyjściowego. Ponieważ UART ma normalnie stan wysoki a dopiero podczas nadawania znaku pojawia się tam coś innego - w szczególności bit startu o wartości zawsze równej zero a potem no to już zależy co się nadaje, to 555 wydaje się idealny. Niestety tak nie jest. W wolnej chwili napiszę dlaczego. Proponuję zatem coś innego: czy masz 74HC14? To 6 inwerterów z wejściem Schmitta, czyli z histerezą. Na trzech takich bramkach, tj. na połowie układu 74HC14 możesz zrobić idealny układ sterowania kierunkiem transmisji. Acha, zamiast HC14 może być 74HC132 - ma to samo (histereza!), ale w postaci bramek NAND. Będzie jeszcze potrzebna jakaś mała dioda i układ RC ze stałą czasową rzędu 1-2ms.

[cyryllo]

Hej

Tak mam układ 74HC14N więc powinien pasować.

Oprócz ww i NE555 mam też ULN2803

Z tego co czytałem to NE555 nie działa do końca dobrze i przez to jest dużo błędów przy komunikacji.

Jeśli byś był w stanie podpowiedzieć jak użyć 74HC14N był bym wdzięczny.

Sam poczytam o tym układzie aby wiedzieć jak działa.