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

[Rozwiązano] Atmega - RS232 - Atmega ( klopoty z komunikacją )

Roki.pl 17 Sie 2018 14:30 432 12
  • #1 17 Sie 2018 14:30
    Roki.pl
    Poziom 9  

    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

    0 12
  • #2 17 Sie 2018 15:43
    kamyczek
    Poziom 34  

    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

    0
  • #3 17 Sie 2018 15:47
    jrk13
    Poziom 14  

    Może zrobiłeś banalny, czeski błąd i połączyłeś TxD z TxD zamiast z RxD ?

    0
  • #4 17 Sie 2018 18:47
    Tomq
    Poziom 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.

    0
  • #5 18 Sie 2018 06:49
    Roki.pl
    Poziom 9  

    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.

    0
  • #6 18 Sie 2018 11:14
    tmf
    Moderator Mikrokontrolery Projektowanie

    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?

    0
  • #7 18 Sie 2018 11:38
    Roki.pl
    Poziom 9  

    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.

    0
  • #8 18 Sie 2018 11:47
    tmf
    Moderator Mikrokontrolery Projektowanie

    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 :)

    0
  • #9 20 Sie 2018 09:19
    Roki.pl
    Poziom 9  

    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

    Kod: vbnet
    Zaloguj się, aby zobaczyć kod


    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

    Moderowany przez Kuniarz:

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

    0
  • #10 20 Sie 2018 11:26
    kamyczek
    Poziom 34  

    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 .

    0
  • #12 20 Sie 2018 12:48
    kamyczek
    Poziom 34  

    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 .

    0
  • #13 27 Sie 2018 10:57
    Roki.pl
    Poziom 9  

    No cóż, brak odpowiedzi więc zamykam temat. Dziękuję wszystkim za dobre chęci.

    0