Brak komunikacji między Atmegą a modułem G SM po rs232 - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Polish to

Threaded View
Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-11 19:51, Atlantis pisze:
Quoted text here. Click to load it

Ale może mieć trochę mniej lub więcej. Jeśli częstotliwość będzie
miała  
odchyłkę ponad 3 procent to mogą być błędy transmisji.

--  
pozdrawiam
MD

Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-11 21:17, Mario pisze:

Quoted text here. Click to load it
miała
Quoted text here. Click to load it

Tylko zastanawia mnie dlaczego w przypadku komunikacji z komputerem  
wszystko jest ok...


Re: Brak komunikacji między Atme gą a modułem GSM po rs232
Quoted text here. Click to load it
miała
Quoted text here. Click to load it

Zmierz może w końcu oscyloskopem szerokość bitów, jak Ci już dwie osoby  
doradziły.

--  
Grzegorz Niemirowski
http://www.grzegorz.net/
We've slightly trimmed the long signature. Click to see the full one.
Re: Brak komunikacji między Atmegą a modułem GSM po rs232
A czytasz i ustawiasz bajt kalibracyjny generatora RC dla 8 MHz?

--  
Pozdrawiam
MM

We've slightly trimmed the long signature. Click to see the full one.
Re: Brak komunikacji między Atmegą a modułem GSM po rs232

Quoted text here. Click to load it

No to tu masz problem. Przerabiałem temat. Użyj zewnętrznego kwarcu i problem  
(jeżeli to jedyny problem) zniknie.

--  
Gof
http://www.chmurka.net/

Re: Brak komunikacji między Atmegą a mo dułem GSM po rs232
W dniu 2012-12-12 08:45, Adam Wysocki pisze:

Quoted text here. Click to load it

Hmm... Wygląda na to, że masz rację w sposób podwójny:

1) Istotnie po części wina musiała leżeć po stronie wewnętrznego  
rezonatora RC. Dałem kwarc 8 MHz i sytuacja się nieco poprawiła. To  
znaczy transmisja zaczęła być trochę stabilniejsza i udało mi się (po  
raz pierwszy) zainicjować moduł bez pomocy komputera, po wykręcając kod  
PIN na tarczy numerycznej. Potem też telefon jako tako działał, przy  
czym nie do końca stabilnie. Udało mi się na niego dodzwonić (pojawiła  
aktywność linii, które potem będą odpowiadały za sterowanie dzwonkiem).  
Parę razy też udało mi się wybrać numer.
Niestety nie wszystko działa stabilnie np. wybieranie numeru nie zawsze  
udaje mi się zrealizować (nie wiem jednak, czy to nie jest jakiś bug w  
kodzie). Nie zawsze też po włączeniu inicjacja przechodzi do końca.
Podsłuchałem dane zwracane przez modem i niestety - krzaczki nadal się  
pojawiają...

http://www.sendspace.pl/file/baf48b4c0760fb6b7b8c247

2) Sprawdziłem oscyloskopem jak wygląda przebieg na zasilaniu modemu  
(konkretnie na kondensatorze 1000uF). Na czas próby odpiąłem Atmegę i  
podłączyłem do stabilizatora jedynie D15. Gdy urządzeni nic nie robi -  
generalnie jest ładny, płaski przebieg. Problem zaczął się w przypadku  
wykonywania operacji. Przy wpisywaniu komend linią wyraźnie szarpało. Po  
wywołaniu numeru innego telefonu kompletnie się rozmyła. Dobierając  
podstawę czasu "znalazłem" taki oto przebieg, zbliżony do sinusoidy  
(przepraszam za jakość, zdjęcie zrobione niezbyt nowoczesnym aparatem...)

http://imageshack.us/photo/my-images/534/img89221.jpg/

Tego nie powinno tam być? ;)

Re: Brak komunikacji między Atmegą a mo dułem GSM po rs232
Ok, okazało się, że sinusoida była wynikiem nieodpowiedniego filtrowania  
- przeoczyłem kondensator 100nF w pobliżu pinów zasilania modułu GSM. Po  
jego dodaniu całość działa jakby stabilniej, chociaż nie wszystko jest  
do końca idealnie.
Nie każda inicjacja się udaje (nie zawsze pyta o pin) nie zawsze też  
udaje się zainicjować połączenie - po prostu jakby nie wysyłał  
AT*Dnumer. nawet na "podsłuchu" w terminalu nie widać, choć inne  
komunikaty przechodzą. Pomyślałbym, że to błąd w programie, gdyby s  
samym komputerem nie działało w 100% poprawnie.

Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-13 20:29, Atlantis pisze:
Quoted text here. Click to load it

Może to nie jest kwestia, że komunikacja z komputerem jest poprawna,  
tylko system pracuje stabilniej gdy masz połączoną masę komputera z masą  
urządzenia.

--  
pozdrawiam
MD

Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-13 21:17, Mario pisze:

Quoted text here. Click to load it

Hmm... Kwestia masy też mi przemknęła przez myśl. Tak prawdę mówiąc  
teraz nie wygląda to zbyt imponująco - ot, płytka uniwersalna i  
połączenia wykonane kabelkami z goldpinami.
Z drugiej strony masę komputera podpinam też do całości, "podsłuchując"  
komunikację między obiema płytkami. Poprawy wówczas nie dostrzegam. Nie  
widać jej też wówczas, gdy wtyczka programatora zostanie w gniazdku ISP.


Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-13 21:34, Atlantis pisze:
Quoted text here. Click to load it

To może z innej beczki. Spróbuj podciągnąć linie transmisyjne lekko do  
plusa. Np rezystorami 10k.

--  
pozdrawiam
MD

Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-13 23:53, Mario pisze:

Quoted text here. Click to load it

A co to może zmienić? To znaczy jakie jest uzasadnienie takiego posunięcia?

Generalnie kończą mi się pomysły. Dzisiaj poprawiłem jeszcze na wszelki  
wypadek filtrowanie zasilania przy stabilizatorze. Teraz mam na wejściu  
kondensatory 470uF+330nF oraz 220uF+100nF. Poprawa niewielka,  
praktycznie żadna.
Dodanie kondensatorka 100nF przy pinach zasilania modułu w jakimś  
stopniu pomogło - znikła sinusoida widoczna na oscyloskopie, poza tym  
subiektywnie wydaje mi się, że moduł inicjuje się nieco częściej. Jednak  
wciąż muszę kilka razy włączać go ponownie, żeby zaskoczył.
Zastosowanie kwarcu też nie do końca pomogło.

Problem z "krzaczkiem" generalnie ciągle występuje.
Wychodzi na to, że na pierwsze pytanie AT+CPIN? przychodzi najpierw  
jedna linia z "krzaczkami" (HyperTerminal widzi tam kwadrat i literę K,  
Programmer's Notepad wyświetla "t" z ogonkiem u dołu, skierowanym w  
lewo). Dopiero w następnej linii przychodzi właściwa odpowiedź (+CPIN:  
SIM PIN) ale program zdążył już przeanalizować poprzednią linię.

Niekiedy ten "krzaczek" nie przychodzi - wtedy udaje się bez problemu  
zainicjować moduł.

Jest też problem z komunikacją w drugą stronę, także w jednym,  
konkretnym przypadku. Mianowicie często (nawet bardzo często) Atmega nie  
wysyła modułowi rozkazu wybrania wykręconego numeru. Nie chodzi nawet o  
to, że występuje jakiś błąd - nawet terminal nie pokazuje niczego  
(chociaż inne komendy wychodzą). Jest to jakby nie patrzeć dziwne...

Gdyby nie fakt, że osobno działa, pewnie szukałbym źródła problemu w  
kodzie...


Re: Brak komunikacji między Atmegą a modułem GSM po rs232
Nie widziałem wątku od początku i może top pytanie już padło: z czego  
zasilasz ten moduł?

--  
Marek

Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-14 23:29, Marek pisze:

Quoted text here. Click to load it

Głównym źródłem zasilania jest zasilacz CB, dający na wyjściu 13,8V.
Oczywiście za nim dałem 78T05. Na wejściu kondensator 470uF i 330nF, na  
wyjściu 220uF i 100nF. Przy pinach zasilania modułu (zgodnie z manualem)  
1000uF i 100nF.

Atmega zasilana jest z tego samego stabilizatora (próbowałem już  
rozdzielenia zasilania, ale nic to nie zmieniło). Oczywiście przy  
kluczowych pinach ma kondensatorki filtrujące.

Co do samego zasilacza, to może ciągle dawać 3A, w porywach do 5A, tak  
więc ma odpowiednią wydajność...

Tak mi jeszcze przyszło do głowy... Może to nie jest wcale błąd  
transmisji? Może to coś związanego z konfiguracją modułu? Tylko w takim  
razie dlaczego problemy nie występowałyby przy pracy z samym komputerem?


Re: Brak komunikacji między Atmegą a modułem GSM po rs232
wrote:
Quoted text here. Click to load it
330nF, na

Rozumiem ze to moduł 5V? Możesz mi podać jego model?
W dalszej części przez ze nie ma problemu przy komunikacji z  
komputerem a później masz wątpliwisci co do działania hyperterminala.
W jaki sposób atmega (opisz procedurę odbioru znaku) komunikuje sie z  
modulem? Czy nie występuje sytuacja w ktorej atmega wysyla do modulu  
komendy at, gdy moduł nie jest gotowy na ich otrzymywanie (nie  
czekasz na wszystkie znaki z poprzedniego komunikatu z modulu lub  
znaku gotowosci). Najczestsza przyczyną problemow to za szybkie  
wysyłanie komend nie czekając na poprawne zakończenie poprzednich  
(transmisja kolejnego polecenia w trakcie odbierania wyników z  
poprzedniego). Np. na sam początek wysylasz at&f i atmega czeka tylko  
na OK i wysyła kolejne polecenie, a trzeba czekać na OK\r\n  dopiero  
po ostatnim \n z odpowiedzi może transmitowac kolejne polecenie.  
Kiedyś miałem podobny problem ze moduł dziwnie się zachowywał z mcu a  
w terminalu było prawidłowo. Był błąd w kodzie programu, mcu wysyłał  
kolejne polecenie w trakcie transmisji ostatniego \n z odpowiedzi  
poprzedniego polecenia i moduł albo się "przytykal" albo wysylal  
krzaczek.
 Na pc w terminalu problemów nie będzie bo wklepujac polecenia  
przerwy między poleceniami sa naturalne i wtedy wszystko działa.

--  
Marek

Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-15 09:12, Marek pisze:

Quoted text here. Click to load it

Wydawało mi się, że już wcześniej wspominałem. Moduł to Motorola D15.
Może pracować z napięciem zasilania od 3V do 6V.
Niezależnie od tego stan wysoki na liniach rs232 wynosi 5V. W tej chwili  
się tym szczególnie nie martwię, bo Atmega zasilana jest ze  
stabilizatora 5V, ale faktycznie ta kwestia chodzi mi po głowie, bo  
docelowo układ ma być zasilany z akumulatorka 3,6V.

Będę wtedy chyba potrzebował jakiegoś level shiftera?

Manual podaje następującą informację.

The signal thresholds are:
Vih 2.0V min.
Vil 0.8V max.
Voh 4.4V min. @ 50uA or 3.8V min. @ 8mA.
Vol 0.1 max. @ 50uA or 0.44V @ 8mA.


Quoted text here. Click to load it

Po prostu starałem się doszukiwać przyczyn tam, gdzie tylko się dało.  
Program pisałem w oparciu o wskazania HT, więc zacząłem nawet  
podejrzewać, że to on coś ukrywał i mogłem tego nie uwzględnić w kodzie.  
Wychodzi jednak na to, że przyczyna była zgoła inna...


Quoted text here. Click to load it

No i to chyba będzie to... Dopiero wróciłem z pracy i nie miałem czasu  
na eksperymenty, ale to najbardziej prawdopodobne wytłumaczenie. Po  
prostu nie wiedziałem o tej własności modułu - sądziłem, że komunikaty  
się kolejkują i wymiana informacji w obydwie strony odbywa się  
niezależenie. Faktycznie dotychczasowy kod ma opisaną przez Ciebie cechę.

Krótko rzecz ujmując używam dwóch tablic: rx_buffer[] i last_line[]. Do  
pierwszej napływają wszystkie znaki z modułu GSM, za wyjątkiem \n, które  
są pomijane. Wystąpienie \r powoduje przepisanie wszystkich  
poprzedzających go znaków z bufora do last_line[]. Pierwszy element  
tablicy last_line[] pełni też funkcję flagi informującej o przyjęciu  
odpowiedzi (kopiowanie odbywa się w przerwaniu, więc z punktu widzenia  
reszty programu całość przybywa za jednym razem).

Jednak zgodnie z tym co piszesz po wystąpieniu \r moduł odbierał jeszcze  
\n (tyle tylko, że go nigdzie nie zapisywał). Co więcej - w niektórych  
przypadkach potem leciała jeszcze pusta linie (\r\n). A tymczasem flaga  
była już postawiona i zaczynało się nadawanie kolejnej komendy...

Teraz zrobię to inaczej. Wystąpienie \n będzie inicjowało kopiowanie  
danych z bufora do last_line[], aż do wystąpienia znaku \r. Wyjątkiem  
będzie sytuacja, kiedy \r znajdzie się w pierwszym polu bufora - wtedy  
zostanie on po prostu wyczyszczony (ignorowanie pustych linii).
Dodatkowo, przed nadaniem każdej komendy zastosuję opóźnienie.

BTW jeszcze pytanie natury formalnej. Jak inteligentny jest kompilator w  
zakresie makrodefinicji zastępujących wartości liczbowe? Jeśli np. dam:

#define WARTOSC 31

a potem w programie dam:

if (zmienna < (WARTOSC-1))

To w którym momencie zostanie obliczona wartość? Podczas kompilacji, czy  
też za każdym razem uC będzie sobie musiał odejmować jedynkę? ;)

Re: Brak komunikacji między Atmegą a modułem GSM po rs232

Quoted text here. Click to load it

Widziałem kiedyś fajny level shifter na takie okazje.

http://husstechlabs.com/wp-content/uploads/2010/09/Level-shifter.jpg

Stosowałem z powodzeniem na BSS138.

Quoted text here. Click to load it

Daj 20ms (na ślepe oko) przed każdym znakiem.

Quoted text here. Click to load it

Kompilator zobaczy w tym miejscu "zmienna < (31 - 1)" (bo preprocesor podstawi  
31 za WARTOSC) i od razu obliczy do 30.

Quoted text here. Click to load it

Optymalizatorem się nie martw - dzisiejsze optymalizatory są wystarczająco  
inteligentne :) Mało jest przypadków, gdy trzeba poprawiać optymalizator.

Poza tym najpierw zrób, żeby działało, a potem baw się w optymalizacje.

--  
Gof
http://www.chmurka.net/

Re: Brak komunikacji między Atmegą a mo dułem GSM po rs232
W dniu 2012-12-15 19:14, Adam Wysocki pisze:

Quoted text here. Click to load it

Hmm... Chyba nie do końca na takie okazje... Z tego co widzę tutaj  
potrzebuję dwóch napięć zasilania - 3.3V oraz 5V.
Moduł D15 może pracować na dowolnym napięciu zasilania pomiędzy 3V a 6V.  
Logiczny stan wysoki jest jednak niezależny od VCC i wynosi 5V.
W tej chwili nie ma problemu, bo zarówno moduł jak i uC zasilam ze  
stabilizatora 78T05.

Martwi mnie jednak zapis w manualu Atmegi8 (a także ATTiny 4313), który  
dość jasno mówi, że najwyższe dopuszczalne napięcie na każdym pinie (za  
wyjątkiem resetu) wynosi VCC+0,5V.

Jeśli zastosuję zasilanie z akumulatorka 3,6V z punktu widzenia D15 nic  
się nie zmieni. VCC będzie mieściło się w widełkach, na liniach danych  
stan wysoki wciąż będzie wynosił 5V. Jednak z punktu widzenia uC będzie  
to prawie o jeden wolt za dużo.

Jednocześnie w takim układzie nie będę miał 5V do zasilenia tego  
shiftera. Gdybym miał, po prostu zasiliłbym z niego całość układu. :)


Re: Brak komunikacji między Atmegą a mo dułem GSM po rs232
Tak więc reasumując widzę tutaj tylko dwa możliwe rozwiązania:
1) Zasilanie układu z akumulatorka, który (wraz z ewentualnym  
stabilizatorem) dawałby około 5V. Wolałbym uniknąć takiego rozwiązania -  
akumulatorem 3,6V z odpowiednim sterownikiem pozwoli mi na korzystanie z  
typowej ładowarki od komórki.
2) Zastosowanie shiftera, który nie wymaga innego zasilania, jak tylko  
to pochodzące z baterii. W końcu max232 też nie potrzebuje napięć -15V i  
+15V do prawidłowej pracy.


Re: Brak komunikacji między Atmegą a modułem GSM po rs232
wrote:
Quoted text here. Click to load it
chwili  

Pisząc rs232 nasz na myśli usart mcu? Używasz jakieś przejściówki  
usart<->rs232 czy usart<->usb w przypadku łączenia się z pc?


Quoted text here. Click to load it

jeśli atmega nie może na 3.3v, to owszem albo level shifter ale można  
też obniżyć dzielnikami a podciagnac dioda + rez. osobiście używałem  
ten drugi sposób z powodzeniem.


Quoted text here. Click to load it
last_line[]. Do

ja jestem zwolennikiem buforu odbiorczego typu ring, które wypełnia  
przerwanie po odbiorze znaku + funkcje odczytu zawartosci bufora.  
Algorytm to m.in. dwie funkcje (w psedokodzie):
wyslij("at&f\r\n");
czekajna("OK\r\n", 1000);
Pierwsza wysyła string polecenia, druga odczytuje bufor (nie będę  
wnikał w obsługę bufora,  sloty itp. ) czekając aż się pojawi  
oczekiwany string  w określonym czasie (timeout w ms), jeśli się nie  
pojawi to funkcją zwraca błąd, który możemy obsłużyć. Bufor ring  
bardzo ładnie jest opisany wraz z przykładami w nocie an2120 dla  
m68hc08, polecam. Oczywiście ważne jest aby do funkcji oczekującej  
podawać "cały koniec" oczekiwanego stringu  (wraz z "\r\n") aby nie  
doprowadzić do zbyt wczesnego nadania kolejnego polecenia.
  
Quoted text here. Click to load it
kompilator w  
Quoted text here. Click to load it
dam:
Quoted text here. Click to load it
kompilacji, czy  
Quoted text here. Click to load it

Nie powinien przy włączonej optymalizacji (to się chyba nazywa  
constant folding), po prostu sprawdzi czy,zmienna<30. Ale to zalezy  
od kompilatora i włączonego poziomu optymalizacji.

--  
Marek

Re: Brak komunikacji między Atmegą a modułe m GSM po rs232
W dniu 2012-12-15 20:04, Marek pisze:

Quoted text here. Click to load it

Tak, miałem na myśli właśnie usart Atmegi.
Łącząc się z pecetem używam modułu na max3232.
Przelotkę na USB będę musiał kupić, ale do takich "warsztatowych"  
zastosowań używam leciwego ThinkPada T23, który posiada port COM.


Quoted text here. Click to load it

Hmm... Zainteresuję się tematem. Na razie zrobiłem to "po swojemu". Jest  
to może rozwiązanie proste, nawet i nieco toporne, ale w pewnym sensie  
to jego zaleta.

W każdym razie najważniejsze - miałeś rację co do przyczyny. Zmieniłem  
procedurę odbierającą znaki. W sposób opisany w poprzedniej wiadomości i  
teraz transmisja przebiega prawidłowo. W komunikatach wysyłanych przez  
moduł nie ma żadnych "krzaczków". Wracają czyste komunikaty.

Jednak teraz w oczy rzuciła mi się jeszcze jedna kwestia, której nie  
dostrzegłem wcześniej. Mianowicie komunikaty są odbierane liniami. Puste  
są ignorowane, ale przyjście każdej następnej pełnej zastępuje  
poprzednią zawartość last_line[].
Sęk w tym, że np. na zapytanie "AT+CPIN?" moduł odpowiada w następujący  
sposób:

+CPIN: SIM PIN\r\n
\r\n\
OK\r\n

Efekt jest oczywisty - oczekiwana, pierwsza linia zostaje niemal  
momentalnie zastąpiona przez trzecią (druga zostaje zignorowana).
Można by to wyłączyć (np. jakąś komendą AT) czy jedynie w grę wchodzi  
zmiana algorytmu odbierania komunikatów?


Site Timeline