To nie tyle problem, co taka ciekawostka na którą się natknąłem. Chciałbym po prostu dowiedzieć się czy wynika to z jakiegoś błędu w programie, czy też jest normalnym zachowaniem programu.
Mam ATmegę328 z udpalonym zestawem do komunikacji przez UART - bufory cykliczne dla RX i TX po 128 bajtów, obsługa wysyłania i odbierania w przerwaniach, parsowanie komend AT- wszystko w oparciu o zieloną książkę, z niewielkimi własnymi modyfikacjami. Właściwie największą zmianą z mojej strony jest zapisywanie odpowiedzi do bufora, zamiast wysyłania ich od razu. Jest to potraktowane tym, że w urządzeniu mam jeszcze inny interfejs komunikacyjny, który korzysta z tej samej funkcji parsującej.

Wszystko działa idealnie, gdy spokojnie "rozmawiam" z programem wysyłając mu komendę i czekając na odpowiedź. W ramach eksperymentu postanowiłem jednak "zalać go" komendami, których nie był w stanie przetwarzać. Poza powtarzaniem typowej odpowiedzi "UNKNOWN COMMAND" (efekt nadpisywania danych w buforze) natknąłem się na co najmniej dwie dziwne reakcje:

1) Przesunięcie odpowiedzi - program odpowiada nie na ostatnią komendę, ale na tą wysłaną tak z 4-5 linijek wstecz.
2) Program zapętla się, wysyłając bez końca ten sam zestaw danych. Wtedy pomaga już tylko reset.

A może przypadkiem za takie zachowanie może odpowiadać układ FT232?

Jak już wspominałem - nie jest to żadnym wielkim problemem. Po prostu zaciekawiła mnie ta sprawa, a przeglądając kod z książki (i moje modyfikacje) za nic nie mogę wytypować potencjalnej przyczyny.

Kolejny "fajny" pomysł - jak coś nie działa to pewnie scalaki są do (Y) .... Tak zawsze najłatwiej - czyli typowe: "JA robię wszystko dobrze a nawet SUPER! więc winny musi być: procek albo eclipse, albo kompilator albo jak tu jeszcze lepiej FT232R - no ludzie kochani ...

Ja mogę ci bez niczego w CIEMNO powiedzieć - twój KOD jest zły ... a sugestia? prosta - napraw go, napisz poprawnie i będzie działać.

Tylko nie pisz mi tu - że to przecież kod z GreenBooka .... bo kod w książce ma być ilustracją do zrozumienia wielu ciekawych zagadnień jak (przede wszystkim) obsługa własnych komend AT, jak parsowanie danych, jak callbacki w służbie obsługi RS232, jak techniki programowania, wykorzystanie funkcji w C takich jak: strtok() czy strtok_r() to obsługi tokenów i wiele innych ....

Przy czym WYRAŹNIE piszę - że nie jest to ŻADNA biblioteka napisana MEGA OPTYMALNIE i obsługująca KAŻDE NIESZCZĘŚCIE, które ci się przydarzy czyli każdy błąd - bo takiej biblioteki panie - to jeszcze nikt nie napisał i nie napisze .... sam to musisz zrobić i dostosować do własnych potrzeb - wtedy się uda

zamiast siedzieć i narzekać na źle działający scalak FT232R (albo chociażby wysnuwać takie kosmiczne wnioski że to może być scalak źle działający na podstawie takich objawów) .... idąc tą drogą to najlepiej od razu napisać do supportu technicznego FTDI i podpowiedzieć im, że właśnie wykryłeś BUG'a w ich scalaku. Tylko że też idąc to drogą to zaraz będziesz pisał tego typu maile a to do producentów procesorów i różnych innych peryferiów - gdy tylko ci twój kod będzie źle działać.

PODEJŚCIE - trzeba zmienić podejście - ZAWSZE to powtarzam

_________________
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 ]

Przepraszam bardzo, ja nic takiego nie napisałem. Po prostu nie jestem do końca pewien jak ten układ się zachowa w takiej sytuacji, na ile jest przezroczysty, a na ile "przetwarza" i buforuje otrzymywane dane itp. Wiem, że takie rozwiązanie jest mało prawdopodobne, ale pomysł nie wziął się bynajmniej "z komosu". Kiedyś miałem do czynienia z modułem GSM, który zachowywał się bardzo podobnie - zaczynał wariować, kiedy wysyłało mu się kolejną komendę, gdy on jeszcze nie skończył odsyłać odpowiedzi na poprzednią. Terminal wyświetlał wtedy bzdury. Kilku innych użytkowników Usenetu potwierdziło zaobserwowanie dokładnie takiego samego objawu w przypadku tego modelu.




Ale ja sobie z tego doskonale zdaje sprawę. Naprawdę nie mam do nikogo pretensji, a już na pewno nie do biblioteki (ani tym bardziej do jej autora). Po prostu "zameldowałem" o zauważeniu takiego ciekawego przypadku, którego w tej chwili nie mogę powiązać z żadną z moich modyfikacji (co nie wyklucza tego, że to właśnie w nich leży przyczyna). Po prostu byłem ciekaw, czy któryś z innych posiadaczy Greenbooka zauważył coś takiego.




Nikt nie powiedział, że źle działa. W normalnych warunkach działa normalnie. Co do scalaka, to jak już powiedziałem - kiedyś wydawałoby mi się to równie absurdalnym pomysłem, ale mam doświadczenia z modułem GSM, gdzie podobne zachowanie miało całkowicie sprzętową przyczynę, więc aż tak niedorzecznym domysłem to nie jest (choć ciągle uważam ten trop za bardzo mało prawdopodobny).

Zrób dodatkową software'ową kontrolę przepływu danych. Odpowiadając na Twoje pytanie uważam, że to co się dzieje u Ciebie to w zasadzie normalne, bo układ UART obsługuje (przetwarza) to co ma w buforze. A że ma "śmieci", to przetwarza śmieci i stąd się biorą wariactwa. Prawdopodobnie źle masz ustawione zależności czasowe przetwarzania danych od bufora UART. Nie może być na styk, tylko minimalny zapas czasu kiedy jeden rozkaz przestaje być przetwarzany i może być przetwarzany nowy. W innym wypadku bufor UART nic nie powinien odebrać. Druga sprawa to jakaś flaga zajętości bufora UART. Jeżeli to dla Ciebie nie problem, to zrób sobie dodatkowe linie danych i sprzętową kontrolę przepływu, ale będzie trzeba wykorzystać dodatkowe piny MCU... Jeżeli bufor UART po stronie MCU jest cyklicznie sprawdzany przez timer, to można do kodu wprowadzić dodatkową zmienną (flagę) gotowości bufora UART -jeśli czegoś takiego nie ma. Czy "lekko" zmieniając kod Pana Mirka aby czegoś niepotrzebnie nie wykasowałeś?
Pozdrawiam! Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Już znalazłem przyczynę - zabrakło instrukcji zerującej zmienną ascii_line przy przepełnieniu bufora.
A co do kontroli przepływu to dobry pomysł. Muszę doczytać czy FT232 obsługuje bity Xon i Xoff.

Ja tylko dodam że w tym kodzie ... z GB, jakbym powiedział że czegoś brakuje jeśli chodzi o sprawdzanie błędów to bym skłamał - w ogóle brakuje sprawdzania sytuacji awaryjnych .... bo gdybym to dopisał to niech mi ktoś mądry powie - jak wtedy miałbym przekazać to co chciałem przekazać ?

a zatem:

1. przede wszystkim trzeba wprowadzić atomowość bo np funkcja uart_getc() z tego co pamiętam zwraca wynik 16-bit ale i w innych miejscach trzeba przejrzeć kod pod tym kątem

2. obsłużyć błędy podawane ze sprzętowego modułu UART przede WSZYSTKIM a tego w ogóle nie ma

3. obsłużyć błędy "porwanych ramek" w trakcie tego "zalewania"

itp itd .... to nie jest robota na 2-3 linijki kodu ... nad tym trzeba trochę posiedzieć, popisać, potestować ....

_________________
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 ]

aż sobie zajrzałem do kodu z GB i taki mamy oto komentarz nawet w kodzie :



to tak w uzupełnieniu do:




Po prostu trzeba przeglądać dokładniej ....

a to:


nie jest ŻADNYM, podkreślam żadnym potwierdzeniem, że pomysł nie był "z kosmosu" wręcz przeciwnie - tym bardziej pomysł z kosmosu - a to co napisałeś potwierdza tylko fakt, że nie ty sam jeden wpadłeś na pomysł z kosmosu ale jeszcze kilku użytkowników tego usnetu jak napisałeś ....

Bo kto wysyła do modemu komendy gdy ten nie zakończył wykonywania poprzedniej ? .... to tylko świadczy znowu o tym że ty czy inni użytkownicy usenetu jesteście początkujący i nie wiecie jak się obsługuje zdarzenia asynchroniczne. Nie wiecie, że PODSTAWOWY standard komend AT daje możliwość sprawdzenia czy jest odpowiedź z modemu czy nie. Że sprawdza się zawsze w takiej rozmowie z modemem co najmniej TRZY podstawowe stany:

1. odpowiedź OK
2. odpowiedź ERR
3. brak odpowiedzi czyli TimeOUT

co DOBITNIE pokazuje - że pomysł - iż coś z modemem jest nie tak gdy odsyła bzdury w takiej sytuacji jak opisałeś - jest pomysłem z KOSMOSU

ale znowu tutaj wychodzi to samo - że brak ci takiego podejścia:



i przez to jak sam widzisz - co rusz popadasz w coraz większe PUŁAPKI własnych pomysłów z kosmosu. Bo raz sobie ubzdurałeś coś z tym modemem - zamiast doczytać właśnie , douczyć się jak się je obsługuje, jak wyeliminować taki błąd ze swojego kodu i potem ... powielasz to samo w BYLE JAKIM innym przypadku ...

sorry że poświęcam temu tyle czasu ale staram się tępić takie podejście i pokazywać na takim właśnie KLASYCZNYM przypadku jaki tu zaprezentowałeś - że to do NICZEGO nie prowadzi ... A jak sam widzisz - nie jest to tylko moje podejście ...

_________________
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 ]