między Atmegą a modułem G

[...]

Podłaczyć się równolegle pod RS-a dwoma terminalami i podsłuchiwać.

Mirek.

W dniu 2012-12-10 20:44, Mirek pisze:

W tej chwili mam tylko jeden moduł na max3232, więc podsłuchiwałem na zmianę łącząc linię RX na zmianę z TX modemu i Atmegi.

W każdym razie pomogło. Okazało się, że przyczyna nie dosyć, że była programowa, to jeszcze prozaiczna. Zwyczajnie dałem za krótką przerwę pomiędzy włączeniem modułu a wysłaniem pierwszej komendy. Modem nie miał dostatecznie dużo czasu, żeby zainicjować obsługę rs232. Chyba będę musiał przeznaczyć jedną linię na obsługę sygnału zgłaszającego gotowość portu do przyjmowania danych.

No i chyba za bardzo się pospieszyłem ze świętowaniem. Co prawda po wprowadzeniu poprawek program przechodzi dalej z inicjacją modemu, ale komunikacja nie jest stabilna. Nie udało mi się dotrzeć do podania PIN-u...

"Podsłuchane" odpowiedzi napływające z modemu nie wyglądają zbyt ładnie. Pojawiają się wśród nich jakieś krzaczki znaki NULL...

Plik z przechwyconą sesją terminalową tutaj:

W czym może leżeć przyczyna? Gdy "rozmawiałem" z modułem z komputera, przez terminal nie było czegoś takiego. Dostawałem "czyste" komunikaty, bez żadnych krzaczków. Wina leży po stronie połączeń czy może raczej nieodpowiedniego zasilania?

No to już oscyloskop by się przydał, ale najpierw bym spróbował zasilać modem osobno żeby po masie od RS-a nie szło zasilanie.

Mirek.

W dniu 2012-12-10 23:08, Mirek pisze:

Oscyloskop mam. Co powinienem sprawdzić?

Hmm... Możesz napisać coś więcej? W jaki sposób powinienem poprowadzić masę i zasilanie? W tej chwili wygląda to następująco:

1) Na płytce z Atmegą znajduje się stabilizator 78T05, z kondensatorami 330nF i 100nF. Stabilizator zasila Atmegę część płytki zawierającą uC (przez usuwalną zworkę). Z wyjścia biorę stabilizatora biorę też zasilanie modemu. 2) Zasilanie modemu filtrowane jest przez kondensator elektrolityczny 1000uF w pobliżu modemu. 3) Masy obydwu płytek są połączone jednym przewodem (pomiędzy minusem kondensatora filtrującego zasilanie modemu a okolicą wyprowadzenia masy stabilizatora na płytce Atmegi). 4) Linie RX i TX obydwu urządzeń są połączone kawałkami przewodów o długości kilkunastu cm.

Może masa jest niewystarczająca? Powinienem dodać drugi kabel, prowadzący w pobliże wyprowadzeń TX i RX Atmegi?

To raczej nic nie da. Po prostu połącz masę grubszym, krótszym przewodem a najlepiej podłącz na próbę zasilanie modemu z odseparowanego źródła. Nie wiadomo czy masa jest tutaj w ogóle problemem - trzeba to sprawdzić.

Mirek.

Jakie parametry transmisji ustawiłeś i jaka częstotliwość w atmedze?

Atlantis snipped-for-privacy@wp.pl napisał(a):

Kształt sygnału szeregowego, szerokość bitów.

W dniu 2012-12-10 22:43, Atlantis pisze:

Może procek nie pracuje na kwarcu tylko na wewnętrznym generatorze RC. Możesz mieć kilka procent odchyłki w prędkości transmisji.

Użytkownik "Atlantis" snipped-for-privacy@wp.pl napisał w wiadomości news:ka5o4e$qus$ snipped-for-privacy@portraits.wsisiz.edu.pl...

Najlepiej jak nadajnik nadaje 2 bity stopu, a odbiornik akceptuje 1 bit stopu. P.G.

Posłuchaj oscyloskopem - sprawdź stromość obu zbocz na obu liniach, może potrzebny jest jakiś pullup na linii od modemu do atmegi? Sprawdź szerokosć impulsów.

W dniu 2012-12-11 00:12, Mirek pisze:

W porządku. W następnej chwili wolnego czasu podłączę zasilanie Atmegi do baterii 9V (przez stabilizator 78T05 rzecz jasna) a modem zasilę (jak do tej pory) z zasilacza CB, przez inny stabilizator. Może to coś da...

W dniu 2012-12-11 00:32, Michoo pisze:

9600 bps, 8 bitów danych, brak parzystości, jeden bit stopu. Taktowanie Atmegi jest ustawione na 8MHz, z wewnętrznego rezonatora RC.

Tak w razie, gdybym się pomylił i tego nie zauważył, to procedura inicjująca pracę modułu rs232 wygląda następująco:

void usart_init (void) { UBRRH = 0; UBRRL = 51; UCSRB = (1<<RXEN) | (1<<TXEN) | (1<<RXCIE); UCSRC = (1<<URSEL) | (1<<UCSZ0) | (1<<UCSZ1); }

W dniu 2012-12-11 15:57, Adam Wysocki pisze:

A właśnie. Jak wygląda kwestia ustawienia bitów odpowiadających liniom na których znajduje się TX i RX w rejestrach DDRC, PORTC i PINC? W tutorialach, które czytałem ta kwestia raczej nie była poruszana - pisano po prostu o rejestrach funkcyjnych i konfiguracyjnych modułu rs232.

Ok, wykonałem próbę. Jak już wspomniałem uC podłączyłem do bateryjki 9V poprzez stabilizator 5V. Moduł przez osobny stabilizator do zasilacza CB

13,8V (może dawać ponoć do 5A, a moduł w peeku pobiera 1,5A).

Płytki miały więc osobne zasilania, połączone były jedynie przewodami masy, TX, RX, TS (ustawienie na stan wysoki włącza moduł) i DSC_EN (stan wysoki oznajmia włączenie modułu).

Pojawił się złowrogi objaw. Mianowicie po włączeniu zasilania Atmegi dioda na zasilaczu CB przygasła, dało się też słyszeć zauważalne brzęczenie. Jakby nagle zwiększył się pobór prądu... Oczywiście natychmiast wszystko wyłączyłem i zrezygnowałem z dalszych eksperymentów.

Każda płytka z osobna dalej działa prawidłowo.

Czy to rozjaśnia w jakiś sposób sytuację? Gzie powinienem szukać błędu?

W dniu 2012-12-11 19:51, Atlantis pisze:

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.

Stabilizator się wzbudza albo obciąża go któraś z tych linii sterujących do płytki atmegi albo zasilacz CB zepsuty. Więcej pomysłów nie mam. Skoro moduł "szarpie" 1.5A to o jego zasilanie powinieneś najpierw zadbać i koło niego stabilizator i krótka masa, a atmega niech sobie wisi na kabelkach.

Mirek.

W dniu 2012-12-11 21:36, Mirek pisze:

Co może być powodem? Dziwne jest to, że każda płytka z osobna na tych samych stabilizatorach działa zupełnie prawidłowo. Problem pojawia się dopiero po połączeniu ich razem.

To była pierwsza rzecz jaka mi przyszła do głowy. Teraz jednak wychodzi na to, że problem nie był związany z "krzakami" odbieranymi przez Atmegę. Okazuje się, że po odłączeniu linii TS i DSC_EN od Atmegi zasilacz już nie wariuje. Jeszcze raz sprawdzę w dokumentacji czy czegoś nie przeoczyłem. Może faktycznie któraś z nich potrzebuje bufora?

Zasilanie modułu GSM włączam po prostu chwilę wcześniej (zwarłem odpowiednie piny, a więc starty następuje automatycznie) a po paru sekundach podaję zasilanie Atmedze.

Niestety - komunikacja wciąż nie odbywa się prawidło, pomimo rozdzielonego zasilania przychodzą nieprawidłowe znaki. Co ważne - zawsze zawartość terminala wygląda tak samo. Nie są to jakieś losowe znaczki...

Odpada. Zasilacz świetnie sobie radzi z konstrukcjami krótkofalarskimi QRP, które podczas nadawania pobierają więcej prądu niż ten moduł. ;)

Jak mówiłem - w tej chwili są dwa osobne stabilizatory. Jeden dla Atmegi, drugi dla modułu D15.

W dniu 2012-12-11 21:17, Mario pisze:

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