Hallo, im Anhang mal ein GPS-Parser, geschrieben in C, optimiert für XMEGA-µCs. Der Code ist so geschrieben dass es vergleichsweise einfach ist auch mehrere Empfänger gleichzeitig auszulesen. Im Codebeispiel habe ich 2 Empfänger implementiert. Der Parser ist gleichzeitig auch die Einleseroutine für die Seriellen Daten, dies geschießt über eine (oder mehrere) ISR, welche dank Nutzung von DMA auch sehr schlank (schnell) gehalten ist. Für die Nutzung von nicht X-Mega Bausteinen muss DMA entfernt werden (und ein Schleifen-array-copy implementiert werden ), sowie die ISR Umbenannt und die initialisierung geändert werden ! Da ich hier im Board nur ASM-Parser gefunden habe dachte ich jemand könnte dieses Teil sicherlich gebrauchen ;) Der Quelltext ist Teilkommentiert, in der .h Datei finden sich Informationen zur Benutzung. Fehlermeldungen, Fragen oder Anregungen sehe ich gerne! Viele Grüße, Marc
:
Verschoben durch User
Hallo, das sieht schon recht ordentlich aus. DMA ist prima, wollte das schon öfters testen. Leider fehlen einige Kommentare wie z.B. USART-Geschwindigkeit. Um deine Funktionen zu testen wäre eine lauffähige Test-Routine nicht schlecht gewesen. Gruß GG
Hallo GG, Ja, den DMA hab ich hier auch das erste mal getestet. Ist dank der Atmel-Bibliothek ne schön einfache sache und hat auch auf Anhieb geklappt. Sicher könnte man das aber noch verschönern ^^ Ich denke das die Einstellung der usart-geschwindigkeit von jedem selber vorgenommen werden kann. Die GPS-Chips habe heutzutage verschiedene Geschwindigkeiten (4800, 9600, 38400 Baud sind üblich), und nicht jeder taktet den xmega mit 32 Mhz so wie ich in dem Beispiel. Mal davon ab gibts von Atmel ein schönes excel-sheet zum berechnen der werte, zu finden in der Datei zur application note wie man den USART der xmegas nutzt. Eine Test-Routine ist nicht wirklich nötig. Einfach Serinit() aufrufen und die ankommenden Daten werden im Rohformat in die Arrays abgelegt. Will man die Werte im Klartext haben einfach GPS_Einlesen(Empfängernummer) aufrufen und schon sind die Werte in den betreffenden Variablen. Die Testroutine ist also: Serinit(); while(1) { GPS_Einlesen(1); // Hier Displayausgabe für Empfänger 1 machen ! } ;) Netten Gruß, Marc
Hallo Marc Seiffert, Egon 64 schrieb: > muss das Array zweidimensional sein? sollte so sein, vermutlich für 4 Satelliten. Aber.. der Aufruf GPGSV_Einlesen(GPGSV0, &GPS_Daten0) führt im AVR-Studio4 zu folgenden Fehler, da die Variable ein mehrdimensionales Array ist. warning: passing argument 1 of 'GPGSV_Einlesen' from incompatible pointer type void GPS_Einlesen(uint8_t Empfaenger){ if(Empfaenger == 0) { GPRMC_Einlesen(GPRMC0, &GPS_Daten0); // ok GPGGA_Einlesen(GPGGA0, &GPS_Daten0); // ok GPGSA_Einlesen(GPGSA0, &GPS_Daten0); // ok GPGSV_Einlesen(GPGSV0, &GPS_Daten0); // ** führt zu Fehler** } die dazugehörigen Variablen uint8_t GPRMC0[70]; // ok uint8_t GPGGA0[70]; // ok uint8_t GPGSA0[70]; // ok uint8_t GPGSV0[3][70]; // ** führt zu Fehler ** Den Fehler kann ich zwar im Aufruf beseitigen GPGSV_Einlesen(GPGSV0[0], &GPS_Daten0); aber dann stimmt sicher der Code nicht mehr. Marc Seiffert bitte um Infos! Gruß XMEGA
@ XMEGA nein, der Code müsste der selbe sein und das array ist 2-Dimensional weil es 3 Nachrichten mit sateliteninformationen gibt je 4 Sateliten ausserdem ist das kein Fehler sondern eine Warnung also nur halb so schlimm ;) Ich hätte auch 3 Einzelne Arrays erstellen können mit entsprechender abfrage aber ich fand das so eleganter ;) Sollte er wirklich etwas falsch einlesen sag aber bitte nochmal bescheid ! Viele Grüße, Marc
@Marc S.
schrieb im Beitrag #2021518:
> Sollte er wirklich etwas falsch einlesen sag aber bitte nochmal bescheid
Danke, es funktioniert astrein!
Gruß XMEGA
Hey Marc, vielen Dank für den Code und fürs "sharing". Aber warum nicht gleich UBX?? Sollten die Empfänger doch heute auch schon "sprechen" oder?? Und schon ein Paar Buchstaben mehr ;-) ?? Grüße, Mike (UniBW)
Hallo Mike, ich muss ehrlich sagen das mir UBX nix sagt. Und ich es auch noch nie bei einem empfänger gesehen habe ? Grüße, Marc (TU DO)
Hey Marc, ich hab nen Navilock GPS Empfänger, der eben dieses UBX (siehe Anhang) Protokoll spricht. Ist binär und wirklich super umfangreich und damit spart man sich die ganze NMEA Parserei ... Das Protokoll scheint zwar von µBlox zu sein, aber mein Empfänger (http://www.navilock.de/produkte/gruppen/13/Boards_und_Module/60413_NL-504ETTL_MTK_TTL_Modul.html) spricht das auch! Grüße, Mike
Hallo Marc, sehr interesant dein Code für XMeGA. Ich brauche nur die Uhrzeit aus dem RMC String für einen Datenlogger. So wie ich DMA verstehem arbeitet das doch unanhängig vom eigentlichen Programm, ich kann mich also auf meine Messroutinen konzentrieren mit meinem XMEGA, die Daten speichern auf SD Card und wenn ich die Uhrezeit brauche, hole ich die aus dem DMA Speicher ? Kann man auch noch einen DMA-Routine fürs speichern über SPI Port schreiben? Wäre toll, wenn Du mir dabei helfen könntest. Gruss Bernd
Hallo Bernd, das komplette speichern der NMEA-Strings inclusive des DMAs wird übern interrupt gesteuert, daher ist das schon richtig das du da nix mehr weiter tun musst ausser den Interrupt zu aktivieren. Du holst die Uhrzeit-Routinen aber nicht aus dem "DMA-Speicher" sondern aus dem dafür vorgesehenen String in das er per DMA gespeichert wurde ;) Was ich mich aber gerade Frage ist warum die DMA haben willst um auf die SD-Karte zu schreiben ? Wenns ein Datenlogger ist (und kein Oszi o.ä.) ist die Datenmenge i.a. so gering das da kein DMA nötig ist. Ich würde einfach einen Timer anwerfen mit der Samplerate die gewünscht ist und in der routine die Daten auf die Karte schreiben. Was auch noch wichtig ist: DMA geht NICHT mit der klassischen SPI Hardware (nicht als Master) dafür muss man den USART nehmen. Warum auch immer Atmel das so gemacht hat ich finde es extremst bescheuert. Ansonnsten muss ich dich leider enttäuschen ich habe selber ein Projekt das mit "sehr großen" Datenmengen hantiert. Leider habe ich DMA nie wirklich für die SD-Karte implementiert. Es war in meinem Fall vorteilhafter die daten von der SD-Karte zuerst auf einen At45DB161 zu speichern (und dabei zu konvertieren) um sie anschließend per DMA aufs Display zu streamen (dabei wurden Datenraten nahe 2 MB/s erreicht). Ich glaube etwa 12fps konnte ich aus dem Display herauskitzeln ;)Ziel des Projektes war das Anzeigen von 320x240x16 Bitmaps auf einem ebensogroßen Bildschirm, und das so schnell das man eine vernünftige Menüführung damit aufbauen kann. Viele Grüße, Marc
Hey Mike, UBX scheint tatsächlich Ublox spezifisch zu sein. Ich weis über die Vorteile binärer Protokolle und war auch schon am überlegen SIRF binary zu implementieren. Was mich aber davon abhält: NMEA versteht JEDER reciever ! Und wirklich Rechenleistung nimmt das ganze nicht ein auf nem XMEGA. das macht der im Hintergrund nebenbei ;) Daher (und weil ich zeitlich eh schon eng eingespannt bin) begnüge ich mich mit dem klassischen NMEA Protokoll. Wenn du natürlich Routinen für UBS oder weis Gott was schreibst füge ich sie gerne in die lib mit ein. Kannst natürlich auch Teile der LIB für deine eigene nutzen und dann UBX machen. Viele Grüße, Marc
Hi Marc, Du hast schon Recht ... NMEA spricht wirklich jeder Empfänger. Ich war damals, als ich das UBX ausprobiert habe einfach so happy mit den vielen Messages, die das Ding anbietet! Neben der "Standard" Position in LLH, gibts viele Werte auch in ECEF, Geschwindigkeiten sogar in NED .... hier ein Auszug aus dem Protokoll für NAV-VELNED 0 - iTOW ms GPS Millisecond Time of Week 4 - velN cm/s NED north velocity 8 - velE cm/s NED east velocity 12 - velD cm/s NED down velocity 16 - speed cm/s Speed (3-D) 20 - gSpeed cm/s Ground Speed (2-D) 24 - heading deg Heading 2-D 28 - sAcc cm/s Speed Accuracy Estimate 32 - cAcc deg Course / Heading Accuracy Estimate Ich bezweifle dass NMEA, das auch bringen kann ... man beachte die Einheiten z.B. für die Geschwindigkeiten [cm/s]. Ich finds klasse ... Viele Grüße, Mike
Hallo Mike, wenn ich mir die Einheiten so ansehe muss ich ehrlich sagen das ich bezweifel das GPS das auch nur ansatzweise kann. Die Ungenauigkeit zwischen 2 Fixes kann ja schon ein paar Meter betragen. Vermutlich kann man die Hohe Auflösung nur nutzen wenn man mit DGPS arbeitet um die Positionsgenauigkeit stark zu erhöhen. Dann haben sie defintiv ihren Sinn. Viele Grüße, Marc
Hallo Marc, teils gebe ich Dir recht, aber die Geschwindikkeitsmessung erfolgt bei so gut wie allen Empfänger nicht über eine Positionsdifferenzierung, sondern über die Phasenverschiebung (Dopplerverschiebung) der Trägerfrequenz (ugs. das GPS-Lock). Ich hab mal nen paar Tests im Garten gemacht und bin ein wenig rumgelaufen ... Klar ist Rauschen drauf, aber die Werte sahen wirklich nicht schlecht aus! Muss mal schauen, evtl. finde ich die Plots noch ... Mit DPGS wärs dann natürlich am Besten ... Viele Grüße, Mike
Hallo Mike, Interessant auf die idee das die Dinger das per Dopplereffekt machen bin ich noch nie gekommen :) Die Plots klingen interessant zeig mal ruhig her ! Ja nur ist DGPS leider nicht so ganz ohne Aufwand ^^ Viele Grüße, Marc
Hi Marc, hätte mich auch gewundert, wenn Dir das entgangen wäre ;-) Die Plots sind leider unauffindbar, aber ich code grad an meinem Tricopter - Regler und da werden hoffentlich bald auch mal ein paar Flugversuche im Garten gestartet und demnach neue Plots entstehen, die ich dann nachreiche ... Viele Grüße, Mike
Hi Mike, schöne Sache das, ich arbeite zur Zeit mit zwei Kollegen an nem recht großen Quadro...weg von "klein und niedlich" hin zu groß und "böse", maximal 12kg Auftrieb wird er haben bei nem Eigengewicht von etwa 3kg, Spannweite fast 1m. Ist ala AEV konzipiert und dementsprechent mit leistungsstarken Antennen (50km) sowie langer Flugzeit(ca 40-60 Minuten) ausgestattet. Wollten ursprünglich einen Oktocopter bauen wegen der Redundanz haben das aber aus Kosten- und Aufwandsgründen gelassen. Viele Grüße, Marc
Hi Marc, klingt spannend!! Wofür steht den AEV? Kenne nur AUV ;-) Kennst das schon: http://www.youtube.com/watch?v=kh_eZE3OQlQ http://defense-update.com/wp/20101004_panther_uav.html Geiles Projekt! Grüße, Mike
Morgen Mike, AEV steht für Autonomous Aerial Vehicle. Im Endeffekt brauch ner nutzer nacher nix weiter eingeben ausser einer GPS-Koordinate und das Gerät fliegt diese automatisch an und kehrt wieder zurück. Natürlich ist dieser Modus nur neben dem vollhändischen flug implementiert. Das Israelische Projekt schaut nicht schlecht aus. Aber so extrem geil finde ich es nicht, ich wagesogar zu bahaupten das es auf der welt noch andere private modellbauer gibt die auch soetwas haben ;) Scheint auch ausschließlich als überwachungsdrohne konzipiert zu sein. Wobei ich den israelis da noch ein paar Tricks zutraue ^^ Grüße, Marc
Hey Marc, klingt schick! Habt ihr dann dann auch einen "intelligenten" Agenten an Bord, der Entscheidungen trifft (bzgl. dem autonomous), plant und eine Mission bekommt?? Oder doch eher "automatic" ?? Das Israeli - Projekt finde ich dahingehend cool, da das Ding 65kg wiegt und 6 Stunden in der Luft bleiben kann ... ich bezweifel, dass das ein "normaler" Modellbauer auch hat ... aber das Konzept hab ich auch schon ein einem "Zagi" gesehen, von daher gebe ich Dir Recht! Grüße, Mike
Hey Mike, der Copter wird autonom auf einige Probleme reagieren können, zum Beispiel wenn der Akku zu leer wird kehrt er automatisch zur Basis (Startpunkt / Vorgegebene Position) zurück. Bei verlust des Empfanges wird zuerst versucht in eine günstige Positon zu geraten ( höher ) und anschließene ebenfalls der Rückweg angetreten falls das nix bringt. Weitere Autonomität machtkeinen Sinn das Ding soll im Endeffekt ja nur das tun was ich will ;) hmm...65kg sind definitiv ne Hausnummer. Aber groß bedeutet nicht unbedingt schwer zu realisieren oder teuer ! Teilweise im Gegenteil. Mein Copter hat sogar ein recht großes Grafikdisplay drauf und nen Empfängerakku zusätzlich, weils das Gewicht einfach erlaubt. Und ich habe zwar stark aufs gewicht geachtet (sogar dünnes Epoxi ist in Verwendung) trotzdem ist es nicht so kritisch. Die lange Flugzeit wird wohl auch nur im Horizontalflug, nicht beim schweben zu realisieren sein ( es sei denn die Israelis haben Akkus von denen ich nix weis ;)) Grüße, Marc
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.