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

[ATmega88][C]Komunikacja z GPS - FGPMMOPA6B.

RealGecko 27 Sty 2012 19:01 2922 25
  • #1 10456503
    RealGecko
    Poziom 9  
    Witam.
    Mam niestety problem z odpowiednią komunikacją z moim modułem GPS. Element ten podłączam wg poniższego schematu:
    [ATmega88][C]Komunikacja z GPS - FGPMMOPA6B.
    Przykładowy schemat podłączenia z dokumentacji:
    [ATmega88][C]Komunikacja z GPS - FGPMMOPA6B.
    Wartości kondensatorów są zgodne z dokumentacją.

    Moduł podłączany jest do ATmegi88, która jest zasilana napięciem 5V.

    Od strony programowej:

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


    Odbiór oraz wyświetlanie danych:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Tak powinny wyglądać przykładowe dane:
    $GPGGA,151503.000,5106.5551,N,01703.6012,E,1,8,0.92,136.8,M,42.6,M,,*56

    Czyli zwykłe znaki ASCII.

    Takie dane odbieram:
    ¾üçÉÔùàåù

    ASCII:
    190,252,231,201,212,249,224,229,249


    Czym to może być spowodowane?
    Pozdrawiam.
  • #2 10456587
    Zocha24
    Poziom 21  
    A czy masz połaczony pin P1 (RXD) bo na schemacie brak tego połączenia
  • #3 10456600
    RealGecko
    Poziom 9  
    Pin RXD jest niepodłączony, gdyż jest on wykorzystywany jedynie do zmiany oprogramowania oraz ustawień - z czego nie korzystam.
    Cytat:
    RX (Pin10) 
    This is the UART receiver of the module. It is used to receive software commands and firmware 
    update. 


    //Po podłączeniu do ATmegi zasilania 3,3V problem dalej występuje.
    Tak więc problem komunikacyjny między GPS (3,3V), a ATmegą(5V) można raczej wykluczyć.
  • #4 10457845
    Fredy
    Poziom 27  
    Może trzeba zanegować te dane? Spróbuj dać negator na zwykłym tranzystorze npn.
  • #5 10458156
    RealGecko
    Poziom 9  
    Ciekawy pomysł, ale raczej to nie to. ;)
  • #6 10458274
    kriss68
    Poziom 20  
    Wpisujesz złą wartość do UBRR, poczytaj w DS jak to wyliczyć ;)
  • #7 10458287
    superduo
    Poziom 13  
    Z daleka to śmierdzi źle ustawionym uartem po stronie kontrolera (zbyt szybki).

    Moduł nadaje 9600b/s.

    Użyj funkcji inicjujących uart opisanych w datasheecie, na rejestrach nie warto kombinować bo łatwo o błędy.
  • #8 10459017
    RealGecko
    Poziom 9  
    @kriss68: Na to wygląda. Aktualnie nie mam dostępu do programatora. Na dniach poprawię ten błąd i dam znać o efektach.
    @superduo: Tak też zrobię. ;)
  • #9 10514593
    RealGecko
    Poziom 9  
    Inicjalizuję UART

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


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


    Niestety, atmega dalej odczytuje śmieci.

    Przykładowe odczytane dane (ascii):
    195, 105, 255, 132, 255, 160, 61, 20, 211, 193


    Zarówno atmega, jak i GPS zasilane są napięciem 3,3V.
  • #11 10515126
    RealGecko
    Poziom 9  
    Chochlik, który wkradł się po aktualizacji posta.
    //
    Poprawione.
  • #12 10515367
    polprzewodnikowy
    Poziom 26  
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Źle
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #13 10515421
    RealGecko
    Poziom 9  
    Dalej to samo. ATmega czasami odbiera kody ASCII > 127, gdzie moduł gps wysyła jedynie "standardowe" znaki ascii.
  • #14 10515654
    michalko12
    Specjalista - Mikrokontrolery
    Jesteś pewien, że popędzasz uC z 1MHz?
    Zamiast makra przeliczającego dzielnik wstaw stałą 5 lub 6
    Sprawdź oscyloskopem co wypluwa odbiornik, jak nie masz oscyloskopu to sprawdź to na karcie dźwiękowej PC
  • #15 10515716
    RealGecko
    Poziom 9  
    Tak - 1MHz. Atmega ma ustawiony (zaprogramowany) CKDIV8.
    Z dokumentacji:
    Cytat:
    The device is shipped with internal RC oscillator at 8.0MHz and with the fuse CKDIV8 programmed, resulting in 1.0MHz system clock. The startup time is set to maximum and timeout


    Wstawienie stałej (5 i 6) nie pomogło - dalej to samo.

    Co do karty dźwiękowej, to na początek muszę poszukać jakiś informacji. ;)
  • #17 10516805
    RealGecko
    Poziom 9  
    Tak, mam pewność, że mam 1Mhz. ;)
  • Pomocny post
    #18 10516958
    JarekC
    Poziom 32  
    Witam,

    Problemem może być zegar = 1MHz zgodnie z kartą katalogową przy 1MHZ, UBRR=5 U2X=0 (9600 bodów) mamy błąd na poziomie 7% to bardzo dużo.
    Szczególnie, że nakłada się na to jeszcze błąd wewnętrznego oscylatora RC.
    Zmień dzielnik UBRR0 na 12 i ustaw bit U2X0 w rejestrze USCR0A, dostaniesz również 9600 bodów ale z błędem 0,2%.

    Pozdrawiam
    JarekC
  • Pomocny post
    #19 10517075
    kamyczek
    Poziom 38  
    Masz kolego dwa podstawowe błędy używasz prędkości która przy takim ustawieniu ma
    -7% błąd więc masz prawo mieć krzaki ;
    Możesz ustawić bit U2X0 w rejestrze UCSR0A
    i zmienić definicje na :
    #define RS_UBRR (F_CPU/(8*BAUD))-1
    0,2% błędu daje szansę na normalną komunikację

    I jak widzę nie tylko ja mam takie zdanie .
  • #20 10517091
    RealGecko
    Poziom 9  
    Jest znacznie lepiej!
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    Pierwsza rzecz - kody odebranych znaków nie są większe od 127.
    Druga rzecz, odbiera częściowo poprawnie ramkę:
    36, 71, 80, 10, 10, 10 (...)

    Co daje nam:
    $GP<LF><LF><LF>

    Przypominam jak wygląda przykładowa prawidłowa ramka:
    $GPGSV,2,1,08,17,52,126,47,04,49,015,49,10,40,238,46,13,34,071,46*7A 

    Niestety, nie wiem skąd bierze się tak wiele <LF>.

    //

    Czasami odebrane dane mają format:
    znak, <LF>, znak, <lf> itd.
  • #21 10517150
    kamyczek
    Poziom 38  
    Możliwe że pracujesz na wewnętrznym generatorze rc ,który kalibrowany jest przez wpisanie odpowiedniej wartości do osccal w przypadku gdy ułlad zasilany jest napięciem innym niż 5V wartość która wpisuje przy starcie układ nie zapewnia prawidłowej prędkości generowanego sygnału zegarowego . Proszę sprawdź ustawienia bitów cksel i osccall .
  • #22 10517171
    RealGecko
    Poziom 9  
    [ATmega88][C]Komunikacja z GPS - FGPMMOPA6B.

    OSCCAL = 170 (0xAA)
  • #23 10517188
    kamyczek
    Poziom 38  
    Proponuje chwilową zmianę cksel na zewnętrznego kwarca 8 MHz i wyposażenie w takowy układu bez zmiany ckdiv8
    jak uzyska kolega stabilną transmisję przesiadkę na oscylator rc i dobranie właściwej wartości oscall i dopisanie kilku linijek kodu by przy starcie układu została wpisana poprawna wartość . Zbudowałem układ który używa wewnętrznego generatora rc i działa stabilnie .
  • #24 10517201
    RealGecko
    Poziom 9  
    Dobrze, jutro się w taki zaopatrzę. (Właściwie to dziś).
    Rozumiem, że fuse bity mają być ustawione tak:
    cksel 3..0 -> 1100
    Prawda?
  • Pomocny post
    #25 10517911
    krru
    Poziom 33  
    Po co ten delay?
    Jak wyświetlasz znaki?

    Wygląda że po prostu za wolno odbierasz bo robisz za dużo rzeczy z każdym znakiem.
    9600 to jest ok 1000 znaków na sekundę, oczywiście GPS zwykle daje po parę linijek 1 raz na sekundę,
    ale jeśli po odebraniu każdego znaku go wyświetlasz w hex (3 znaki) i dajesz delay to moze nie zadzialac.
    Będziesz gubił znaki (można sprawdzić flagę).
    Odbieraj do bufora linijkę (od $ do <LF>) i dopiero obrabiaj.
  • #26 10518940
    RealGecko
    Poziom 9  
    Problem rozwiązany.
    Pomogła odpowiednia inicjalizacja UARTu (posty wyżej) i wywalenie delaya.
    Dziękuję za pomoc.
REKLAMA