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

MAX3485CPA+ RS-485: Błędne znaki przy komunikacji Raspberry Pi z ATmegą

Patman 31 Maj 2014 21:52 5883 2
REKLAMA
  • #1 13652121
    Patman
    Poziom 10  
    Cześć. Próbuję nawiązać komunikację pomiędzy Raspberry PI i ATmegą przy użyciu RS-485. Stan wysoki dla RPI to 3.3V, więc korzystam z układów scalonych MAX3485CPA+. Wszystko zasilam napięciem 3.3V.

    Dla uproszczenia ustawiłem komunikację w jednym kierunku, tj. wymusiłem na sygnałach sterujących kierunkiem maxów (piny DE /RE), nadawanie dla ATmegi oraz odbieranie dla RPI. Prędkość 9600. Napisałem stosowny program dla ATmegi, ale RPI odbiera inny znak od wysłanego. Nie są to losowe dane, tylko zawsze dla 'a'->'0'(zero), 'Q'->'W' itd.

    Całość wygląda tak:
    MAX3485CPA+ RS-485: Błędne znaki przy komunikacji Raspberry Pi z ATmegą

    Dodam jeszcze, że wcześniej zasilałem ATmegę napięciem 5V i po jej stronie korzystałem z MAX485 i występował identyczny problem. Łącząc ATmegę i RPI bezpośrednio przez UART (bez pośredniczących max-ów) całość działa poprawnie.

    Postanowiłem wykonać test: stworzyłem pętlę komunikacyjną, tj. RPI ma sam do siebie wysyłać znak przy użyciu RS485, gdzie całość wygląda tak:
    MAX3485CPA+ RS-485: Błędne znaki przy komunikacji Raspberry Pi z ATmegą
    Układ zachowuje się identycznie. Wysyłam przez Putty 'a', wraca '0'. Dodam, że UART w RPI jest poprawnie skonfigurowany. Zwarte piny RXD i TXD (bez wykorzystywania RS485), powodują, że wracają poprawne dane.

    Z moich rozważań wynika, że wina leży po stronie scalaków MAX3485.

    Update: Po zmianie scalaków na MAX485 (zasilanych z 3.3V, jak i dla testu z 5V) problem jest identyczny.

    Czy ktoś jest wstanie wskazać mi powód takiego zachowania?
  • REKLAMA
  • Pomocny post
    #2 13652527
    kspro
    Poziom 27  
    Wszystko pięknie tylko dlaczego masz przekręcone linie A i B między transceiverami? Przecież w ten sposób nadawane jedynki odbierane są jako zera i na odwrót. Co prawda nie podałeś dokładnie jaki jest rodzaj transmisji, ale i bez tego widać pewną prawidłowość, zwłaszcza jeśli założy się transmisję asynchroniczną startstopową, 8 bitów danych, 1 bit stopu, bez parzystości.
    Znak 'Q' w kodzie ASCII to 51H, czyli 01010001B. Dane nadawane są począwszy od najmłodszego bitu, więc znak 'Q' jako strumień bitów wygląda tak:
    0100010101 (bit startu, 8 bitów danej, bit stopu, łącznie 10 bitów)
    Po zanegowaniu sekwencja bitów wygląda tak:
    1011101010
    Jeśli znak nadawany był non-stop w pętli, sekwencje skleiły się, powtórzę tylko dwie:
    10111010101011101010
    No i odbiornik UART-a wykrył 0 jako bit startu, wczytał sekwencję 11101010 jako 8 bitów danych, i 1 jako poprawny bit stopu, czyli odebrał 01010111B (57H), czyli znak 'W'. Zgadza się?
  • #3 13652583
    Patman
    Poziom 10  
    kspro masz rację. Nie zwróciłem na to uwagi. We wszystkich datasheetach, połączenia były symbolicznie poskręcane i A->B wydawało mi się bardziej "naturalne". Mój błąd.

    Dziękuję za pomoc.
REKLAMA