ATNEL tech-forum

Re: Parsowanie komend AT z pakietów UDP

2014-03-21T17:41:49+01:00

Quote:

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

Statystyki: Napisane przez mirekk36 — 21 mar 2014, o 17:41

Re: Parsowanie komend AT z pakietów UDP

2014-03-21T16:25:20+01:00

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:

[syntax=c]if( 0 == pBuf[0] ) strcpy_P(pAnswer, PSTR("\r\n"))[/syntax]

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:

[syntax=c]data = (char *)UDP_DATA_P;[/syntax]

------------------------ [ 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.

Statystyki: Napisane przez Atlantis — 21 mar 2014, o 16:25

Re: Parsowanie komend AT z pakietów UDP

2014-03-21T15:52:42+01:00

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.

Statystyki: Napisane przez mirekk36 — 21 mar 2014, o 15:52

Re: Parsowanie komend AT z pakietów UDP

2014-03-21T15:48:57+01:00

mirekk36 napisał(a):

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ć.

Statystyki: Napisane przez Atlantis — 21 mar 2014, o 15:48

Re: Parsowanie komend AT z pakietów UDP

2014-03-21T15:37:43+01:00

Atlantis napisał(a):

To pewnie zrobię w następnej kolejności.

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

Atlantis napisał(a):

"ATI\0" to treść wysyłana pakietem UDP

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

[syntax=c]lcd_cls();
lcd_str( bufor );
while(1);[/syntax]
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

Statystyki: Napisane przez mirekk36 — 21 mar 2014, o 15:37

Re: Parsowanie komend AT z pakietów UDP

2014-03-21T15:11:49+01:00

mirekk36 napisał(a):

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.

Quote:

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

"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.

Quote:

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"

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:

[syntax=c]if( AT_CNT == i ) strcpy_P(pAnswer, PSTR("ERROR3\r\n"));[/syntax]

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...

Statystyki: Napisane przez Atlantis — 21 mar 2014, o 15:11

Re: Parsowanie komend AT z pakietów UDP

2014-03-21T14:42:51+01:00

Atlantis napisał(a):

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".

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.

Atlantis napisał(a):

To tyle gadania. Przechodzę do rzeczy.

racja ...

Atlantis napisał(a):

ale przecież coś takiego jak "AT\0" albo "ATI\0" powinno dać odpowiedź

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:

[syntax=c]{"AT", at_service},
{"ATI", ati_service},[/syntax]

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"

Statystyki: Napisane przez mirekk36 — 21 mar 2014, o 14:42

Parsowanie komend AT z pakietów UDP

2014-03-21T14:05:28+01:00

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
[syntax=c]#ifndef KOMENDY_AT_H_
#define KOMENDY_AT_H_

//Definicje wyjść i wejść
#define LED1 0
#define PORTLED1 PORTB
#define DDRLED1 DDRB

// definicja typu strukturalnego
typedef struct {
char polecenie_at[8];
int8_t (* at_function)(uint8_t inout, char * params, char * pAnswer);
} TATCMD;

// deklaracje zmiennych zewnętrznych
extern const TATCMD polecenia_at[] PROGMEM;

// deklaracje funkcji
void parse_data( char * pBuf, char * pAnswer );

int8_t at_service(uint8_t inout, char * params, char * pAnswer);
int8_t ati_service(uint8_t inout, char * params, char * pAnswer);
int8_t at_lamp_service(uint8_t inout, char * params, char * pAnswer);

#endif /* KOMENDY_AT_H_ */[/syntax]

komendy_at.c

[syntax=c]#include
#include
#include
#include
#include
#include

#include "komendy_at.h"

#define AT_CNT 3// iloć poleceń AT

//----------- tablica z poleceniami AT i wskaźnikami funkcji do ich obsługi --------------------
const TATCMD polecenia_at[AT_CNT] PROGMEM = {
// { at_cmd } ,{ wskaźnik do funkcji obsługi at },
{"AT", at_service},
{"ATI", ati_service},
{"AT+LAMP", at_lamp_service},
};

//----------------- funkcja do analizowania danych odebranych z UART ------------------------------
void parse_data( char * pBuf, char * pAnswer ) {

int8_t (*_at_srv)(uint8_t inout, char * data, char * pAnswer);

char * cmd_wsk;
char * reszta;
uint8_t i=0, len;

if ( strpbrk(pBuf, "=?")){
// obsługa poleceń AT we/wy + parametry

if ( strpbrk(pBuf, "?")){
// zapytania do układu w postaci: AT+CMD?

cmd_wsk = strtok_r(pBuf, "?", &reszta);
len = strlen(cmd_wsk);
for(i=0;iif ( len && 0 == strncasecmp_P(cmd_wsk, polecenia_at[i].polecenie_at, len) ) {
if( pgm_read_word(polecenia_at[i].polecenie_at) ) { // <--- UWAGA! w tekście książki zabrakło pgm_read_word()
_at_srv = (void *)pgm_read_word( &polecenia_at[i].at_function );
if( _at_srv) {
if( _at_srv( 0, reszta, pAnswer ) < 0 ) strcpy_P(pAnswer, PSTR("ERROR\r\n"));
}
}
strcpy_P(pAnswer, PSTR("\r\n"));
break;
}
}

} else {
// ustawienia układu w postaci: AT+CMD=parametry

cmd_wsk = strtok_r(pBuf, "=", &reszta);
len = strlen(cmd_wsk);
for(i=0;iif ( len && 0 == strncasecmp_P(cmd_wsk, polecenia_at[i].polecenie_at, len) ) {
if( pgm_read_word(polecenia_at[i].polecenie_at) ) { // <--- UWAGA! w tekście książki zabrakło pgm_read_word()
_at_srv = (void *)pgm_read_word( &polecenia_at[i].at_function );
if( _at_srv && ! _at_srv( 1, reszta, pAnswer ) ) strcpy_P(pAnswer, PSTR("OK\r\n"));
else strcpy_P(pAnswer, PSTR("ERROR\r\n"));
}
break;
}
}
}

} else {
// obsługa poleceń AT bez parametrów

if( 0 == pBuf[0] ) strcpy_P(pAnswer, PSTR("\r\n"));// reakcja na znak CR lub CRLF z terminala
else {
for(i=0;iif ( 0 == strncasecmp_P(pBuf, polecenia_at[i].polecenie_at, strlen(pBuf)) ) {
if( pgm_read_word(polecenia_at[i].polecenie_at) ) { // <--- UWAGA! w tekście książki zabrakło pgm_read_word()
_at_srv = (void *)pgm_read_word( &polecenia_at[i].at_function );
if( _at_srv) _at_srv(2,0, pAnswer);
}
break;
}
}
}
}

if( AT_CNT == i ) strcpy_P(pAnswer, PSTR("ERROR\r\n"));
}

//----------------- obsługa poszczególnych komend AT ----------------------------------
int8_t at_service(uint8_t inout, char * params, char * pAnswer) {
strcpy_P(pAnswer, PSTR("OK\r\n"));
return 0;
}

int8_t ati_service(uint8_t inout, char * params, char * pAnswer) {
strcpy_P(pAnswer, PSTR("Sterownik oswietlenia v0.1\r\n"));
return 0;
}

int8_t at_lamp_service(uint8_t inout, char * params, char * pAnswer) {

/*if( inout < 2 ) {
if( 1 == inout ) {
if( params[0] < '0' || params[0] > '1' ) return -1;
if( '1' == params[0] ) LED_ON;
else LED_OFF;
}
uart_puts("+LED: ");
if( LED_PIN & LED ) uart_putint(1,10);
else uart_putint(0,10);
uart_puts("\r\n");
} else if( 2 == inout ) {
uart_puts("AT+LED = (0-1)\r\n");
}
*/
PORTLED1 ^= (1<return 0;
}[/syntax]

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:

[syntax=c]parse_data(data, answer);
if (answer[0]) {
make_udp_reply_from_request(buf, answer, strlen(answer), myudpport[0]);
answer[0] = '\0';[/syntax]

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:

[syntax=c]typedef struct {
char polecenie_at[8];
int8_t (* at_service)(uint8_t inout, char * params, char * pAnswer);
} TATCMD;[/syntax]

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"

Statystyki: Napisane przez Atlantis — 21 mar 2014, o 14:05