Data aus USART vom SAM7-EX256 lesen

Irgendwelche Idee??

Jetzt bekomme ich Daten aber sie sehen überhaupt nicht wie GPS-Daten aus 
(siehe Anhang). Weiss jemand vielleicht woran das liegt?

Die Baudrate stimmt bei mindestens einem USART nicht. Hast Du einen 
ordentlichen JTAG Debugger, bei dem man sich Variablen anzeigen lassen 
kann?

Jim M. schrieb:
> Hast Du einen
> ordentlichen JTAG Debugger, bei dem man sich Variablen anzeigen lassen
> kann?

Hi Jim,

und dke für deine Meldung. Ich verwende den ARM-USB-TINY-H von Olimex. 
Anbei ist ein Screenshot über den Start von Openocd über ARM-USB-TINY-H 
zu sehen.

Meintest du es?

Stephan schrieb:
> Warum nimmst du nicht die Beispiele von Atmel?

Hi Stephan,

und dke für deine Antwort. Meinst du vielleicht das Beispiel über 
Serial?Wenn ja, dann habe ich schon angeschaut  aber ich musste ein paar 
Anpassungen machen wie es im Anhang zu sehen ist. Zu Bsp die Baudrate; 
Mein GPS läuft mit einer Baudrate von 38400 bps. Deswegen habe ich im 
US_BRGR den Wert 78 = MCK/(16*38400). Übrigens, ich habe diese Formel 
aus dem Datasheet genommen, weil ich im Asynchronous Mode bin und OVER = 
0 (siehe den Wert, der im US_MR geschrieben wird).

Stephan schrieb:
> aber könntest du so nicht einfach ein 'Hello World' für deine UART
> Ausgabe schreiben?

Das habe ich schon gemacht und es hat auch vollkommen funktioniert. Aber 
trotzdem eine gute Idee, ich versuche mal mit dem gleichen Code.

>Wie ist denn deine PLL eingestellt?

PLL ist nicht eingestellt. Sollte ich?

Stephan schrieb:
> mit welcher Frequenz läuft denn dein MC?

48 MHz

Dieses Programm habe ich gerade geschrieben und es basiert sich auf das 
"Hello worl" Programm mit ein paar Anpassungen. Aber, wenn ich das 
Programm debugge, kriege das beigefügte screenshot: Das sind aber keine 
GPS Daten. Entweder ist liegt es an meinem Code oder liest irgendwas auf 
RXD1 aus.

Ansonsten hätte ich noch eine Frage: Kann ich direkt im US_RHR Charakter 
schreiben, Wie ich sogar gemacht habe? Oder müssen nur die Adressen 
sowohl in RHR als auch im THR geschrieben werden?

Ich freue mich wieder auf eure Meldungen.

Yann

Anhang: Code1 und debug_result1

Yann B. schrieb:
> Dieses Programm habe ich gerade geschrieben und es basiert sich auf das
> "Hello worl" Programm mit ein paar Anpassungen.

Und das "Hello, World" war im putty zu lesen? Dein Fehler sieht nämlich 
nach flasch programmierter Baudrate aus.

Mit dem Debugger könnte man sich anschauen, ob die Daten beim GPS UART 
falsch rauskommen oder nur am PC die Daten falsch ankommen.

Achtung: Das RHR besser nicht direkt im Debugger lesen, sondern ein 
gelesenes Byte in einer Variable (besser: Array) speichen und die dann 
auslesen. Das Lesen vom UART im Debugger kann unerwartete Nebenwirkungen 
haben.

Jim M. schrieb:
> Und das "Hello, World" war im putty zu lesen?

Ja.

>Mit dem Debugger könnte man sich anschauen, ob die Daten beim GPS UART
>falsch rauskommen oder nur am PC die Daten falsch ankommen.

Was meinst du eigentlich damit? Wenn ich das GPS Modul direkt am PC 
anschließe erhalte durch PUTTY richtige Daten.

>Achtung: Das RHR besser nicht direkt im Debugger lesen, sondern ein
>gelesenes Byte in einer Variable (besser: Array) speichen und die dann
>auslesen. Das Lesen vom UART im Debugger kann unerwartete >Nebenwirkungen
>haben.

Danke für den Tipp, ich probiere gleich ohne Debug aus. Und was ist mit 
THR? Darf ich auch direkt den Inhalt von RHR drin schreiben oder lässt 
dies nur Adresse zu?

Stephan schrieb:
> char* nmea_data = 0x0;
> was ist das?

Sorry es war ein Fehler. Ich wollte den Zeiger initialisieren. Wenn ich 
den Code teste, erhalte ich den beigefügten Anhang (gps_test_2). Ich 
konnte das "printf" nicht benutzen, weil das Programm die <stdio.h> Lib 
nicht finden konnte.

Kommischerweise, wenn ich die Baudrate ändere (baud = 9600 -> US_BRGR = 
313) bekomme ich trotzdem Daten, die leider auch keine GPS-Daten sind. 
Ist es überhaupt möglich?

So jetzt stützt der Rechner ab, wenn die Daten lange ausgelesen werden. 
Weiss jemand vielleicht woran das liegen könnte? Manchmal nach dem 
absturz wird mein Bildschirm blau ( mit Crash dump ... Memory...) und 
nach 100 Sekunden ausgeschaltet. (Siehe Anhang crash dump)

Dke Stephan,

ich probiere es gleich aus.

Es hat funktioniert.

Hey Yann,
noch dran oder hast schon aufgegeben?

Stephan

Hi,
da biste ja wieder. :-)

Yann schrieb:
> dritter Pin-Anschluss ist Schield.
> Wozu dient er eigentlich?

Da sind die Abschirmbleche drauf, je nachdem wie 'dreckig' die Umgebung 
ist, (Störfrequenzen) desto mehr muß man für die Entstörung tun.

Ich bin mir zwar nicht 100% sicher, aber im Labor wird ich ihn mit GND 
verbinden, aber in der freien Wildbahn....

Auf den 3. Bild steht RS232 xxx an den PINs, jetzt sag nochmal wie du 
den PC und den GPS Baustein angeschlossen hast?

Yann B. schrieb: vom 1. Beitrag:
> Das GPS ist an
> USART1 (RxD0) angeschlossen und der USB-RS232 Adapter an RS232 (USART0)
> des Boards und am PC angeschloßen.
Ich hab mir einmal das olimex board angesehen (Rev C) und glaube den 
Grund für dein nicht funktionieren gefunden zu haben.
DAS Board hat nur 1 ST3232 (RS232) Baustein und da liegt entweder die 
DEBUG oder die USART0(RxD0) Schnittstelle dran!
USART1(RxD1) liegt dort nur als TTL Signal am UEXT(10pol) vor!
KEIN RS232!
Der 2. DSUB ist ein CAN Interface!

Stephan

Yann schrieb:
> Wo hast du es angehängt? Ist es das SAM7-EX256 von Olimex?

angehängt nicht, aber der Link von dir war richtig.
mit Rev C war der Schaltplan gemeint:
SAM7-EX256 REV.C schematc -> 
https://www.olimex.com/Products/ARM/Atmel/SAM7-EX256/resources/SAM7-EX256_Rev_C-sch.pdf

Yann schrieb:
> aber warum steht
> auf der Seite 21 des Datenblatts folgendes: RS232 1 Receive und RS232 1
> Transmit? (siehen das angehängte Screenshot darüber).

das wäre nicht richtig!

Yann schrieb:
> Ansonsten hast du völlig Recht, auf EXT und UEXT sind LVTTL Pegel. Würde
> es also bedeuten, dass ich den Pegelwandler wie den Max232 bräuchte,
> falls ich die USART1 Verwenden soll?

keinen MAX232 (5V), einen LVTTL zu RS232, wie den ST3232 oder MAX3232!

Yann schrieb:
> Außerdem habe ich gerade noch gelesen, dass die beiden USART eigene
> Baudrate haben (Seite 27, Absatz 7.6 RS232).

Ich hatte dir doch die Funktion "AT91F_US_SetBaudrate" gegeben, dort 
wird doch auch die UART mit übergeben! DIE 3 Schnittstellen DBUG, UART0 
und UART1 sind komplett unabhängig, jede muss einzeln konfiguriert 
werden!

Yann schrieb:
> dass RS232 mit 9600 als Baudrate arbeitet. Heißt es eigentlich,
> dass der Wert der Baudrate nicht änderbar oder einstellbar ist?

NEIN! In dem Beispiel Code für das Board, sind die Funktionen 
"InitUSART0" und "InitUSART1" hart auf 9600bps programmiert. Das soll 
den Einstig in die SW Projekte erleichtern. DU kannst die Baudrate 
ändern wie du willst. ;-)

Dein Bild zum Sensor und PC ist richtig!
Jetzt nur einen 3V LVTTL zu RS232 Wandler aus der Bastelkiste und den 
UART1 anschließen und dein Programm sollte laufen.
(Wenn die Schnittstellen richtig eingestellt ist)

Stephan

Wieder da. Seitdem ich den Adapter bestellt habe ich es von Amazon noch 
nicht bekommen und ich habe mich dazwischen mit dem LCD-Display 
beschäftigt. Mein Ziel ist die GPS Daten jetzt auf dem Display 
anzuzeigen. Ich habe bis jetzt das LCD und das GPS Modul so 
programmiert, dass wenn ich auf dem Switch 1 drücke dann sollte 
mindesten die UTC-Zeit angezeigt werden. So sieht das Szenario aus:

1) Beim Start wird das welcome angezeigt

2) Nach 10 Sek wird dem User 2 Optionen als Menu vorgeschlagen:
 Drücken Sie:
   - SW1: um die Position anzuzeigen
   - SW2: Quit

Wenn der User auf SW1 drückt dann wird der Bildschirm gelöscht und die 
Position sollte wie folgendes angezeigt werden:
    Longitude: ....
    Latitude : ....
    UTC_Time : ....

Wenn ich das programme ausführe passieren die beiden Szenarien (1 und 2) 
mit Erfolg. Aber wenn ich jetzt auf SW1 drücke passiert nichts. Wenn ich 
aber die Funktion parseGGA() auskommentiere, dann ich kriege das Bild 1. 
Ich möchte mich zunächst auf dem Inhalt von UTC_Time nicht 
konzentrieren, weil ich den Pointer im struct nicht initialisiert habe.

mein Problem ist folgendes:

Woran könnte es liegen, dass wenn ich meine Funktion parseGGA() in main 
aufrufe, dann passiert nichts beim Drücken auf Switch 1. Gibt es 
vielleicht etwas Falsches in meiner parseGGA(), was das Programm an 
dieser Stellt blockiert? Weil ich das Programm schon mehrmals überprüft 
habe und bis jetzt noch nichts gefunden, was der Grund sein könnte.

Anbei die verschiedenen betroffenen Funktionnen.

Ich konnte selber ein paar Fehler herausfinden. Deswegen habe ich den 
Code angepasst.

Ach so, im ersten vorherigen Post habe ich vergessen, die Rolle der LED 
zu erwährnen. Also, sie sollte leuchten, wenn ein Charakter empfangen 
wird. Nachdem ich gerade den Code angepasst habe und ausgeführt bleibt 
die LED aus. Also gehe ich davon aus, dass entweder das GPS Modul keine 
Daten empfängt oder liegt an der Maskierung in der 
read_char_USART0_nonstop().

Außerdem, wenn ich die Funktion parseGGA in der endlosen while-Schleife 
aufrufe, dann wird nur den UTC_Time beim Drücken auf Switch 1 angezeigt. 
Also nehme ich an, dass das Problem am Source gps.c liegt aber ich weiß 
nicht wo genau.

Irgendweche Idee oder Anmerkung?

Vielen Dank im voraus

Weiß jemand vielleicht, woran das liegen könnte?

Irgendwelche Idee?

Ich habe heute den ttl zu rs232 Adapter bekommen und ich ich kann die 
Daten am USART1 auslesen (siehe screenshot).

Ich bedanke mich ganz herzlich bei dir Stephan für deine große 
Unterstützung.

Hi Stephan

> Ist das andere dann noch aktuell?

Meinst die Post über das LCD-Display?

Sorry, ich war krank.
Stephan schrieb:
> Yann kann es sein das du hier ein Copy & Paste Fehler hast?

Copy & Paste Fehler!!!

Stephan schrieb:
> Ein kleiner Tip, wenn deine Funktionen mit 'Pointern auf Buffern'
> arbeiten, gib immer die Größe des Buffers mit, So kann die Funktion
> erkennen, wann sie aufhören muss in den Speicher zu schreiben.(Buffer
> overflow)

dke für den Tip. Leider kann ich noch nicht die Zeit auf dem Display 
anzeigen lassen. Das Problem ist, dass das GPS Modul kontinuerlich die 
Daten sendet. Die Funktion get_gga_string() ist eigentlich die Funktion 
get_gps_string(), die hier anbei liegt. Diese musste ich noch anpassen, 
aber beim Testen kann ich nur das erste Zeichen des gespeicherten 
Strings nämlich das $ Zeichen anzeichen lassen. Andere Elemente des 
Buffers werden nicht angezeigt und ich habe mich schon lange gefragt, 
was das Problem sein könnte. Ich habe viel recherchiert, um zu sehen, wo 
der Fehler liegt aber ich bin komme immer noch nicht voran.

Ich bitte euch wirklich um Hilfe, sonst werde ich verrückt sein.

Sorry in main.c nämlich in LCDPutChar() statt gps_msg3[2] ist es 
gps_msg3[0] anzunehmen.

Ich habe den Fehler gefunden. Vielleicht habt ihr auch gesehen. Der 
Fehler lag in der zweiten do Schleife. Da war die if-Anweisung 
auskommentiert. Jetzt kann ich andere Elemente des Buffers auf dem 
Display anzeigen lassen.

Anbei ein Ergebnis.

Wie gesagt mein Ziel ist die UTC_Zeit aus dem GGA zu holen und 
anzuzeigen. Ich mache jetzt Schritt für Schritt, weil der ganze Code zum 
ersten Versuch nicht funktioniert hat.

Bingo! I got it.

ich kann die UTC_Zeit anzeigen lassen aber noch nicht, wie ich es will. 
Ich möchte meine erstellte Struktur verwenden aber es geht immer noch 
nicht. Hier zeige ich nur die nachkommenden Zeichen nach dem Komma, wenn 
es ein GGA String ist (siehe main.c).

Soo jetzt kann ich sowohl die Zeit als auch die Breite und die Länge auf 
dem Display anzeigen.