Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[Solved] Atmega - RS232 - Atmega ( klopoty z komunikacją )

Roki.pl 17 Aug 2018 14:30 711 12
  • #1
    Roki.pl
    Level 10  
    Może, ktoś z kolegów podpowie, bo nie mam pojęcia dlaczego nie mogę skomunikować Atmegi 8 z Atmegą 16.
    Atmega16 wysyła przez RS jednoznakowy string i druga Atmega go odbiera i realizuje sekwencję programu związaną z tym poleceniem. po wykonaniu ma odpowiedzieć tym samym znakiem, że polecenie zostało zrealizowane i tu jest problem. Pierwsza Atmega informacji nie odbiera. Atmegi pracują na 4 MHz i skomunikowane są przez MAX232. Łącząc poszczególne Atmegi z komputerem i testując kolejno przez TESTER RS232 wszystko jest OK. Znaki sa wlaściwie odczytywane. Proszę o jakieś sugestie
  • #2
    kamyczek
    Level 38  
    Sprawdziłeś jaki masz błąd prędkości uart dla rezonatora 4MHz . Poza tym jesteś pewny że dobrze ustawiłeś konfigurację cksel i nie pracujesz na wewnętrznym oscylatorze RC 1MHz . Większość błędów to źle skonfigurowany zegar taktujący mikrokontroler . poza tym pokaż kod bo bez niego to tylko gdybanie
  • #3
    jrk13
    Level 15  
    Może zrobiłeś banalny, czeski błąd i połączyłeś TxD z TxD zamiast z RxD ?
  • #4
    Tomq
    Level 38  
    Do rozwiązywania takich problemów najlepiej kupić za ok 35 zł analizator stanów logicznych kompatybilny z Saleale (dostępnej w tej cenie na znanym portalu aukcyjnym) . Wtedy można podejrzeć komunikację za pomocą komputera. Oprogramowanie analizatora jest w stanie interpretować wysyłane znaki, o ile wskażemy mu prędkość transmisji.
  • #5
    Roki.pl
    Level 10  
    Serdecznie dziękuję za odpowiedzi. Błąd jest dopuszczalny, pracuję na zewnętrznym oscylatorze 3-12MHz, Rx z Tx nie pomyliłem gdyż na tym samym kabelku łączę się komputerem i na Terminal emulator mam pełną komunikację zarówno z jednym procesorem jak i drugim procesorem tak, że nie wchodzą w grę błędy wynikające z prędkości, czy niewłaściwego połączenia Rx i Tx. Dodatkowo na laptopie mam program testujący połączenia realizowane przez RS232 i również na tym programie wszystko jest OK, więc myślę, że analizator stanów logicznych jest niepotrzebny ( ale może czegoś nie wiem i więc chętnie posłucham innych argumentów ). Jestem w 99,9% przekonany, że programy są napisane poprawnie, ale " czegoś " brakuje lub jest za dużo w bezpośredniej transmisji danych między procesorami. Ale nie wiem w czym jest problem.
  • #6
    tmf
    Moderator of Microcontroller designs
    No to raczej bez pokazania kodu nic ci nie pomożemy. Najprościej jest napisać możliwie najprostszy program testowy i na nim sprawdzić czy działa. Jeśli tak, to problem sprzętowy jest wykluczony i można dalej szukać błędu w programie. W większości przypadków problemem jest błędna konfiguracja UART - zły baudrate, inna konfiguracja ramki, złe taktowanie MCU. Sprawdziłeś, czy procek rzeczywiście jest taktowany z rezonatora 4 MHz? Co to jest - kwarc?
  • #7
    Roki.pl
    Level 10  
    Tak, w jednym i drugim jest kwarc 4 MHz, Fussbity ustawione na zewnętrzny kwarc. Jakby oscylator nie pracował to nie byłoby komunikacji z prockiem. Prędkość transmisji w obu 9600. A współpracować nie chce. Zastanawia mnie fakt b. dobrej współpracy jednego i drugiego procka z programami testującymi i popranych realizacji zadań przy wysyłanych poleceniach kodem ASCII. Może tolerancja ewentualnych błędów transmisji w kompie jest większa niż w procesorach. Program umieszczę w poniedziałek, bo mam go w pracy. Na razie tyle, ale serdeczne dzięki za sugestie.
  • #8
    tmf
    Moderator of Microcontroller designs
    Jeśłi oba procki są taktowane kwarce 4 MHz to nie ma odchyłek w szybkości transmisji - błędy sie znoszą po obu stronach. Transmisja oczywiście będzie z nieco inną szybkością, ale z błędem 0%.
    Pozostaje jeszcze sprawdzić hardware, a jeśli nie pokażesz minimalnego programu odtwarzającego problem, to jak pisałem, nikt ci nie pomoże, bo wróżek raczej tu nie ma :)
  • #9
    Roki.pl
    Level 10  
    Przedstawiam tylko istotne części programu związane z transmisją danych
    Na początek Atmega 16 obsługuje klawiaturę, Wyświetlacz LCD i komunikację GSM i inne drobiazgi oraz RS232 z Atmegą 8
    Code: vbnet
    Log in, to see the code


    To na razie tyle.

    Dodano po 10 [minuty]:

    A tak przy okazji takie pytanie czym różni się transmisja po RS232 dla:

    A=1
    Print A

    oraz

    Print "1"

    Wg ASCII < 1 > ma kod 49 i chyba w jednym i drugim przypadku w ramce zostanie wysłany ten sam układ 8 bitów znaczących oprócz bitów sterujących

    Moderated By Kuniarz:

    Proszę treść programu umieszczać w odpowiedni sposób - guzik SYNTAX pomoże ;-)

  • #10
    kamyczek
    Level 38  
    Bascom jest językiem w którym nic nie jest pewne , Problem mogą robić inne przerwania , poza tym nie widzę deklaracji portu com ,bo $baud to dla mnie za mało . Co do pytania na końcu to prawdopodobnie dla pierwszego przypadku dostaniesz wartość w hex=1 a w drugim Hex 49 bo zapis bez przedrostka i innych znaków dotyczy wartości dziesiętnej .
  • #11
    Kuniarz
    Moderator of Designing
    kamyczek wrote:
    poza tym nie widzę deklaracji portu com ,bo $baud to dla mnie za mało .

    To w przypadku Bascom kompletnie wystarczy.
  • #12
    kamyczek
    Level 38  
    Wybacz bascom pamiętam jeszcze z 8051 tam było config .... W każdym razie u mnie skńczyło się na etapie gdy procek mógł a bascom nie chciał .... I do dziś jest asembler pomijam że są inne i może lepsze, ale na moje skromne potrzeby wystarcza . To co pamiętam z bascoma to to że czasem niektóre konfiguracje wykorzystywały te same peryferia i co za tym idzie nie działały w jednym programie . Podsumowując jak testowałem każdy element działał poprawnie jak był sam po złożeniu w program nie działał jeden z klocków .
  • #13
    Roki.pl
    Level 10  
    No cóż, brak odpowiedzi więc zamykam temat. Dziękuję wszystkim za dobre chęci.