logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[Atmega8][C] Weryfikacja kodu komunikacji z modułem GPS

eiliat 05 Maj 2012 12:16 6097 34
  • #1 10862604
    eiliat
    Poziom 15  
    Witam,

    Od kilku godzin tworzę mini projekt, który za pomocą ATmegi8 ma wyświetlić na LCD HD44780 informacje z GPS-a. Na razie wszystkie próby wykonuje w domu dlatego nie mam pewności czy to jest przyczyną, że nie mogę złapać sygnału GPS czy w moim kodzie czy schemacie jest jakiś błąd.

    Procesor: ATmega8 2 MHz wew.
    GPS: GPS-FGPMMOPA6C

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    W załączniku konfiguracja ATmegi8 i schemat projektu.
    Jeśli wszystko będzie OK to spróbuje przenieść się na powietrze ale muszę mięć pewność 100% że do tej pory wszystko jest dobrze zrobione bo mając to zmontowane na płytce prototypowej wszystko wisi :)

    Czy wszystko jest zrobione i zaprogramowane prawidłowo?
  • Pomocny post
    #3 10863396
    przemekbary
    Poziom 16  
    Witam
    W niektórych modułach GPS, VBACKUP musi być też podłączone do zasilania, jeśli nie ma baterii podtrzymującej - sprawdź dokładnie dokumentację.

    Mirek ma rację odnośnie zasialania. Kiedyś miałem problem z odbiornikiem GPS. Strasznie długo łapał fiksa. Na płytce miałem również modem GSM który generował zakłócenia zarówno przewodzone jak i w postaci fali elektromagnetycznej. Sytuacja się znacznie poprawiła gdy:
    1) Zastosowałem oddzielne LDO
    2) Użyłem kondensatorów filtrujących zasilanie: 10uF, 100nF
    3) Użyłem kondensatorów które "zwierają" zakłócenia dla częstotliwości rzędu GHz: 10p, 22p, 33p, 47p, 56p - zobacz notę aplikacyjną modemu H24 w którym jest wbudowany odbiornik GPS
    4) Zastosowałem wydzielone miejsce na odbiornik GPS. Miejsce to otoczyłem gęsto przelotkami. Zobacz na noty aplikacyjne niektórych kodeków dźwięku lub na płytę rozwojową do modułów GSM motoroli.

    Pozdrawiam
  • #4 10863534
    eiliat
    Poziom 15  
    Witam,

    1. Bardzo przepraszam, że wprowadziłem w błąd ale dwa kondensatory przy filtracji zasilania ATmegi są dla mnie tak oczywiste, że o nich zapomniałem przenieść na schemat. Tak jak napisałem mam 2 x 100 nF.

    2. Według datasheet jest napisane, że jeśli nie mam zasilania awaryjnego to "zostawić otwarte".
    Cytat:
    This connects to the backup power of the GPS module. Power source (such as battery) connected
    to this pin will help the GPS chipset in keeping its internal RTC running when the main power
    source is turned off. The voltage should be kept between 2.0V~4.3V, Typical 3.0V.
    IF VBACKUP power was not reserved, the GPS module will perform a lengthy cold start every
    time it is powered‐on because previous satellite information is not retained and needs to be retransmitted.
    If not used, keep open.


    3. Co do zakłóceń, moduł GPS znajduje się w odległości 8 cm od atmegi i 10 cm od wyświetlacza. Stabilizatory napięć 3.3V i 5V mam po drugiej stronie długiej płytki prototypowej. Dodam, że stabilizator 3.3V zasila GPS i procesor. Napięcia są w miarę stabilne - 3.25V i 4.95V.

    4. Po za tym kod jest prawidłowy?
  • Pomocny post
    #5 10863581
    przemekbary
    Poziom 16  
    Zobacz jeszcze czy masz dobrze połączone RX, TX !!!! Są różne konwencje oznaczania tych końcówek. Wyjście jednego układu musi być podłączone z wejściem drugiego i odwrotnie.

    Jeśli chodzi o kod, to dawno nie pisałem w AVR, także tutaj nie pomogę

    Dodano po 9 [minuty]:

    Z tego co widzę w dokumentacji, w atmega TX jest wyjściem; w module GPS również, więc powinieneś skrzyżować końcówki, tak aby TX było podłączone z RX i odwrotnie. Sprawdź jeszcze sam dokładnie
  • #6 10865147
    eiliat
    Poziom 15  
    Mam od chwili inny problem. Gdy mam ustawione na 2 MHz (Int. RC Osc. 2Mhz Start-up time 6 CK + 0ms) oraz w ustawieniach projektu 2000000 przy próbie wrzucenia nowego kodu, po dłuższej chwili, już przy samym końcu pluje błędem.

    Nie wiem od czego to zależy - raz się zaprogramuje a drugim razem już jest problem...

    Dodano po 32 [minuty]:

    Problem pojawia się gdy zasilam Atmege8 napięciem 3.3V
    Po przełączeniu na 5V jest OK. O co w tym chodzi?
  • #7 10866405
    eiliat
    Poziom 15  
    Witam,

    Po woli widać postęp. GPS po przysunięciu do okna i lekkim uniesieniu łapie w miarę szybko fix-a. Zamiana linii TX/RX również dała jakiś efekt.
    Teraz atmega odbiera jakieś znaki ale co to jest to nie mam pojęcia :)

    [Atmega8][C] Weryfikacja kodu komunikacji z modułem GPS [Atmega8][C] Weryfikacja kodu komunikacji z modułem GPS

    P.S
    Problemy z częstotliwością możemy odłożyć na bok, na razie działam na domyślnych fuse więc i FCPU = 1 MHz.
  • Pomocny post
    #8 10866439
    tmf
    VIP Zasłużony dla elektroda
    Problem też w tym, że na wewnętrznym RC rs232 po prostu może nie działać i będziesz odbierał śmieci. Podłącz zewnętrzny kwarc i wtedy spróbuj.
  • #9 10866624
    eiliat
    Poziom 15  
    Atmega jest podłączona bezpośrednio do GPS-a.
    Na razie zwiększyłem zegar do 2 MHz-ów.

    Nie do końca jestem przekonany do tego kodu... Może to jego wina, że wyświetla takie głupoty?
  • #10 10866711
    mirekk36
    Poziom 42  
    eiliat napisał:
    Atmega jest podłączona bezpośrednio do GPS-a.
    Na razie zwiększyłem zegar do 2 MHz-ów.

    Nie do końca jestem przekonany do tego kodu... Może to jego wina, że wyświetla takie głupoty?


    Ja tam nie wiem dlaczego wewnętrzny osc. RC miałby uniemożliwiać poprawne działanie UARTA. Jeśli procesor ma pracować w temperaturach zbliżonych do temperatury popularnie określanej "pokojową" to AVR'ki świetnie dają sobie z tym radę a nawet w szerszych zakresach zmian temperatury. Rzadko się zdarza i to bardzo rzadko, żeby fabrycznie jakaś partia procków była niedokładnie skalibrowana - a nawet jak jest to spokojnie można zwiększyć precyzyjne ustawienie za pomocą rejestru OSCCAL i wcale nic a nic nie będzie się w tej temperaturze rozjeżdżało.

    Za to w twoim kodzie na pewno zmieniłbym jedną rzecz odnośnie ustawień UART.

    Przede wszystkim jeśli to nie ma być zasilanie bateryjne to od razu ustawiłbym sobie 8MHz a nie jakieś takie ślimacze tempa 1MHz albo 2MHz, ale to tak na marginesie

    Jeśli już koniecznie (choć nie wiem z jakich powodów i na siłę ) chcesz męczyć te 2MHz to twoja inicjalizacja wykorzystuje bit U2X

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    i zobacz co robisz:

    [Atmega8][C] Weryfikacja kodu komunikacji z modułem GPS

    czyli decydujesz się na gorszą jakość próbkowania sygnału RS232 (w uproszczeniu mówiąc) ..... dlaczego ???

    zastosuj U2X=0 czyli tą wartość jaką masz zaznaczoną na zielono - i rozumiem że chodzi ci o prędkość 4800

    przy takim ustawieniu RS232 na wewn. Oscylatorze będzie chodził jak burza i żadnego kwarca nie musi być (o ile będą takie warunki o jakich pisałem wyżej) ... ale jeśli układ/moduł będzie miał pracować np na zewnątrz czyli w skrajnych warunkach temperatur to wtedy lepiej dać kwarc.
  • #11 10866752
    eiliat
    Poziom 15  
    Zmieniłem fuse na 8 MHz. Teraz:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Jest już poprawną wartością. W efekcie na ekranie LCD widzę powielony, rozstrzelony napis Oczekiwanie na GPS.

    Na razie nie planuje, żeby układ pracował w ekstremalnych warunkach - na razie chcę zrobić, żeby działał :)
  • Pomocny post
    #12 10867052
    mirekk36
    Poziom 42  
    eiliat napisał:

    Na razie nie planuje, żeby układ pracował w ekstremalnych warunkach - na razie chcę zrobić, żeby działał :)


    No i tym bardziej działaj spokojnie na razie na wewn. oscylatorze, ale dla pewności ja bym na twoim miejscu zrobił pewien test:

    1. podłączył wyjście tego odbiornika wprost do terminala na PC i zobaczył co on wysyła

    2. podłączył swój układ do terminala i wysłałbym parę napisów czy znaków żeby zobaczyć czy poprawnie pojawiają się w terminalu

    po tej operacji będziesz wiedział:

    1. co wysyła normalnie odbiornik GPS
    2. czy poprawnie działa twój program w zakresie RS232

    jeśli na obydwa powyższe pytania będziesz miał odpowiedź że DZIAŁA OK

    to wtedy z kolei będziesz wiedział że na LCD ci się źle wyświetla bo masz babole we własnym programie a nie będziesz tracił czasu na szukanie przyczyn np w złym działaniu UART'a w procku bo np zły wewn. oscylator
  • Pomocny post
    #13 10867172
    tmf
    VIP Zasłużony dla elektroda
    mirekk36 napisał:
    eiliat napisał:
    Atmega jest podłączona bezpośrednio do GPS-a.
    Na razie zwiększyłem zegar do 2 MHz-ów.

    Nie do końca jestem przekonany do tego kodu... Może to jego wina, że wyświetla takie głupoty?


    Ja tam nie wiem dlaczego wewnętrzny osc. RC miałby uniemożliwiać poprawne działanie UARTA. Jeśli procesor ma pracować w temperaturach zbliżonych do temperatury popularnie określanej "pokojową" to AVR'ki świetnie dają sobie z tym radę a nawet w szerszych zakresach zmian temperatury. Rzadko się zdarza i to bardzo rzadko, żeby fabrycznie jakaś partia procków była niedokładnie skalibrowana - a nawet jak jest to spokojnie można zwiększyć precyzyjne ustawienie za pomocą rejestru OSCCAL i wcale nic a nic nie będzie się w tej temperaturze rozjeżdżało.


    Wystarczy rzucić okiem do noty procesora i wiadomo dlaczego na wewnętrznym może nie działać (rysunki 170 i dalsze). Dodatkowo Atmel nie gwarantuje fabrycznej kalibracji na poziomie wystarczającym dla poprawnej pracy UASART (to dopiero gwarantuje dla XMEGA), co zresztą pisze w nocie. Owszem, to czasami działa, a czasami nie, zresztą niedawno był tu post, gdzie ktoś kupił całą serię M8 i mu nagle magicznie USART przestał działać. Owszem, OSCCAL jest rozwiązaniem, ale to trzeba cały protokół kalibracji zaimplementować (zresztą Atmel ma stosowną notę na ten temat) i IMHO nie ma sensu tak kombinować jeśli nie ma takiej potrzeby. Ja bym na miejscu autora dał ten kwarc na chwilę i sprawdził. Zresztą można to podpiąć pod PC i wysyłać dane, sprawdzając co się odbierze.
  • Pomocny post
    #14 10867334
    mirekk36
    Poziom 42  
    Dokładnie - ja też kiedyś kupiłem partię m16 w których wewn. RC był na tyle rozkalibrowany, że nie działała z marszu transmisja UART - ale to raz na jakiś czas - no i oczywiście bez żadnych problemów lekka zmiana OSCCAL i po kłopocie. No a wspominałem właśnie o tym że wystarczy podłączyć do PC i sprawdzić - wtedy będzie ostatecznie i pewnie stwierdzone - z czym się zgadzam. A autor sobie potwierdzi co i jak bez kłopotu.
  • Pomocny post
    #16 10868139
    mirekk36
    Poziom 42  
    eiliat napisał:
    witam,

    Z racji, że nie posiadam portu RS232 to chcę kupić taki adapter:
    http://allegro.pl/adapter-usb-to-rs232-profesjonalny-vk652-i2266313361.html

    Czy jeśli jest to zewnętrzny układ muszę stosować dodatkowy konwerter RS232?


    No i pomyśl sobie, kupisz taką przejściówkę, która ma wyjście w standardzie RS232 czyli sygnały (-12V/+12V) .... i co ??? jak do tego podłączysz moduł GSM albo swój układ ? - będziesz musiał robić kolejną przejściówkę na MAX232 żeby dopasować poziomy sygnałów albo nawet MAX3232 - jeśli zasilasz moduł czy układ z 3,3V

    lepiej kupić przejściówkę na FT232R która ma możliwość komunikacji w standardzie TTL i to jeszcze ze zworką pozwalającą na zmianę standardu albo na TTL albo na 3,3V

    Są przecież takie moduły gotowe - i wtedy od razu podłączasz czy procka czy moduł do kompa - bez niczego....

    Taka przejściówka gdy się korzysta z procków, modemów czy modułów gsm to podstawa żeby mieć ;)
  • Pomocny post
    #18 10869803
    tmf
    VIP Zasłużony dla elektroda
    Zależy do czego. Ja bym ci polecił ten moduł DIL - pewnie ma wyprowadzone wszystkie piny i wygodnie jest się do nich podłączyć, chociażby na płytce stykowej.
    Natomiast jeśli potrzebujesz to wyłącznie do przetestowania połączenia to bym się zastanowił czy warto wydawać pieniądze. Jak pisałem, wsadź ten kwarc na chwilę i sprawdź. Jak masz zwykły miernik, to on ma też zapewne prostą funkcję pomiaru częstotliwości. Wygeneruj więc przebieg, np. 10kHz przy pomocy timera i zmierz miernikiem. Wiadomo, będzie niedokładnie, ale zorientujesz się co do odchyłki.
  • #19 10870210
    mirekk36
    Poziom 42  
    tmf napisał:
    Zależy do czego. Ja bym ci polecił ten moduł DIL - pewnie ma wyprowadzone wszystkie piny i wygodnie jest się do nich podłączyć, chociażby na płytce stykowej.


    Zdecydowanie dobry pomysł - też tak uważam - tylko zwróć jak mówiłem czy jest na nim możliwość przełączania standardu wyjść z TTL na 3,3V

    tmf napisał:
    Natomiast jeśli potrzebujesz to wyłącznie do przetestowania połączenia to bym się zastanowił czy warto wydawać pieniądze.


    Warto warto. Robić coś z mikrokontrolerami i nie mieć tego typu przejściówki, nie móc podłączyć się terminalem żeby cokolwiek sprawdzić na szybko, albo użyć jej do celów prostego i szybkiego debugowania to po prostu wręcz grzech :) .... to tak jakby robić coś z prockami i nie mieć programatora (prawie)
  • Pomocny post
    #20 10870295
    tmf
    VIP Zasłużony dla elektroda
    [quote="mirekk36"]
    tmf napisał:

    tmf napisał:
    Natomiast jeśli potrzebujesz to wyłącznie do przetestowania połączenia to bym się zastanowił czy warto wydawać pieniądze.


    Warto warto. Robić coś z mikrokontrolerami i nie mieć tego typu przejściówki, nie móc podłączyć się terminalem żeby cokolwiek sprawdzić na szybko, albo użyć jej do celów prostego i szybkiego debugowania to po prostu wręcz grzech :) .... to tak jakby robić coś z prockami i nie mieć programatora (prawie)


    To co piszesz jest oczywiste. Zwróć tylko uwagę, że napisałem, że jeśli ma ją kupić wyłącznie do tego jednego projektu i na nic więcej mu się nie przyda to warto się zastanowić czy kupno jest opłacalne. W ogólności oczywiście warto taką przejściówkę mieć (no może już nie tak bardzo jak kiedyś, gdyż nawet w świecie AVR wbudowany interfejs USB jest co raz powszechniejszy).
  • #21 10878814
    eiliat
    Poziom 15  
    Witam,

    Moduł mi się przyda bo to dopiero początek mojej przygody z AVR. Wcześniej dużo robiłem projektów ale nie wiązałem ich z modułami do przesyłania danych i komputerem.

    Zamierzam kupić ten i już chciałbym wiedzieć jak mam ustawić zworkę J1 tak aby sprawdzić mojego GPS-a?
    Link
  • #22 10878873
    tmf
    VIP Zasłużony dla elektroda
    Zauważ, że ten moduł ma wyjścia wyłącznie w standardzie RS232-TTL. Ta zworka wybiera czy wyjście jest w standardie 3,3V czy 5V - sprawdź swojego GPSa - czy ma wyjście RS232-TTL czy normalne. Jeśli ma normalne to potrzebujesz jeszcze układ MAX232.
  • #23 10878916
    eiliat
    Poziom 15  
    Ciężko to określić, nic nie widzę o tym w datasheet. Możesz zobaczyć?
    Link
  • #24 10879210
    tmf
    VIP Zasłużony dla elektroda
    Jest w standardzie TTL, max napięcie w stanie H t 2,8V. Jeśli łączysz ten moduł z mikrokontrolerem to pamiętaj aby mikrokontroler zasilać z napięcia mac 3,3V - inaczej może nieprawidłowo rozpoznawać stan na wyjściu Tx modułu. Stąd też może twoje problemy - dla zasialnia mikrokontrolera 5V, napięcie wyjścia Tx może być niewystarczające do rozpoznania stanu wysokiego. Pin Rx modułu możesz nie podłączać.
  • #25 10879518
    eiliat
    Poziom 15  
    Witam,

    Problem na pewno leży po stronie GPS-ATMega8. Teraz mam podłączony GPS przez powyżej podany konwerter do komputera i ładnie wyświetla mi informacje.

    Jutro od nowa podłącze moduł do AVR i zacznę walkę :)
    Postaram się z pomocą mkAVR Calculator ustawić na zewnętrzny kwarc, może to coś pomoże.

    Jakby ktoś miał sprawdzony kod i może się podzielić to proszę o zamieszczenie :)
  • #26 10879815
    Konto nie istnieje
    Konto nie istnieje  
  • #27 10880767
    eiliat
    Poziom 15  
    napisał:
    mirekk36 napisał:
    i rozumiem że chodzi ci o prędkość 4800


    Z tego co pamiętam to ten moduł ma w "default" prędkość 9600bps, więc nic dziwnego, że wyświetlane są krzaki, a wystarczyło spojrzeć do noty katalogowej modułu GPS, żeby też się tego dowiedzieć... (strona 15).


    Pan mirekk36 mnie źle zrozumiał, moduł cały czas był ustawiany na 9600.
  • #28 10881400
    mirekk36
    Poziom 42  
    eiliat napisał:

    Pan mirekk36 mnie źle zrozumiał, moduł cały czas był ustawiany na 9600.


    Zobacz tzn wróć do rysunku z tego posta:

    https://www.elektroda.pl/rtvforum/topic2288306.html#10866711

    w programie wpisywałeś do UBRR wartość 51 - i tylko dlatego chciałem się upewnić czy przypadkiem nie masz ustawionej transmisji własnie na 4800 bps i to z włączonym bitem U2X. W ogóle nie zaglądałem do noty PDF tego twojego modułu ani nie brałem tego pod uwagę. Chodziło mi tylko o zwrócenie uwagi na bit U2X i gorsze próbkowanie sygnału.
  • Pomocny post
    #29 10882572
    Konto nie istnieje
    Konto nie istnieje  
  • #30 10884178
    eiliat
    Poziom 15  
    Witam,

    Główną przyczyną jak mi się wydaje była funkcja wyświetlająca tekst na ekranie.
    Z takim kodem dane są odczytywane prawidłowo:

    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Mam teraz pytanie. Ze względu, że dostaje kilka ramek jak zapisać do zmiennej:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Ramkę odpowiedzialną tylko za pozycję czyli $GPGGA?
    Chcę zrobić odczyt od łańcucha $GPGGA aż do 14 znalezionego przecinka po $GPGGA?
REKLAMA