Mam mały problem, w zielonej książce jest świetnie opisane parsowanie danych z komendami AT.

Potrzebował bym jeszcze w jak prosty sposób można w drugą stronę, czyli wysyłając komendę AT z procesora do urządzenia i dostając odpowiedź, ją sparsować.
Na początek wystarczyła by obsługa zwykłego [OK] i [ERROR], jak to ugryźć? przecież nie da się bezpośrednio porównywać stringa? a może się da?, ale czy to nie będzie za bardzo zasobnożerne?

Jak w prosty sposób poradzić sobie z tym, potrzebuje wysyłać konfigurację do wizfi, dostaję zwrotnie albo samo [OK], albo dosyć sporo parametrów z których potrzebuje wyłuskać np IP.

Cześć, w bibliotece string.h jest funkcja do porównania dwóch stringów. Jeżeli są takie same funkcja zwraca 0 a jeżeli różne to 1. Funkcja wyglądała jakoś tak strcmp (tab1, tab2). Jak będę w domu to potwierdzę nazwę

Edit.
Oczywiście funkcja porównuje dwie tablice zawierające stringi

Wysłane z mojego GT-I9100 za pomocą Tapatalk 4

Nie ? .... a to jakby działały funkcje, które opisujesz, że działają ? przecież w tym kodzie na który patrzysz do obsługi AT są właśnie funkcje porównujące stringi W C masz ich od groma i ciut ciut.

Komunikacja komend AT w drugą stronę ? ... ja bym się tu mniej przejmował porównywaniem stringów ... ale bardziej skoncentrowałbym się na timeoutach - bo zaczyna się asynchroniczność na maxa że tak powiem

Ja do tego tematu przyłożę się z wyjasnieniem dopiero w 3 książce przy okazji SMS/GSM/GPRS ... sam muszę usystematyzować wszystkie swoje pomysły w tym zakresie, a książka będzie dobrym celem. Niestety minęło tyle czasu od zapowiedzi a nadal nie ruszyłem niestety - więc to jeszcze troszkę potrwa.

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

Do podstawowej pracy z GSM na SIM900 używam bufora 128 bajtów zakładając że obsługuję tylko kilkunastoznakowe SMS'y (zdalna konfiguracja, nic więcej).
Jeżeli chcesz obsłużyć pełną długość SMS'a musisz mieć już prawie 200 bajtów.
Z GPS'em wszystkie ramki podchodzą już pod 255 bajtów

_________________
sig off ;(

Anty, ale oczywiście że masz rację - że z takich modułów może nadlatywać bardzo dużo tekstu nawet więcej niż 256 bajtów w stringu ...

ale ... oczywiście, że są sposoby na rozwiązywanie takich zadań i realizowałem je niejednokrotnie ... To nie jest tak, że liczę, że dopiero wpadnę na te pomysły ... Krótko mówiąc sposoby są dwa (co najmniej dwa)

1. zastosować np mikrokontroler ATmega1284 który ma 16kB RAM ... no ale to takie banalne

2. zastosować w miarę potrzeb parsowanie "W LOCIE" też się da i wtedy można do obróbki użyć nawet ATtiny2313 który przecież całego RAM'u ma bidulek, tylko 128 bajtów

z tym, że pisałem właśnie o tym uporządkowaniu i usystematyzowaniu tych moich pomysłów na ten drugi sposób, bo realizowałem to wielokrotnie, ale prawie zawsze nieco inaczej (wiesz jak jest) i ciężko byłoby to wyjaśnić wtedy w szczegółach. A tymczasem gdy człowiek usiądzie, pomyśli (sam tak przecież masz - jesteś mistrzem w tym!) napisze jakiegoś LIB'sika .... który nawet nie musi być zaraz tym NAJ... NAJ... lepszym libsikiem - ale umożliwi zrozumienie jak można do tego podchodzić - to wtedy jest fajnie ...

tylko to miałem na myśli

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

Dzięki za wszelkie sugestie.

Mirku mam nadzieje, że zależnościami czasowymi aż tak nie będę się musiał przejmować.
Parsowanie danych wejściowych (masa w ascii + parę innych drobnych komunikatów) to w zasadzie mam już załatwione .
Gorzej sprawa wygląda z obsługą wizfi po AT, bo po pierwsze nie wiem, czy iść w "ordynarne" wrzucanie do modułu za każdym włączeniem parametrów startowych, czy jednak zrobić jakieś zapytania.

Jakoś porównywanie stringów, taka wielka biblioteka do takiej pierdoły .

PS. Ależ Mirku nie musisz się tłumaczyć , po prostu Anty miał na myśli (przynajmniej tak mi się wydaje), że ty masz już obcykane te parsowanie i nawet ja by cie obudzić o 3 rano to byś sparsował nawet zapytanie do serwera sql po rs232.
No ale ja to ja, nie widzę pewnych aspektów od razu.

Przykład funkcja z twojej biblioteki at_lcd_service(....)
gdzie pasowane są dane dla wyświetlacza, dla mnie to jakiś potwór .
Przydało by się za każdym razem takie tłumaczenie jak na stronie 431 greenbooka, toż to poezja
Przykładowy "tekst" a potem rozłożenie go na czynniki .

U mnie lata sporo więcej, bo np. (nie wiem czy uda mi się oddać wygląd z terminala) tu jest ręczne łączenie,
ale np. jeżeli APek nie będzie odpowiadał już przy AT+WA=Teraoka, wywali [ERROR] na terminal, zamiast [OK].


Nie wiem, czy nie chcę za dużo, ale jakaś obsługa błędów by się przydała.
Procek to będzie Atmega644P (PA) więc flasza sporo, ramu też w miarę.

Jak ci biblioteka za duza to sobie wez strcmp z implementacji standardowej i ja przerob pod siebie:

Dzięki, o tym też pomyślałem .

Tzn o tym (wydaje mi się), że będziesz musiał pomyśleć ... i już tłumaczę dlaczego

tzn wiem że parsowanie masz już obcykane i super ... ale rozmowa z modemami za pomocą komend AT wymaga czy tego chcesz czy nie chcesz timeoutów. Tzn o ile chcesz to zrobić dobrze .... Bo fakt można to pominąć ... i jakoś tam na sztywno gadać z modemem ...

to jednak pragnę zwrócić uwagę na pewien fakt, który po jakimś czasie zacznie (chyba jak każdemu kto zaczyna tą zabawę) spędzać czas z oczu, przyprawiać o siwe włosy albo ich utratę przez wyrywanie sobie z głowy ...

do rzeczy ...

1. rozważmy taki przypadek - wysyłasz polecenie AT i .... kurka wodna nie dostajesz ŻADNEJ odpowiedzi ... i na co wtedy zda się całe parsowanie ? .... pomyśl co się w takich sytuacjach może dziać ... i nie zakładaj, że tobie się one nigdy nie pojawią. Albo że to są tylko jakieś strachy na lachy - bo to nie jest straszenie tylko zwrócenie uwagi na pierwszy podstawowy aspekt każdej ASYNCHRONICZNEJ i dobrze obsłużonej komunikacji. Zwykle osoby zaczynające zabawę w komunikację komendami AT ale w kierunku DO MODEMU na tym łamią pierwsze zęby

2. drugi przypadek to standardowy komunikat ERROR w komedach AT, który wymaga czasem niezłych rozgałęzień w programie tu też zaczyna się często HARDCORE ... bo taki niewinny napis ERROR trzeba np czasem obsłużyć w ten sposób aby ponownie wysłać komendę (o ile pewni jesteśmy jej składni) a do tego przewidzieć po drodze to co wyżej w pkt.1 czyli TimeOUT

3. kolejny przypadek to np odpowiedzi z modemu gdy nadlatuje UWAGA! może się z tym jeszcze nie spotkałeś - PACZKA STRINGÓW hmmm może inaczej LISTA STRINGÓW ... a dopiero na samym końcu komunikat "OK" - to jest "smakowity kąsek" do kodowania

Generalnie gdy oprogramowuje się to na PC, gdzie człowiek ma pod ręką sprzętowe WĄTKI - to jest dużo łatwiej ... a tu? ... a tu trzeba się troszkę namęczyć

a pewnie (odnoście pkt nr.1) nie chciałbyś mieć takiej sytuacji, że kiedyś urządzenie zrobi totalną zwiechę bo po wysłaniu AT+COŚTAM będziesz czekał na odpowiedź ...

I to miałem na myśli pisząc o zależnościach czasowych - stąd moja sugestia aby od razu myśleć o tym - tak zawczasu, bo później przerobić program - oj będzie ciężko ...

co więcej - żeby dobrze się dogadywać z modemem to gdy zdarzy się TimeOUT zawsze warto co najmniej 3 razy powtórzyć wysłanie tego samego polecenia i dopiero po kilku powtórzeniach timeoutu ostatecznie podjąć decyzję w programie o tym, że mamy jakąś awarię ... choć nie zawsze musi to oznaczać awarii całego modemu - tylko jakiejś jego części że tak powiem ...

No generalnie dużo można by pisać o tym jakie są sposoby podejść do komunikacji za pomocą komend AT

ale na pewno te przeróżne wyrywkowe pokazywane przykłady czy to w internecie czy w niektórych publikacjach - często w ogóle nie poruszają tego bardzo ważnego zagadnienia i później mamy taki efekt, że ktoś coś zrobi ... i pojawiają się kłopoty z których nawet nie wiadomo jak wybrnąć ... dopiero długa żmudna analiza i praca z tym umożliwia dojście do takich wniosków. A jest to o tyle niewdzięczna analiza że niestety takiego głupiego Timeouta nie uda się wywołać na zamówienie szczególnie podczas próby odbioru nagle dużej ilości danych - bo tu bywają one najgorsze.

wiem wiem ... może to co piszę to trochę takie masło maślane ... i wygląda jakbym się mądrzył czy straszył czymś .... co przecież zwykle w takich prostych testach prawie nigdy się nie zdarza. No ale ... kurczę na prawdę uważam, że jest to zagadnienie warte uwagi i przemyślenia chociaż ... I to właśnie to podejście chcę sam sobie usystematyzować - jak się uda to wtedy będę w stanie to dokładnie opisać i w kodach pokazać - a na razie tylko sygnalizuję.

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

Nie wiem czy nie przekombinowałem



A tu main.c

taki mały hint zamiast tego



korzystaj pan z bibliotek wbudowanych, będzie łatwiej, prościej, lepiej, szybciej i przyjemniej ... o np tak



albo:



bardzo przydatna funkcja w wielu przypadkach - a leży gotowa i się marnuje - no nie ?

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

Dzięki Mirku za wszelkie sugestie, o tym, jak to ładnie określiłeś obsługiwaniu błędów cały czas myślę i spędza mi to sen z powiek . Bo projekt poważny i nie ma to tamto .
30 urządzeń będzie na raz włączanych, i po pierwsze musi być bardzo dobrze ogarnięte które ma problem, po drugie, w przypadku jak padnie coś to nie chciał bym za każdym razem jeździć do Ustki .

Do tych timeoutów świetnie nada się softwerowy timer,
będę was zamęczał moimi wypocinami .