Kiedyś zacząłem pisać maszynę stanów do obsługi modułu ESP8266. Nawet to
zaczynało działać - kod przeprowadzał inicjację modułu i odbierał
pakiety UDP. Jednak prace przerwałem, bo w międzyczasie przyjrzałem się
bliżej SDK od Espressif przekonując się, że dużo łatwiej można to
załatwić pisząc własny soft dla modułu.
Projekt planowałem wskrzesić z myślą o jakimś module GSM, ale teraz tak
sobie myślę... Może pisanie tego samemu jest wyważaniem otwartych drzwi?
Naprawdę nikt do tej pory niczego takiego nie napisał?
Wszystkie przykłady jakie widzę w sieci to typowe dla środowiska
użytkowników Arduino operowanie delay'ami i czekanie w pętli na wynik
działania ostatniej komendy.
Nikt nie stworzył biblioteki, która obsługiwałaby taki SIM300/SIM900 bez
blokowania procesora? Trochę to dziwne, biorąc pod uwagę fakt, że
komendy AT to rozwiązanie stare jak świat. Może ktoś ma namiary na taki kod?

do góry

On Mon, 19 Oct 2015 09:33:35 +0200, Atlantis <m...@w...pl>
wrote:
> Naprawdę nikt do tej pory niczego takiego nie napisał?

Pytałem pół roku o to samo, odpowiedziałeś, że masz przykłady
nieblokującwgo kod u w książce Kardasia i coś tam sobie
wykombinujesz.
W końcu usiadłem i napisałem nieblokujący driver do sim900d,
obsługuje sms (text/pdu) bez poolingu, komunikaty sieciowe
(forwarduje na inny nr), udp, tcp.

--
Marek

do góry

W dniu 2015-10-19 o 11:48, Marek pisze:

> Pytałem pół roku o to samo, odpowiedziałeś, że masz przykłady
> nieblokującwgo kod u w książce Kardasia i coś tam sobie wykombinujesz.

To musieliśmy się źle zrozumieć. W "greenbooku" Kardasia faktycznie jest
całkiem fajnie napisania, nieblokująca biblioteka do obsługi komend AT.
Tyle tylko, że tutaj chodzi o drugą stronę - sterowanie własnym
projektem za pomocą tych komend.
Można więc powiedzieć, że jest to "serwer", a nie "klient". Trudno
byłoby w prosty sposób przerobić to na mechanizm służący do obsługi
modemu, gdzie trzeba pilnować kontekstu, czekać na kilka linii
następujących po sobie itp.

Twój kod jest może gdzieś dostępny, czy to zamknięty projekt?

do góry

On Mon, 19 Oct 2015 12:24:41 +0200, Atlantis <m...@w...pl>
wrote:
> Twój kod jest może gdzieś dostępny, czy to zamknięty projekt?

Specjalnie tajny nie jest, tylko nie wiem czy się w nim połapiesz, bo
jest mocno "deweloperski", nieelegancki i nie jest udokumentowany.
Aczkolwiek działa. Mogę Ci go udostępnić jeśli obiecasz, że go
rozwiniesz, uporządkujesz bez ograniczania aktualnej funkcjonalności
i będziesz mnie informował o błędach jakie znajdziesz.

--
Marek

do góry

I co, widzę że prpozycja nie do zaakceptowania? :-)

--
Marek

do góry

W dniu 2015-10-19 o 12:42, Marek pisze:

> Aczkolwiek działa. Mogę Ci go udostępnić jeśli obiecasz, że go
> rozwiniesz, uporządkujesz bez ograniczania aktualnej funkcjonalności i
> będziesz mnie informował o błędach jakie znajdziesz.

Chętnie rzucę okiem, chociaż pewnie minie jeszcze kilka tygodni, zanim
będę mógł się zabrać za projekt wykorzystujący ten moduł.
BTW dla jakiej platformy powstał oryginalny kod? PIC32?

do góry

On Tue, 20 Oct 2015 10:25:35 +0200, Atlantis <m...@w...pl>
wrote:
> Chętnie rzucę okiem, chociaż pewnie minie jeszcze kilka tygodni,
zanim
> będę mógł się zabrać za projekt wykorzystujący ten moduł.
> BTW dla jakiej platformy powstał oryginalny kod? PIC32?

Tak, ale elementy kodu (hal) charakterystyczne dla pic32
(inicjalizacja uarta) są wydzielone #ifdef więc łatwo je zastąpić
własnymi, reszta to czyste C. Jeśli to miałoby pójść pod 8 bitowcem
to
jedyne co mógłbyś zrobić to pozamieniać int na char w zwrotach
funkcji oraz argumentach tam gdzie zakres argumentu w kontekście
funkcji dopuszcza char/unsigned char, coby zaoszczędzić po jednym
bajcie. Nie chciało mi się pisać kodu przyjaznego do 8 bitowca
(używać char gdzie jego zakres jest wystający) bo i tak używam ten
kod tylko z pic32 a int dla arch. pic32 jest wygodniejszy i szybszy.
Ale z ciekawości dziś skompiluje ten kod pod 8 bitowca, to będzie
orientacyjnie wiadomo ile flash/ram biblioteka zajmuje.

Napisałem krótkie howto do tego api, podaj email to Ci je wyślę, na
podstawie tej lektury zorientujesz się o poziomie trudności i
przydatności.

--
Marek

do góry

Po skompilowaniu na 8 bitowca kod zajął 11kB flash i 1.1kB ram

--
Marek

do góry

W dniu 2015-10-20 o 13:12, Marek pisze:

> Po skompilowaniu na 8 bitowca kod zajął 11kB flash i 1.1kB ram

To naprawdę niezły wynik. I tak prawdopodobnie użyję xmegi, albo
przynajmniej którejś z większych atmeg.
Jeśli możesz, podeślij wspomniane materiały na gmaila: marekw1986.

BTW, "filozofia" programowania PIC32 bardzo różni się od ośmiobitowych
kontrolerów z tej rodziny? Czy też należy je traktować jako naturalne
"rozszerzenie" i sposób korzystania z GPIO albo konfigurowania
peryferiów jest podobny?

do góry

On Wed, 21 Oct 2015 09:00:24 +0200, Atlantis <m...@w...pl>
wrote:
> BTW, "filozofia" programowania PIC32 bardzo różni się od
ośmiobitowych
> kontrolerów z tej rodziny? Czy też należy je traktować jako
naturalne
> "rozszerzenie" i sposób korzystania z GPIO albo konfigurowania
> peryferiów jest podobny?


Są te same nazwy rejestrów specjalnych (GPIO) np. PORTC, TRISC, LATC
itd. stąd kod jest przenośny. Ze względu na to, że na pic32 dostęp do
tych "standardowych" rejestrów w trybie kompatybilności wstecznej nie
jest już atomowy co może być w niektórych przypadkach problematyczne
(LATC=0 wykona się w kilku rozkazach) to dodano do każdego rejestru 3
rejestry specjalne, dzięki którym można przestawiać pojedyncze bity
atomowo, np LATCSET, LATCCLR i LATCINV, np. LATCSET=2 ustawi tylko
drugi bit na porcie C bez ingerencji w pozostałe (rozwiązuje problem
z read-modify-write).

--
Marek

do góry