Ktoś z was miał może już jakieś większe doświadczenia z tym popularnym
modułem? Ja dopiero zaczynam eksperymenty - pobawiłem się połączeniami
pod terminalem, ale jeszcze nie złożyłem na nim żadnego większego
projektu z MCU. Powoli projektuję jednak płytkę zegara nixie z
synchronizacją czasu po NTP.
Czy moduł można uznać za stabilny? To znaczy raz włączony będzie działał
bez samodzielnego zawieszania się? Nie liczę tutaj oczywiście sytuacji,
do których może dojść z winy użytkownika.

Pytam, ponieważ rozpoczynając eksperymenty z ENC28J60 (a później także
W5100) natknąłem się na kilka mitów dotyczących ich stabilności. Układy
miały się rzekomo nie nadawać do zastosowań takich jak automatyka domowa
czy telemetria, ze względu na tendencję do samodzielnego wieszania się i
zrywania połączeń. Tymczasem praktyka pokazała coś zupełnie innego -
zaprojektowane przeze mnie płytki z tymi układami działają już dobre pół
roku i przez ten czas udawało im się nabijać uptime liczony w
tygodniach, jeśli nie miesiącach.

Czy istnieje jakaś różnica w stabilności pomiędzy poszczególnymi
wersjami modułów? Bo na rynku dostępnych jest kilkanaście różnych odmian
- zaczynając od najpopularniejszej "01" (antena PCB i goldpiny) kończąc
na znacznie bardziej profesjonalnie wyglądających modułach z anteną
ceramiczną i metalowym ekranem nad elektroniką.

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?

do góry

On Tue, 27 Jan 2015 10:06:31 +0100, Atlantis <m...@w...pl>
wrote:
> Ktoś z was miał może już jakieś większe doświadczenia z tym
popularnym
> modułem


Poszukaj w archiwum, kilka miesięcy temu była dyskusja o jego
stabilności, kilku użytkowników opowiedziało swoje doświadczenia.
Ogólnie nie jest źle.

--
Marek

do góry

Hmm... Wczoraj zauważyłem ciekawą kwestię w związku z działaniem tego
modułu. Najpewniej w oprogramowaniu jest jakiś błąd, bo połączenia UDP
nie chcą działać prawidłowo, gdy korzystam z DNS-a. W przypadku TCP
wszystko jest w porządku - po podaniu nazwy hosta (np. google.pl)
połączenie zostało zestawione i udało mi się wymienić dane. Potem
spróbowałem połączyć się z serwerem NTP i zaczęły się dziać dziwne
rzeczy. System niby przyjął nazwę hosta (nie zwrócił "DNS fail") i
rozpoczął procedurę wysyłania danych ("AT+CIPSEND=4,48", zwrócony znak
">"). Niestety nie przebiegała ona tak, jak powinna - po otrzymaniu 48
bajtów program nadal oczekiwał na kolejne dane. Dopiero wysłanie mu
sporego nadmiaru danych (w tym chyba jakiejś komendy zakończonej "\r\n")
spowodowało wyświetlenie błędu. Od tego momentu miałem już tylko "Busy
inet..." i z modułu nie dało się korzystać.
Próba połączenia się z serwerem NTP przez podanie numeru IP daje
pozytywny skutek - moduł po otrzymaniu 48 bajtów zwraca "SEND OK".

Czy ktoś z Was zetknął się z podobnym błędem? Może dostępna jest jakaś
nowsza wersja firmware'u z odpowiednią poprawką?

BTW ktoś wie coś na temat jakiejś biblioteki do obsługi tego modułu?
Wszystko co widzę w sieci (głównie rozwiązania dla Arduino) wykorzystują
spore delay'e do oczekiwania na odpowiedź modułu. Ja preferowałbym
jednak rozwiązanie oparte o flagi i zdarzenia, mam ogólny zamysł jak to
mogłoby wyglądać, ale nie chciałbym wyważać otwartych drzwi - zawsze
łatwiej przeportować gotową bibliotekę, niż pisać własną od podstaw.

do góry

On Wed, 28 Jan 2015 08:27:14 +0100, Atlantis <m...@w...pl>
wrote:
> Czy ktoś z Was zetknął się z podobnym błędem? Może dostępna jest
jakaś
> nowsza wersja firmware'u z odpowiednią poprawką?

http://www.electrodragon.com/w/ESP8266#Latest_firmwa
re

http://blog.electrodragon.com/cloud-updating-your-wi
07c-esp8266-now/



> BTW ktoś wie coś na temat jakiejś biblioteki do obsługi tego modułu?
> Wszystko co widzę w sieci (głównie rozwiązania dla Arduino)
wykorzystują
> spore delay'e do oczekiwania na odpowiedź modułu.

Mógłbyś jaśniej to opisać, po co delaye skoro muszą i tak czekać na
odpowiedź?

--
Marek

do góry

On Wed, 28 Jan 2015 10:08:15 +0100, Marek <f...@f...com> wrote:
> Mógłbyś jaśniej to opisać, po co delaye skoro muszą i tak czekać na
> odpowiedź?

A chyba już wiem, wysyłają polecenie AT, delay oczekując na
odpowiedź, po czym sprawdzają bufor odbiorczy uarta... ależ to jest
bardzo nieefektywne, zamiast delay procek mógłby robić w tym czasie
coś innego.

--
Marek

do góry

W dniu 2015-01-28 o 10:33, Marek pisze:

> A chyba już wiem, wysyłają polecenie AT, delay oczekując na odpowiedź,
> po czym sprawdzają bufor odbiorczy uarta... ależ to jest bardzo
> nieefektywne, zamiast delay procek mógłby robić w tym czasie coś innego.

No właśnie wiem. ;)
Dlatego gdybym ja się za to zabierał, to wszystko robiłbym na flagach i
zdarzeniach. Na przykład wysyłając dane ustawiamy odpowiednią flagę i
podajemy funkcji w pętli głównej wskaźnik do bufora. Dopóki flaga jest
ustawiona, nie możemy rozpocząć kolejnego wysyłania, a czyści się ją po
odebraniu "SEND OK".
Podobnie można postąpić z "ready" i innymi sygnałami kontrolnymi.
Sprawdzane byłoby też pojawienie się ">\r\n".
Oczywiście wszystkie odpowiedzi byłyby odbierane i parsowane "w tle",
przez funkcję w pętli głównej.

Nieco problematyczny jest tylko odbiór danych, które mogą się pojawić w
dowolnym momencie jako "+IDP,<soc>,<len>:<data>\r\n".
Sęk w tym, że ciąg danych może składać się z większej ilości linii, więc
odebranie "\r\n" nie musi oznaczać końca odbioru danych. Trzeba by dać
instrukcję warunkową, która sprawdza czy linijka po ":" zawiera mniej
znaków niż "len" - jeśli tak, trzeba by uruchomić specjalny tryb odbioru
danych, w którym kolejne napływające znaki nie są parsowane jako
komendy, ale doklejane do końca bufora, aż do pobrania zadanej ilości.

do góry

W dniu 2015-01-28 o 10:08, Marek pisze:

> http://www.electrodragon.com/w/ESP8266#Latest_firmwa
re
> http://blog.electrodragon.com/cloud-updating-your-wi
07c-esp8266-now/

To jest najnowsza, oficjalna wersja firmware'u, czy jakieś alternatywne
oprogramowanie, zmodyfikowane przez kogoś ze społeczności użytkowników?

do góry

On Wed, 28 Jan 2015 10:52:52 +0100, Atlantis <m...@w...pl>
wrote:
> Podobnie można postąpić z "ready" i innymi sygnałami kontrolnymi.
> Sprawdzane byłoby też pojawienie się ">\r\n".
> Oczywiście wszystkie odpowiedzi byłyby odbierane i parsowane "w
tle",
> przez funkcję w pętli głównej.
> Nieco problematyczny jest tylko odbiór danych, które mogą się
pojawić w
> dowolnym momencie jako "+IDP,<soc>,<len>:<data>\r\n".

Obsługę modemu robi się maszyna stanów i bufirem fifo uarta, nie ma
wtedy problemu z "unsolicited codes".

--
Marek

do góry

On Wed, 28 Jan 2015 11:35:15 +0100, Atlantis <m...@w...pl>
wrote:
> To jest najnowsza, oficjalna wersja firmware'u, czy jakieś
alternatywne
> oprogramowanie, zmodyfikowane przez kogoś ze społeczności
użytkowników?

Z tego co czytałem chyba nie istnieje "oficjalna" nowa wersja, nowe
sa tylko wersje społecznościowe. Ale mogę się mylić.

--
Marek

do góry

W dniu 2015-01-28 o 12:14, Marek pisze:

> Obsługę modemu robi się maszyna stanów i bufirem fifo uarta, nie ma
> wtedy problemu z "unsolicited codes".

Hmm... Możesz napisać coś więcej? Sam nie bawiłem się tym jeszcze, ale z
tego co widzę po znajomych, to sporo osób (przyzwyczajonych do obsługi
modułów Ethernet na SPI) narzeka na rozwiązanie przyjęte w ESP8266. Z
drugiej strony praktycznie taki sam mechanizm od lat stosuje się w
modemach, więc muszą istnieć jakieś sprawdzone rozwiązania. ;)

do góry