Dzień dobry,
piszę tutaj gdyż mam problem z połączeniem dwóch AVR Atmega8 za pomocą układów MAX485. Komunikacja half-duplex, przy czym na razie testuję połączenie master-slave, gdzie master wysyła co chwilę ramkę 10. bajtową do slave. Slave nic nie nadaje. MAX przy masterze jest ustawiony na nadawanie, a MAX przy slave na odbiór.
Jeżeli połączę te Atmegi poprzez proste skrzyżowanie RX i TX to nie ma żadnych problemów. Gorzej, jeżeli używam układów MAX485. Master co chwile dostaje jakieś "śmieci" mimo że nie powinien nic odbierać. (dioda nieregularnie mruga na przerwanie RXC, które nie powinno w masterze w ogóle występować). Nawet po odłączeniu od siebie Atmeg, gdy master nadaje w "eter" to i tak odbiera "śmieci".
Układ połączony jest jak na dołączonym schemacie. Z czego wynikają te przerwania RXC na masterze? Echo? Jest sposób by się ich pozbyć?

Bardzo liczę na pomoc, z góry dziękuję!

Informacje dodatkowe : zewnętrzne kwarce 16MHz, UBRR=3 (250kbps), Atmegi działają w trybie MPCM, łączone na płytce stykowej

Ło matko! a co kolega zrobił ? co to za rezystory R1 i R2 ??? to chyba jakiś kosmos - przede wszystkim to usuń je jak najszybciej i podłącz pin scalaka GND do masy bezpośrednio a nie takie coś. Potem znowu potestuj.

------------------------ [ Dodano po: 1 minucie ]

Wywal też na czas testów rezystory R6 i R7

------------------------ [ Dodano po: 2 minutach ]

na czas takich testów możesz nawet wywalić rezystor (terminator) R5

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dziękuję za szybką odpowiedź. Teraz układ połączony jest jak na dołączonym schemacie. Niestety master nadal coś odbiera. Może wina trefnej płytki stykowej?

No to teraz to juz nie szukaj w elektronice tylko w kodzie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Uprościłem maksymalnie kod dla obu Atmeg, dziwne jest teraz to, że nawet najmniejsze dotknięcie kabla łączącego RX mastera z MAX485 powoduje otrzymanie jakiegoś szumu, wywołanie przerwania RXC i miganie diodą. To samo po restarcie, dioda miga kilak razy przy masterze. Zjawisko takie nie wystepuje gdy połaczymy ATmegi bezpośrednio krzyżując RX i TX. Czy to wina standardu rs485?

Master:



SLAVE:

Używasz max 485 czy jakiegoś zamiennika? Może niezgodny pinowo zamiennik??

_________________
IntegraMETEO
WordCLOCK
IntegraTOUCH

Używam oryginalnego Maxim MAX485. Żeby nie było niejasności, Master wysyła i Slave odbiera, tylko te szumy na Masterze mi przeszkadzają. Gdy miałem bardziej zaawansowany kod m. in. z adresowaniem MPCM to też działało, dopóki nie pojawiało się właśnie takie zakłócenie/echo. Nie wiem jednak, czy taka czułość np. na dotykanie przewodów to nie jest właśnie przypadkiem "piękno" RS485.

Powiem Ci tak...
Jak myślisz? Dlaczego Rs485 jest tak popularny i wykorzystywany jako magistrale przemysłowe? Ze jest zawody i podatny na zakłócenia? Właśnie Rs485 jest na nie bardzo odporny.
Masz szumy i zakłócenia po dotknięciu kabla pomiędzy atmegą a kością max? Czyli się zachowuje jakby pin wisiał w powietrzu bez podciągnięcia...

_________________
IntegraMETEO
WordCLOCK
IntegraTOUCH

Tak się właśnie zachowuje. W takim razie jak temu zaradzić? Do Vcc przez R10k?

A czy na pewno masz tak jak na schemacie zrobione sterowanie nadawaniem (włączone na stałe)?

--
Pozdrawiam,
Robert

Tak, podłączone było na pewno dobrze. Po podłączeniu przewodu RX przez rezystor 10K do VCC komunikacja przebiega bez problemu nawet przy "majstrowaniu" przy tym kablu. Nie wiem tylko czy to jest prawidłowe rozwiązanie i czy później nie wynikną z tego powodu jakieś problemy.

Mam nieco podobny problem, więc pomyślałem, że nie będę zakładał nowego tematu.

Używam układu MAX3485 do komunikacji po RS485 na wbudowanym porcie ttyAMA0 w RaspberryPi 2 i jest to MASTER. W momencie, kiedy komunikowałem się z moją płytką sterującą opartą o Atmege169 - SLAVE, również korzystającej z tego samego chipu nie było problemów. W raspberry układem steruje GPIO4, a atmedze jeden z portów i wszystko śmiga.

Nie dawno zakupiłem urządzenie, które chcę wpiąć jako kolejnego SLAVEa do magistrali, ale niestety po kilku próbach i testach muszę stwierdzić, że urządzenie to odpowiada zbyt szybko i raspberry nie zdąża przełączyć GPIO na 0 po zakończeniu nadawania rozkazu, żeby przełączyć MAXa w tryb odbierania. Efektem tego jest ucięcie pierwszych bajtów ramki odpowiedzi ze SLAVEa. Urządzenie wiem, że jest sprawne, bo po wpięciu PC jako podsłuchu widzę, że na magistrali wszystkie dane wysyłane są prawidłowo. Komunikacja z SLAVEm mojej produkcji działa prawidłowo zapewne dlatego, że po przechwyceniu dobrze zaadresowanej ramki, mam w kodzie delay 20ms przed odesłaniem odpowiedzi. Skontaktowałem się z producentem zakupionego sprzętu i ma mi dać w przyszłym tygodniu informację, czy jest w stanie wprowadzić taki delay u siebie. Nie mniej jednak chciałbym się przygotować na najgorsze i obmyślić rozwiązanie alternatywne. Poczyniłem dziś testy i pin RE rozwarłem od GPIO, a następnie podłączyłem na stałe do GND. Efekt jest taki, że słyszę to, co sam nadałem, ale przynajmniej dodatkowo odbieram kompletną ramkę z zakupionego SLAVEa. To mogę już sobie odfiltrować softwarowo.

Moje pytanie brzmi, czy w związku, że i tak muszę robić przeróbkę płytki, aby rozewrzeć RE i DE, to czy dalej muszę sterować pinem DE w celu blokowania nadawania, czy mogę go zewrzeć na stałe do VCC, tak jak RE do GND i przez to zwolnić sobie jedno GPIO w raspberry? Przyznam szczerze, że brak konieczności sterowania MAXem okupiony tylko i wyłącznie softwarowym filtrowaniem otrzymanych danych byłby dla mnie sporym ułatwieniem także w innych projektach.

Pozdrawiam

@vietnam69
Moje pytanie dotyczyło czy masz na pewno tak jak na ostatnim zaprezentowanym schemacie zrobione sterowanie nadawaniem (włączone na stałe), bo Twój efekt jest poprawny dla trochę innej konfiguracji
Jeżeli używasz sterowania nadawaniem (a przy dwukierunkowej szynie RS485 to normalne), to są momenty gdy nikt nie steruje szyną RS485 i jest ona w stanie nieustalonym. I w takim wypadku jak działasz jakimś zewnętrznym polem magnetycznym, to uzyskujesz taki jak masz efekt.
Na załączonym schemacie (tym drugim) masz na stałe ustawione włączenie nadawania po jednej stronie. I w tym wypadku nie możesz mieć tego problemu, bo nadajnik utrzymuje odpowiednie stany na szynie. Ale jak już masz zrobione sterowania nadawaniem z mikroprocesorów, tak jak na początkowym schemacie, to już wszystko ma prawo tak działać jak działa
Prawdę mówiąc to to Mirek wepchnął Cię na minę, ale sam jesteś sobie winien

W twoim wypadku aby nie "odbierać duchów" niesterowanej szynie musisz zastosować rezystory podciągające do VCC i GND - jest to opisane w standardzie RS485 (tak jak próbowałeś to robić na pierwszym schemacie)

Masz to opisane np. w Guidelines for Proper Wiring of an RS-485 (TIA/EIA-485-A) Network
https://www.maximintegrated.com/en/app-notes/index.mvp/id/763

--
Pozdrawiam,
Robert

------------------------ [ Dodano po: 18 minutach ]

@ stefan_bak
Typowo w układach z RS485 linie RE/DE są sterowane przeciwnymi stanami i wystarczy jeden pin do zmiany nadawanie odbiór (albo nadajemy albo słuchamy) i tak jest u Ciebie w MAX3485
Jeżeli nie potrzebujesz mieć dwukierunkowej transmisji lub chcesz słyszeć to co nadajesz to możesz pin RE podpiąć na stałe.
Jednak podpięcie pinu DE na stałe wiąże się z tym że nie będziesz miał albo możliwości nadawania (gdy dasz do GND) albo będziesz mógł nadawać tylko tym jednym układem na szynę RS485 (gdy podepniesz do VCC). Szyna RS485 nie jest szyną z nadajnikami typu open-kolektor

--
Pozdrawiam
Robert

PS. Wiadomo, że układy podpięte do RPi programowane są przez cały stos softwarowych nakładek i driverów, które nie działają w czasie rzeczywistym. Ale coś mi się nie chce wierzyć, że masz aż tak duże opóźnienia na wyjściu sterowania linią DE. Jakiej prędkości transmisji używasz? 1Mbps?

Dzięki za informację o DE, w takim razie zostawię go zapiętego pod GPIO4.

Co do Raspberry, to też jestem zdziwiony, ale raczej na 100% jest to kwestia sterowania MAXem. Jak podłącze dedykowany interfejs USB RS485 do raspberry to program działa idealnie. Z drugiej strony ciekawe, że reakcja zakupionego przeze mnie SLAVEa jest taka szybka, trochę już miałem do czynienia z urządzeniami sterowanymi różnymi interfejsami i zawsze jednak te kilka ms trzeba było czekać na odpowiedź.

Jeszcze zastanawiam się nad przetestowaniem tego w innym języku. Mój program jest w Pythonie, być może sterowanie GPIO w C będzie szybsze i problem nie wystąpi.

Trochę nie widzi mi się zamawianie nowych płytek. Robienie pająka przerabiając te już wytrawione również nie będzie wyglądało zbyt estetycznie, no cóż zobaczymy.

Zapomniałem dodać, prędkość jakiej używam to 9600, więc to kwestia raczej samego czasu reakcji urządzenia na rozkaz.

Według informacji z testów to w pythonie da się na RPi uzyskać ok. 70 tys. operacji na pinie GPIO:
http://rpiai.com/benchmarking-gpio-pins-of-raspberry-pi-model-b-plus/index.html
więc nie to powinno być przyczyną gubienia początku transmisji z odpowiedzią.
Choć porównanie do 15 mln przy korzystaniu z C, dużo mówi o koniecznym narzucie. Dlatego używaj C jak się da

Szukałbym raczej problemu w tym, że nie łapiesz dokładnie końca nadawania po stronie RPi. Pewnie dostajesz znacznie później informację o jej zakończeniu i w wyniku tego robisz "spóźnione" przełączenie nadawanie na odbiór ...

Sam układ MAX3485 przełącza nadajnik/odbiornik w czasie poniżej 100ns:

Więc on raczej nie wnosi znaczących opóźnień. Dlatego transmisję można zmieniać jak szybko mogą zrobić to logiki na urządzeniach. Na AVRach możesz bez problemu robić to na poziomie pojedynczych mikrosekund (generujesz przerwanie Tx Complete i jak to był ostatni znak to zmieniasz stan pinów DE/RE)
Być może na tym twoim nowym układzie ktoś tak do tego podszedł i masz problem, bo ten Twój szybki ARM w RPI to tylko z teorii i taktowania zegara jest szybki ale już nie w tym wypadku.

--
Pozdrawiam,
Robert

Bezpośrednim rozwiązaniem mojego problemu było podciągnięcie przez 10K do Vcc pinu RX mastera. Dziękuję wszystkim bardzo za pomoc i wskazówki, okazały się niezmiernie pomocne.