W dniu 2015-01-29 o 14:13, Marek pisze:

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

Hmm... W takim razie coś takiego z grubsza już kiedyś robiłem. W jednym
z projektów zachodziła konieczność cyklicznego wysyłania żądania
aktualizacji NTP oraz uploadowania paru danych na serwer. Układ
wykorzystywał ENC28J60 wraz ze stosem Tuxgraphics, a więc nie było
możliwości przeprowadzenia większości operacji automatycznie, w tle.

Trzeba było przy tym sprawdzić kilka warunków:
- Czy w konfiguracji podano numer IP celu, czy też nazwę hosta do
rozwiązania przez DNS.
- Czy cel znajduje się w naszej sieci, czy gdzieś w Internecie (od tego
zależało jakiego adresu MAC użyjemy w kolejnym etapie).
Oznaczało to konieczność odpytywania stosu o różne rzeczy, w dodatku
trzeba było pilnować, aby kolejne wywołanie nie szło przed zakończeniem
poprzedniego.

Zrobiłem to właśnie przez dwie zmienne (jedna dla NTP, druga dla klienta
TCP), które pilnowały na jakim etapie obecnie znajduje się operacja. W
pętli głównej podejmowana była odpowiednia akcja, stosowanie do stanu
zmiennej.

do góry

On Fri, 30 Jan 2015 09:33:26 +0100, Atlantis <m...@w...pl>
wrote:
> 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?

--
Marek

do góry

W dniu 2015-01-30 o 13:50, Marek pisze:

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

Zdaniem ludzi z elektroda.pl to oficjalny soft.
Niemniej trudno powiedzieć - w tej materii z tego co widzę panuje spory
bałagan, a lepszej dokumentacji brak...

do góry

Chciałbym sie przy okazji podczepiś do wątku o tym module i zadać pytanie.

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?


jp

Atlantis wrote:

> 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

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.

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.

do góry

No i oczywiście moduł niczego nie wypluwa po RS232, ale po UART z
poziomami logicznymi 3,3V. Podłączając go do RS232 bez konwertera
zniszczysz go natychmiast.

do góry

Atlantis wrote:

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

Dzięki
jp

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

do góry

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.

do góry

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

jp

do góry

jacek pozniak wrote:

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

do góry