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

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

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

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

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.

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.

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?

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.

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

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


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

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 .

kamyczek wrote:

poza tym nie widzę deklaracji portu com ,bo $baud to dla mnie za mało .

To w przypadku Bascom kompletnie wystarczy.

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 .

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