Maszyna stanów do obsługi modułu GSM

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.

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?

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.

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

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?

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.

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

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?

ośmiobitowych

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

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

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?

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.

On Sun, 25 Oct 2015 22:10:11 +0100, Atlantis snipped-for-privacy@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.

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?

Tak, też z gmail, sprawdź spam.

wyjaśniło się, była liiterówka w adresie, mail dostał ktoś inny. Wysłałem już na prawidłowy, mam nadzieję.

On 2015-10-25 23:37, Marek wrote: [...]

No z tą naturalnością wyboru to bym nie przesadzał. Przecież PIC32 ma zupełnie inny rdzeń. A to, że tytani intelektu z działu marketingu Microchipa wymyślili sobie, że nazwą ichnią wersję MIPS-a PIC32 to jest zupełnie inna sprawa.

Może po prostu pytaj o ludzi mających pojęcie o MIPS-ach. :-)

Wiadomo, że inny ale co z tego? Jeśli w api zachowali semantykę podstawowych rejestrów z pic16/pic14 to dzięki temu migacz diodą typowa gospodyni domowa z Gdańska znająca pic14/16 zrobi tak samo na pic32? :-)

No był tu jeden partyzant od rodzinnego programowania mipsów w asemblerze to go pogoniliście jak wszystkim na Święta życzył błogosławieństwa Bożego :(.