W dniu 2015-01-27 o 10:06, Atlantis pisze:
> Może mity biorą się od początkujących użytkowników Arduino, którzy nie
> wiedzą, że taki moduł potrzebuje jednak odpowiednio wydajnego źródła
> zasilania i kondensatorów filtrujących w pobliżu pinu VCC?

Niekoniecznie to są mity.
Mi W5500 po kilku, kilkunastu godzinach testów obciążeniowych potrafi
"odłączyć" socket w trybie UDP (brak przerwań, nie zwiększa się licznik
ilości danych odebranych, zawartość wszystkich rejestrów wygląda poprawnie).
Niestety, nie udało mi się jak dotąd stworzyć reguły dającej 100%
pewności, że socket się zawiesił i trzeba go ponownie zainicjować.

--
AWa.

do góry

On Wed, 28 Jan 2015 12:26:50 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... Możesz napisać coś więcej?

Oj to dużo pisania, trochę nie na temat grupy. Ale tak ogólnie to są
dwie ważne sprawy, pierwsza to prawidłowa obsługa bufora cyklicznego
fifo, do którego pisze przerwanie uarta po odebraniu znaku. Bardzo
fajnie jest to opisane w tym dokumencie (od strony 36)

http://cache.freescale.com/files/microcontrollers/do
c/app_note/AN2120.pdf

(nota bene dokument opisuje fajną minimalistyczną implementację
ppp/tcp/udp na 8 bit mcu, sprawdzone, działa). Drugi bufor, to
podręczny bufor api (aplikacyjny), do którego są "wyciągane" z fifo
kolejne znaki i na podstawie jego zawartości api przełącza się w
odpowiednie stany, obsługujące dane zdarzenie. Druga sprawa to
opisanie wszystkich możliwych stanów maszyny. Najważniejszym stanem
jest SM_IDLE, w której się oczekuje na "unsolicited codes". Kolejnym
stanem może być np. SM_RECEIVE_SMS, w który się przełączamy ze stanu
SM_IDLE po odebraniu np. +CMTI i powrót z powrotem do SM_IDLE, gdy
zakończyliśmy procesowanie odebranego smsa. Zaletą takiego modelu
jest to, że każdy stan jest nieblokujący mcu: gdy nie ma żadnego
znaku do pobrania z fifo to nie ma nic do roboty i można wrócić do
"main_loop". Gdy jest znak to go wyciągamy z fifo i sprawdzamy czy po
"dołożeniu" go do lokalnego bufora mamy już kompletną odpowiedź
modemu, jeśli nie znowu wracamy do "main_loop". Natomiast gdy mam już
kompletną odpowiedź to ją identyfikujemy i przełączamy się na
odpowiedni stan aby ją przeprocesować. Gdy api jest dłużej w jakimś
stanie procesującym (nie sprawdza czy coś jest "nowego" w fifo),
nieoczekiwane dane z modemu nie zginą bo są buforowane przez
przerwanie piszące do fifo. Te dane zostaną odebrane z fifo po
powrocie do stanu SM_IDLE.

"Unsolicited codes" nie pojawiają się np. w połowie odpowiedzi na
jakieś polecenie AT, stąd nie ma zagrożenia, że popsują kontekst tej
odpowiedzi (innego polecenia). Na uarcie musi być chwilowa cisza
między komendami AT aby modem zwrócił taki kod. Sposób wysyłania tych
kodów konfiguruje się poprzez AT+CNMI, najbezpieczniejsze jest
AT+CNMI=3,1,0,0,0 bo to własnie włącza buforowanie sygnalizacji
zdarzenia (gdy wystąpi w trakcie odpowiedzi na inne polecenie lub gdy
modem jest w trybie data a nie command). W takim przypadku kod
zostanie przesłany po zakończeniu transmisji poprzedniej odpowiedzi
(pod warunkiem chwilowej "ciszy", o której wspomniałem wyżej).

To tak bardzo ogólnie. Oczywiście każdy stan może mieć swój "lokalny"
idle, w których czeka np. na OK\r\n po jakimś poleceniu. Jak się
podgląda taka komunikację "nodelay" na uarcie to bardzo ładnie ona
wygląda, jest szybka i płynna.

--
Marek

do góry

BTW mam jeszcze jedno pytanie co do tego modułu.
Jaki jest właściwy sposób jego podłączenia? Na większości stron z
przykładami dla Arduino podaje się następujące rozwiązanie:

VCC - wiadomo, zasilanie 3.3V
GND - wiaodmo, masa
RX - pin TX mikrokontrolera
TX - pin RX mikrokontrolera
CH_PD - podłączony bezpośrednio do VCC
RST, GPIO0 i GPIO2 - wiszące w powietrzu

W tej chwili mam moduł podłączony właśnie w ten sposób. Działa...
Niemniej nie podobają mi się pewne rzeczy:
1) Czy CH_PD nie powinien być podciągnięty rezystorem do VCC, a nie
połączony bezpośrednio?
2) Czy tak samo piny RST, GPIO0 i GPIO2 nie powinny mieć ustalonej
wartości przez podciągnięcie do VCC lub masy jakimś rezystorem?

Niektóre opisy radzą zresztą, żeby cztery środkowe piny podciągnąć do
plusa, można tak przeczytać np. tu:

http://rayshobby.net/first-impression-on-the-esp8266
-serial-to-wifi-module/

do góry

Nawet na główną Wykopu trafiło :)
http://www.wykop.pl/link/2367456/esp8266-tanie-i-lat
we-w-uzyciu-wifi/

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 70 days, 5 hours, 11 minutes and 18 seconds

do góry

W dniu 2015-01-28 o 16:23, Marek pisze:

> Oj to dużo pisania, trochę nie na temat grupy. Ale tak ogólnie to są
> dwie ważne sprawy, pierwsza to prawidłowa obsługa bufora cyklicznego
> fifo, do którego pisze przerwanie uarta po odebraniu znaku. Bardzo
> fajnie jest to opisane w tym dokumencie (od strony 36)

Z buforami cyklicznymi akurat jakoś sobie radzę - stosuję je standardowo
w swoich projektach, zarówno po stronie odbiorczej, jak i nadawczej.


> (nota bene dokument opisuje fajną minimalistyczną implementację
> ppp/tcp/udp na 8 bit mcu, sprawdzone, działa). Drugi bufor, to podręczny
> bufor api (aplikacyjny), do którego są "wyciągane" z fifo kolejne znaki
> i na podstawie jego zawartości api przełącza się w odpowiednie stany,
> obsługujące dane zdarzenie. Druga sprawa to opisanie wszystkich
> możliwych stanów maszyny.

Hmm... Czyli krótko mówią mogę zrobić to np. za pomocą tablicy, w której
będę trzymał typ strukturalny złożony z łańcucha tekstowego (wszystkie
możliwe komendy zmieniające stan) oraz jakiejś zmiennej (np. enum)
określającej ten stan.
Potem w pętli głównej cyklicznie pobieram kolejny znak z bufora
cyklicznego i na bieżąco sprawdzam (strncasecmp_P) czy zawartość bufora
pokrywa się z którymś z tekstów umieszczonych w tabeli. Jeśli tak -
ustawiam przypisany mu stan.
Oczywiście to, co odbywa się w danym momencie w pętli głównej musiałoby
zależeć od obecnego stanu - inaczej program zachowywałby się podczas
oczekiwania na komendę, inaczej podczas odbierania znaków składających
się na SMS-a albo nadchodzące dane TCP.

do góry

On Thu, 29 Jan 2015 08:36:13 +0100, Atlantis <m...@w...pl>
wrote:
> Hmm... Czyli krótko mówią mogę zrobić to np. za pomocą tablicy, w
której
> będę trzymał typ strukturalny złożony z łańcucha tekstowego
(wszystkie
> możliwe komendy zmieniające stan) oraz jakiejś zmiennej (np. enum)
> określającej ten stan.

Przykład szkieletu stanów i ich obsługi z moich wypocin:

typedef enum
{
SM_INITIALIZE=0,
SM_WAIT_FOR_INIT,
SM_EVENT_WAIT_INIT,
SM_EVENT_WAIT,
SM_RETR_SMS_R,
SM_RETR_SMS_W1,
SM_RETR_SMS_W2,
SM_SEND_INIT,
SM_SEND_WAIT1,
SM_SEND_P2, SM_SEND_WAIT2, SM_SEND_NETWORKQ_INIT,
SM_SEND_NETWORKQ_WAIT, SM_STATUS_GET,
SM_STATUS_WAIT,
SM_CALLOUT_SET,
SM_CALLOUT_WAIT,
SM_HANGUP_SET,
SM_HANGUP_WAIT
}SM_STATE;

static SM_STATE gsm_state;

void gsm_task()
{

switch (gsm_state)
{
case SM_INITIALIZE:
//
break;

case SM_WAIT_FOR_INIT:
//
break;
....

}
}

W pętli głównej w main () wywołujesz tylko gsm_task();. Zajrzyj do
pdfa do którego podawałem link w poprzednim poście, do źródła ppp.c,
cały ppp jest zrobiony na maszynie stanów.

--
Marek

do góry

No cóż... Dwie kolejne obserwacje:

1) Należy BARDZO uważać ze stosowaniem komendy AT+CIUPDATE, która ma
rzekomo przeprowadzać internetową aktualizację firmware'u modułu. Tak
naprawdę jednak (w zależności od wersji posiadanego FW) albo generuje
błędy, albo brickuje moduł - na szczęście odwracalnie.
2) W najnowszej wersji firmware'u AT
(http://www.electrodragon.com/w/ESP8266#Firmware) ciągle występuje błąd
z wysyłaniem danych UDP, jeśli korzystamy przy tym z DNS-a. Może
Chińczycy jeszcze go nie zauważyli? ;)

do góry

On Thu, 29 Jan 2015 17:55:42 +0100, Atlantis <m...@w...pl>
wrote:
> No cóż... Dwie kolejne obserwacje:


> 1) Należy BARDZO uważać ze stosowaniem komendy AT+CIUPDATE, która ma
> rzekomo przeprowadzać internetową aktualizację firmware'u modułu.
Tak
> naprawdę jednak (w zależności od wersji posiadanego FW) albo
generuje
> błędy, albo brickuje moduł - na szczęście odwracalnie.
> 2) W najnowszej wersji firmware'u AT
> (http://www.electrodragon.com/w/ESP8266#Firmware) ciągle występuje błąd
> z wysyłaniem danych UDP, jeśli korzystamy przy tym z DNS-a. Może
> Chińczycy jeszcze go nie zauważyli? ;)

Wcale się nie śmiej, w chińskiej dokumentacji do prostych
urządzeń/modułów używających tcp/up przykłady z adresami ip zamiast
nazw to standard, wcale bym się nie zdziwił, że nie przetestowali z
nazwami hosta.
Nawę hosta na pewno prawidłowo podajesz w argumencie polecenia
(cytowanie stringa)?

--
Marek

do góry

W dniu 2015-01-29 o 18:27, Marek pisze:

> Wcale się nie śmiej, w chińskiej dokumentacji do prostych
> urządzeń/modułów używających tcp/up przykłady z adresami ip zamiast nazw
> to standard, wcale bym się nie zdziwił, że nie przetestowali z nazwami
> hosta.

Będę musiał sprawdzić, czy da się do kogoś w tej sprawie napisać...


> Nawę hosta na pewno prawidłowo podajesz w argumencie polecenia
> (cytowanie stringa)?

Testuję pod terminalem, zapis wygląda następująco:
AT+CIPSTART=4,"UDP","time.windows.com",123\r\n
Gdzie \r" to znak powrotu, a "\n" to znak nowej linii.

do góry

Hmm... Wgranie poniższego softu usunęło problem.
W dodatku znacząco zmniejszył się czas odpowiedzi na pinga.

http://bbs.espressif.com/viewtopic.php?f=5&t=154

do góry