Stabilność modułów ESP8266: Czy wersja 01 radzi sobie w projektach NTP?

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.

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)?

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.

W dodatku znacząco zmniejszył się czas odpowiedzi na pinga.
http://bbs.espressif.com/viewtopic.php?f=5&t=154

To jest nowa wersja softu, który był oryginalnie czy to jakaś alternatywa?

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?

Interesuje czy ten moduł ma takie właściwości, że może być serwerem z
ustalonym IP i się łączymy się do niego po telnecie i to co on odbierze
przez sieć to wypluwa na rs232 i odwrotnie, taki konwerter sieć<->rs232?

W dniu 2015-01-30 o 15:57, jacek pozniak pisze:

Interesuje czy ten moduł ma takie właściwości, że może być serwerem z
ustalonym IP i się łączymy się do niego po telnecie i to co on odbierze
przez sieć to wypluwa na rs232 i odwrotnie, taki konwerter sieć<->rs232?

Nie do końca. To znaczy o ile mi wiadomo moduł nie ma trybu
"przezroczystości", tak jak w najpopularniejszych modemach GSM -
zestawiasz połączenie między urządzeniami i od tego czasu modem
zachowuje się jak "kawałek kabla", po prostu przerzucając bajty z jednej
strony na drugą.

Wszystkie przychodzące dane pojawiają się w terminalu wraz z komendą do
sparsowania:

+IPD=<x>,<y>:<dane

Gdzie x to numer socketa, y oznacza ilość odebranych danych, a dane to
odebrany ciąg. Możesz też ustawić tryb, w którym obsługiwane jest tylko
jedno połączenie w danym czasie - wówczas rezygnujesz z pierwszego
parametru.
Dzięki, tak mogłoby być, dane to ja sobie poobieram z tych nagłówków.

Moduł może pracować jako serwer i nawet całkiem wygodnie stawia się na
nim telnet - uruchamiasz serwer, a każdy kolejny klient zajmuje sobie
kolejny wolny socket. Każda wysłana linijka przylatuje do ciecie jako IPD.

Dzięki, tak mogłoby być, dane to ja sobie poobieram z tych nagłówków.

W dniu 2015-01-30 o 16:43, jacek pozniak pisze:

Dzięki, tak mogłoby być, dane to ja sobie poobieram z tych nagłówków.

Jak robisz prostą komunikację w rodzaju telnetu, gdzie pojedyncze
polecenie zamyka się w jednej linijce, to nie ma problemu. Możesz sobie
nawet odpuścić liczenie napływających znaków i porównywanie tej liczby z
parametrem po IPD. W miarę bezpiecznie można założyć, że \r\n kończy nam
całą ramkę. Trochę gorzej z bardziej skomplikowanymi protokołami, jak
HTTP.
Nie, tylko trochę danych; zapytanie z komputera 6 bajtów i odpowiedź z

Atlantis wrote:

W dniu 2015-01-30 o 16:43, jacek pozniak pisze:

Dzięki, tak mogłoby być, dane to ja sobie poobieram z tych nagłówków.

Jak robisz prostą komunikację w rodzaju telnetu, gdzie pojedyncze
polecenie zamyka się w jednej linijce, to nie ma problemu. Możesz sobie
nawet odpuścić liczenie napływających znaków i porównywanie tej liczby z
parametrem po IPD. W miarę bezpiecznie można założyć, że \r\n kończy nam
całą ramkę. Trochę gorzej z bardziej skomplikowanymi protokołami, jak
HTTP.
Nie, tylko trochę danych; zapytanie z komputera 6 bajtów i odpowiedź z
urządzenia z podłączonym tym modułem, max 256 bajtów.
To chyba powinien dać radę?
Tylko, że to dane binarne.

jp