NMEA - C - Garmin - atmega 8

[GPSler (Gast)]

Hallo Forum!

Ich probiere gerade meinen Garmin mit dem Originalen Datenkabel von 
Garmin
über UART auszulesen.
seit 3 Tagen sehe ich alles nur keine NMEA datensätze.
ich brauche nur ein hinweis, damit ich mir den rest selbst erarbeiten 
kann.

Gegeben:
Atmega8
LCD
Garmin Oregon 300
Garmin Datenkabel mit freien Enden


Serielles Datenkabel an RX am Atmega8 angeschlossen


Liegt das Problem am UBRR ?
Es rauschen nur Sonderzeichen über das Display!

#include <avr/io.h>
#include <avr/interrupt.h>
#include "lcd-routines.h"
#include <util/delay.h>
#include <stdlib.h>
#include <inttypes.h>


#define F_CPU 15206400
#define BAUD 9600UL      // Baudrate
 




/***************************************************************************************************************************************************************/

void USART_vInit(unsigned int ubrr) 

{ 


// Set frame format to 8 data bits, no parity, 1 stop bit 


UCSRC = (1<<URSEL)|(0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0); 
UBRRH = (char)(ubrr>>8); 
UBRRL = (char)ubrr; 

UCSRB =(1<<RXEN); 

} 

int USART_vReceiveByte() 

{ 
while ( !(UCSRA & (1<<RXC)) ); 

return UDR; 

} 



/***************************************************************************************************************************************************************/

int main() 
{ 
    lcd_init();
    USART_vInit(98);
    char start[7];

  
 




   while(1) 
   { 
    
      start[0]=USART_vReceiveByte(); 
                    
       
        //lcd_setcursor( 0, 2 );
        lcd_data( start[0] );


      if(start[0]=='$') 
      { 
         
      
     
      lcd_setcursor( 0, 2 );
    lcd_clear();
    lcd_string("juhuuuu");
    return 0;
    
    
  

   }
 
  
    }
    return 0;
  }

Ich wäre über einen Tipp sehr froh!
Danke im Vorraus !


GPSler

[L. P. (lpg)]

Hi, klemm das Teil mal am PC an und schau ob das überhaupt rauskommt. 
Oder umgekehrt, teste dein Programm am PC.

Lg

[Dr. Faust (Gast)]

>Gegeben:
>Atmega8
>LCD
>Garmin Oregon 300
>Garmin Datenkabel mit freien Enden
>Serielles Datenkabel an RX am Atmega8 angeschlossen


Fangen wir bei Adam und Eva an.
Die serielle Schnittstelle am Garmingerät ist für die Zusammenarbeit mit 
einem PC-RS232-Port ausgelegt.

http://de.wikipedia.org/wiki/RS-232

Die Gretchenfrage:
wird ein Pegelwandler&Inverter ein MAX232 macht das z. B.)verwendet?

[WAASy (Gast)]

GPSler schrieb:
> #include <util/delay.h>
> ...
> #define F_CPU 15206400

Warum gaukelst du der Delay-Routine eine andere Frequenz als dem Rest 
des Programms vor?

[Gaukler (Gast)]

Autor: WAASy (Gast) schrieb:
>Warum gaukelst du der Delay-Routine eine andere Frequenz als dem Rest
>des Programms vor?


Hallo Thread-Starter,

du mußt den RICHTIGEN CPU-Takt VOR dem inkludieren von delay.h angeben. 
Ansonsten nimmt er einen default Wert - und ob der auf deinem System 
passt ist reine Glückssache.

Das würde auch erklären, daß das GPS fleißig GPGGA (oder was auch immer 
für Datensätze) rausgibt, du aber nichts lesen kannst.

Stimmen denn die 9600Baud? Der NMEA-Standard sieht 4800Baud vor.

[Michael (Gast)]

GPSler schrieb:
> #define BAUD 9600UL      // Baudrate

Nur weil du dem Präprozessor sagst, dass er "BAUD" durch "9600UL" 
ersetzen soll, weiß der USART noch lange nicht, mit welcher Taktrate er 
arbeiten soll. Und was macht deine magic number (98)? Paßt die zu deineM 
verwendeten (Stichtwort Fuse) Takt?

[GPSler (Gast)]

Danke für die schnellen Antworten.
Funktioniert leider noch nicht.

>Hi, klemm das Teil mal am PC an und schau ob das überhaupt rauskommt.

Ja- Über GPS-Gate getestet - voller NMEA Datensatz

>Die Gretchenfrage:
>wird ein Pegelwandler&Inverter ein MAX232 macht das z. B.)verwendet?

Nein - muss man das auf jeden Fall machen ?

>Die serielle Schnittstelle am Garmingerät ist für die Zusammenarbeit mit
>einem PC-RS232-Port ausgelegt.

Ausgabe von
Garmin Seriell
Garmin Spanner
NMEA
Textout
RTSC o.s.Ä.


>du mußt den RICHTIGEN CPU-Takt VOR dem inkludieren von delay.h angeben.
>Ansonsten nimmt er einen default Wert - und ob der auf deinem System
>passt ist reine Glückssache.

Danke, das ist neu für mich. Ich war der Meinung, dass es keine Rolle 
spielt.


>>Stimmen denn die 9600Baud? Der NMEA-Standard sieht 4800Baud vor.

habe ich beide getestet,
Das Garmin Oregon kann seit einem der letzen Updates 4800 und 9600
habe es wieder auf 4800 umgestellt.


>Nur weil du dem Präprozessor sagst, dass er "BAUD" durch "9600UL"
>ersetzen soll, weiß der USART noch lange nicht, mit welcher Taktrate er
>arbeiten soll. Und was macht deine magic number (98)? Paßt die zu deineM
>verwendeten (Stichtwort Fuse) Takt?

Ich war der Meinung, dass

void USART_vInit(unsigned int ubrr) 

{ 


// Set frame format to 8 data bits, no parity, 1 stop bit 


UCSRC = (1<<URSEL)|(0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0); 
UBRRH = (char)(ubrr>>8); 
UBRRL = (char)ubrr; 

UCSRB =(1<<RXEN); 

}

die UART Takt Rate festlegt mit meiner (ubrr) Magic Number, welche ich 
aus folgender Tabelle entnommen habe.
http://www.wormfood.net/avrbaudcalc.php?postbitrate=9600&clock_speed_table=on&postclock=16&bit_rate_table=on

oder sind die Angaben auf der Seite falsch ?


>Paßt die zu deineM verwendeten (Stichtwort Fuse) Takt?
Wie viele Takteinstellungen muss denn überall beachten ?

[WAASy (Gast)]

GPSler schrieb:
> die UART Takt Rate festlegt mit meiner (ubrr) Magic Number, welche ich
> aus folgender Tabelle entnommen habe.
> 
http://www.wormfood.net/avrbaudcalc.php?postbitrate=9600&clock_speed_table=on&postclock=16&bit_rate_table=on
>
> oder sind die Angaben auf der Seite falsch ?

Warum ersetzt du dieses "mehrbändige Werk" nicht durch eine einfache 
Formel zum Berechnen der Konstanten durch den Präprozessor, so wie das 
im Artikel AVR-Tutorial: UART: UART konfigurieren beschrieben ist?

[Robert S. (p1337)]

WAASy schrieb:
> GPSler schrieb:
>> die UART Takt Rate festlegt mit meiner (ubrr) Magic Number, welche ich
>> aus folgender Tabelle entnommen habe.
>>
> 
http://www.wormfood.net/avrbaudcalc.php?postbitrate=9600&clock_speed_table=on&postclock=16&bit_rate_table=on
>>
>> oder sind die Angaben auf der Seite falsch ?
>
> Warum ersetzt du dieses "mehrbändige Werk" nicht durch eine einfache
> Formel zum Berechnen der Konstanten durch den Präprozessor, so wie das
> im Artikel AVR-Tutorial: UART: UART konfigurieren beschrieben ist?

Danke für den Tipp, ich hatte es schon so , war mir aber nicht sicher, 
ob ich das richtig umgesetzt hatte.
darum wollte ich es aus einer Tabelle entnehmen.

ich baue es sicherheitshalber doch wieder rein.

Danke!

[Robert S. (p1337)]

Ich aktualisiere :


SO IN ETWA ?

/* 
  UART-Init: 
Berechnung des Wertes für das Baudratenregister 
aus Taktrate und gewünschter Baudrate
*/
 
#ifndef F_CPU
/* In neueren Version der WinAVR/Mfile Makefile-Vorlage kann
   F_CPU im Makefile definiert werden, eine nochmalige Definition
   hier wuerde zu einer Compilerwarnung fuehren. Daher "Schutz" durch
   #ifndef/#endif 
 
   Dieser "Schutz" kann zu Debugsessions führen, wenn AVRStudio 
   verwendet wird und dort eine andere, nicht zur Hardware passende 
   Taktrate eingestellt ist: Dann wird die folgende Definition 
   nicht verwendet, sondern stattdessen der Defaultwert (8 MHz?) 
   von AVRStudio - daher Ausgabe einer Warnung falls F_CPU
   noch nicht definiert: */
#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000UL  // Systemtakt in Hz - Definition als unsigned long beachten 
                         // Ohne ergeben sich unten Fehler in der Berechnung
#endif
 
#define BAUD 4800UL      // Baudrate
 
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD) // Fehler in Promille, 1000 = kein Fehler.
 
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif


#include <avr/io.h>
#include <avr/interrupt.h>
#include "lcd-routines.h"
#include <util/delay.h>
#include <stdlib.h>
#include <inttypes.h>



 




/***************************************************************************************************************************************************************/

void USART_vInit(unsigned int ubrr) 

{ 


// Set frame format to 8 data bits, no parity, 1 stop bit 


UCSRC = (1<<URSEL)|(0<<USBS)|(1<<UCSZ1)|(1<<UCSZ0); 
UBRRH = (char)(UBRR_VAL>>8); 
UBRRL = (char)UBRR_VAL; 

UCSRB =(1<<RXEN); 

} 

int USART_vReceiveByte() 

{ 
while ( !(UCSRA & (1<<RXC)) ); 

return UDR; 

} 



/***************************************************************************************************************************************************************/

int main() 
{ 
    lcd_init();


    USART_vInit();     


    char start[7];

  
 




   while(1) 
   { 
    
      start[0]=USART_vReceiveByte(); 
                    
       
     //   lcd_setcursor( 0, 1 );
        lcd_data( start[0] );


      if(start[0]=='$') 
      { 
         
      
     
      lcd_clear();
    
      lcd_setcursor( 4, 2 );
    
    lcd_string("juhuuuu");
  
    
    
  

   }
 
  
    }
    return 0;
  }

[WAASy (Gast)]

Robert Stefanowicz schrieb:
> #ifndef F_CPU
> ...
> #define F_CPU 4000000UL  // Systemtakt in Hz - Definition als unsigned

So ein fester Default-Wert für F_CPU ist ausgesprochen gefährlich weil 
man trotz i.A. falschem Wert keine anständige Compiler-Fehlermeldung 
bekommt und die Warnungen werden zu gerne mal abgedreht oder nicht 
beachtet.

GPSler schrieb:
> Nein - muss man das auf jeden Fall machen ?
RS232 und USART Signale unterscheiden sich ganz grundlegend durch die 
Pegeldefinition und durch die Polarität. RS232-Treiber invertieren und 
konvertieren damit die Signale des USART in positiver Logik in die 
negative Logik der RS232-Schnittstelle. Außerdem wird von +/-3..12V auf 
0/3.3..5V umgesetzt.