Od maszyny stanów do SIM300/SIM900 - brak bibliotek bezblokujących w Arduino?

Mon Oct 19, 2015 7:33 am   

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?

Mon Oct 19, 2015 9:48 am   

On Mon, 19 Oct 2015 09:33:35 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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

Mon Oct 19, 2015 10:24 am   

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


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?

Mon Oct 19, 2015 10:42 am   

On Mon, 19 Oct 2015 12:24:41 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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

Mon Oct 19, 2015 11:03 pm   

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

--
Marek

Tue Oct 20, 2015 8:25 am   

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


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?

Tue Oct 20, 2015 8:57 am   

On Tue, 20 Oct 2015 10:25:35 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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

Tue Oct 20, 2015 11:12 am   

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

--
Marek

Wed Oct 21, 2015 7:00 am   

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


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?

Wed Oct 21, 2015 9:27 am   

On Wed, 21 Oct 2015 09:00:24 +0200, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


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

Fri Oct 23, 2015 5:52 pm   

Tytył książki: "Maszyna stanów logicznych"
Masakra jakaś. Żeby zwykly algorytm nazywać maszyną. To jak jakieś
podniecanie się wyborami partyjnymi żeby wzbudzić zainteresowanie.
Wogóle to nie ma co nazywać przechodzenie w pętli z jednego stanu do
drugiego bez blokowania.

Sorry.
Starość.

Fri Oct 23, 2015 10:33 pm   

On Fri, 23 Oct 2015 19:52:22 +0200, "pawel" <paw1976@poczta.onet.pl>
wrote:

akurat analogia (co z tego, że abstrakcyjnego bytu) do maszyny jest
dość trafna, być może bardziej po polsku "automat skończony"
bardziej by Ci pasowało?

--
Marek

Sun Oct 25, 2015 10:10 pm   

W dniu 2015-10-21 o 11:27, Marek pisze:


Hmm... Kupiłem kiedyś książkę do nauki PIC-ów ("Mikrokontrolery PIC w
praktycznych zastosowaniach" Borkowskiego). Z tego co widzę autor skupia
się na linii ośmiobitowych MCU od Microchipa. Na razie nie miałem czasu,
żeby bliżej im się przyjrzeć. Rozumiem, że gdy już jako-tako opanuję
"małe" PIC, to przejście na PIC32 nie powinno być problemem? Nie
potrzeba osobnego podręcznika/kursu, tylko wystarczy poczytać o
różnicach? To nie jest taka przepaść, jak pomiędzy AVR-ami a AT91SAM?

BTW udało Ci się może wysłać te materiały dotyczące biblioteki? Nic do
mnie nie dotarło.

Sun Oct 25, 2015 11:37 pm   

On Sun, 25 Oct 2015 22:10:11 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


Nie wiem jak jest między AVR. Między 8bitowcami PIC a PIC32 jest
oczywiście przepaść technologiczna, tutaj nie ma co ukrywać. Z tym że
MCHP swoim API dość zgrabnie ją przysłania. Podstawowe rejestry
związane z GPIO mają taka, samą semantykę, tak samo rejestry
kontrolujące spi, usart czy np. timery stąd user obeznany w 8bitowej
rodzinie odnajdzie się szybko w pic32 a kod z 8bit praktycznie bez
modyfikacji skompiluje i z powodzeniem uruchomi na pic32. Nie wiem
jaka jest różnica w środowiskach programistycznych jakie daje MCHP
(nie używam, używam własne oparte na Makefile+vim), ale ostatnio to
chyba zintegrowali i ich mplab x obsługuje wszystko w jednym
zunifikowanym środowisku (oparty na eclipse).
PIC32 oczywiście (jak każdy 32 bitowiec chyba) przy przejściu z 8
bitowców daje większą swobodę i komfort, nie trzeba już przejmować
się czy ram/flash starczy, przejmować się używaniem rozpychających
floatów, a domyślny int "starcza" na wszystko, itp. itd. Nie
wspominając już o np. o ogromnie pożytecznym "exception handler" czy
takim babake jak szybkości w działaniu.
Na Twoim miejscu skoro znasz już 8bitowce to nie interesował bym się
specjalnie 8bitowcami PIC, nie widzę potrzeby. No chyba, że
konkretnie zależy Ci na jakimś wbudowanym peryferiu, który nie ma
avr (np. strzelam: sterownik LCD?). Jeśli chcesz przejść na 32bit to
wybierz jakąś platformę, z każdej na pewno znajdziesz tutaj
fachowców. PIC32 jest ma pewno naturalnym wyborem dla tych co są
emocjonalnie i doświadczalnie związani z PIC, ale czy dla
wszystkich?
Oczywiście miło by było pogadać czasem tutaj z kimś o pic32 , jeden
kolega był ale po jakieś religijnej sprzeczce zniknał.


Wysłałem opis api, nie było reakcji, stąd uznałem, że nie jesteś
dalej zainteresowany.

--
Marek

Sun Oct 25, 2015 11:48 pm   

W dniu 2015-10-25 o 23:37, Marek pisze:


Hmm... Wygląda na to, że nic nie dotarło... Wysłałeś na marekw1986 [na]
gmail.com?