Pracuję obecnie nad prostym systemem automatyki domowej (zapalanie i gaszenie świateł za pośrednictwem sieci LAN).
Do testów wykorzystuję autorską płytkę z ATmegą328 i układem ENC28J60. Obsługą stosu TCP/IP zajmuje się biblioteka z tuxgraphics.org. Do prasowania komend AT wykorzystuję zmodyfikowaną na swoje potrzeby bibliotekę z płytki dołączonej do zielonej książki. Kod poniżej:


komendy_at.h


komendy_at.c



Główna zmiana polega na dodaniu dodatkowego bufora char * answer, do którego zapisywane są odpowiedzi zwracane przez komendy. Dzięki temu wywołanie funkcji w programie wygląda następująco:



Dzięki temu mogę wielokrotnie stosować tę samą funkcję w różnych miejscach programu, do parsowania komend przychodzących z różnych interfejsów i do wysyłania odpowiedzi na odpowiedni interfejs.

Przy okazji zauważyłem także drobny błąd w bibliotece - oryginalnie deklaracja tabeli w pliku "komendy_at.h" wyglądała następująco:



Nazwa "at_service" dublowała się z nazwą funkcji obsługującej komendę "AT", poprawiłem to przez zmianę na "at_function".

To tyle gadania. Przechodzę do rzeczy. Skompilowałem program, wgrałem go do ATmegi, podłączyłem wszystko do sieci.
Do wysyłania pakietów UDP używam androidowego "Packet Sendera". Pakiety dochodzą, ale za każdym razem, co bym nie wysłał otrzymuję odpowiedź "ERROR\r\n". Czyli komunikacja działa, ale coś z parsowaniem jest nie tak.

W pakiecie próbowałem wysyłać już różne rzeczy, ale przecież coś takiego jak "AT\0" albo "ATI\0" powinno dać odpowiedź, tymczasem ja uzyskuję ten nieszczęsny "ERROR\r\n"

No i dowiedzieliśmy się o rzekomym błędzie w książce a tymczasem po jego poprawieniu kod ci nie działa a ten z książki działa ... Nie sądzisz jednak że coś jest nie tak ? Nie mówię tego złośliwie broń Boże, ale z kolei może warto czasem zapytać ? dopytać ? zamiast stwierdzać ?

Nazwy te z punktu widzenia kompilacji nie są żadnym błędem ... bo to tak jakbyś chciał udowadniać że np nazwy argumentów formalnych i aktualnych funkcji MUSZĄ być różne, a nie muszą. Owszem dla kogoś może to stanowić jakiś problem odnośnie wizji całości - wtedy można sobie zmienić - przykłady w książce to TYLKO przykłady - przykłady dydaktyczne.


racja ...



a skąd taki pomysł ? Może jednak nie do końca kolega zrozumiał albo przeczytał jednak ten rozdział ?

Co to za stringi "AT\0" albo "ATI\0" ? to na pewno nie są te stringi:



Poza tym skoro wciąż wyskakuje ERROR to co za problem wyświetlić sobie na LCD albo przesłać na terminal zawartość odebranego bufora żeby prześledzić (ręcznie zdebugować) co dotarło do procka ? Myślę że po tej operacji szybko by kolega doszedł dlaczego nie ma reakcji na jakiś tam string "AT\0"

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

Racja. Użyłem zbyt mocnego słowa, przepraszam. To nie błąd, ale jednak może nieco mylić. Dlatego zmieniłem.
Nie zmienia to faktu, że moja zmiana nie ma nic wspólnego z opisywanym problemem. Wcześniej też nie działało.




"ATI\0" to treść wysyłana pakietem UDP. Zero dodane na wszelki wypadek, nie powinno robić tutaj żadnej różnicy, bo przecież jest to symbol oznaczający koniec łańcucha tekstowego. Próbowałem też wysyłać bez niego. Nie ma żadnej różnicy.
Skontrolowałem też WireSharkiem co dokładnie jest wysyłane i odbierane. Wygląda na to, że wszystko się zgadza. Nic nie zostaje poszatkowane na kilka pakietów, w części pakietu "data" znajduje się ciąg o odpowiedniej treści i długości, zakończony znakiem \0.




To pewnie zrobię w następnej kolejności. W tej chwili ponumerowałem jeszcze poszczególne "ERROR-y" występujące w kodzie, żeby dowiedzieć się, który z nich zostaje wywołany. Wychodzi na to, że za każdym razem odzywa się ostatni:



Tak, jakby kod nie rozpoznawał komendy i po przejściu do końca tabeli zgłaszał błąd.
Przychodzi mi do głowy jeszcze taka możliwość, że może do funkcji parsującej wysyłany jest nieprawidłowy adres początku danych w przetwarzanym pakiecie UDP.

------------------------ [ Dodano po: 24 minutach ]

Wygląda na to, że chyba faktycznie przepisując kod przez pomyłkę wpisałem złą stałą określającą początek danych. Teraz poprawiłem i jest zmiana, ale nie do końca wszystko działa jak powinno. Za każdym razem otrzymuję ciąg "\r\n". Muszę jeszcze poszukać przyczyny...

A ja bym od tego zaczął bo to od razu dałoby mi odpowiedź - dlaczego nie dochodzi do porównania nadsyłanej komendy.

I tu uściślę .... bo napisałeś:



i piszesz, że tu jest zero dodane na końcu ? gdzie ? ... wg ciebie "\0" to jest zero czy jak ? ... pytam bo być może przylatują ci po prostu dwa kody ASCII, jeden znaku ukośnika a drugi zera - rozumiesz ? bo gdzieś tam w smartfonie wcale ci się to nie zamieniło na 0 .....

Zresztą taki zapis "AT" w C oznacza że mamy do czynienia z C-Stringiem czyli łańcuchem w tym przypadku trzy-elementowym, gdzie dwa pierwsze elementy to AT a ostatni to zero ...

Reasumując - jeszcze raz powtórzę - to prosta czynność jeśli masz jakiś LCD pod ręką - zastawić sobie pułapkę programową i dać wprost


i masz od razu pozamiatane - tzn widzisz co przyszło - a jeśli nie masz LCD to wysyłasz na UART do terminala .... i masz sprawę jak na dłoni co? gdzie? i jak leci

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

Tak, oczywiście rozumiem różnicę. Nie, nie wysyłam dwóch znaków ASCII, ale jeden znak końca łańcucha. Packet Sender daje zresztą podgląd hex tego, co się wysyła i na końcu leci 0x00, odpowiadające temu \0. To samo widzę w WireSharku. Packet Sendera w wersji pod Windowsa też zdążyłem już wypróbować.

A ok ... to ja w takim razie jak coś czekam na info co masz w buforze gdy zaczynasz parsowanie .... gdy ja testuję sobie parsowanie czegokolwiek a na początku takie dziwne rzeczy mi się dzieją - to dla mnie jest podstawą zobaczyć na własne oczy co wpada do parsowania. Co tu dużo mówić - od razu widać czy np coś nie jest źle przekazywane wcześniej ... No trzeba to niestety takimi etapami sobie sprawdzać. Tzn tak mi się wydaje.

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

Ok, muszę tylko poszukać przelotki RS232 <--> UART, bo nie pamiętam w którym pudełku leży.
W międzyczasie ponumerowałem jeszcze wystąpienia samego ciągu \r\n i okazuje się, że za każdym razem, bez względu na to co wyślę (może to być zarówno dowolna komenda, jak i nonsensowny ciąg znaków) odzywa się ta linijka:



Wygląda na to, że masz rację i faktycznie funkcja otrzymuje złe dane do parsowania. Zupełnie jakby za każdym razem otrzymywała adres pamięci, pod którym zawsze znajduje się zero. Dzieje się tak nawet wtedy, gdy wyślę ciąg z komendą zawierającą znak '?' albo '='.

Dlatego jeszcze przed podłączeniem kabelka chciałbym zapytać, czy faktycznie przekazuję właściwy adres do początku danych UDP:



------------------------ [ Dodano po: 11 minutach ]

Ok, już zauważyłem swój błąd. Powinno być:
data = (char *)(&(buf[UDP_DATA_P]));

Niby drobiazg, a mocno skomplikował życie.

No dokładnie - dlatego podglądanie bufora doprowadza po sznureczku gdzie w końcu leży błąd

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