Hallo, an einem Atmega644 hängt ein GPS Sensor, der mit 5Hz Daten per UART sendet. Das Programm auf dem µC soll ebenfalls mit etwa 5Hz laufen. Pro Durchlauf werden noch ADC-Werte und eine Frequenz per Timer gemessen. Frage: Wie sichere ich nun am besten die ankommenden Werte vom GPS Sensor? Einfach 1x per Durchlauf den Interrupt auslösen und die Daten in einer Variablen sichern? Danke!
Hi >Das Programm auf dem µC soll ebenfalls mit etwa 5Hz laufen. Ich würde ein paar MHz nehmen. >Wie sichere ich nun am besten die ankommenden Werte vom GPS Sensor? >Einfach 1x per Durchlauf den Interrupt auslösen und die Daten in einer >Variablen sichern? Was soll da einen Interrupt auslösen? Üblicherweise sendet der GPS-Empfänger die Daten in einem NMEA-String. Diesen String solltest du in einen Puffer einlesen und dann decodieren. MfG Spess
Also wenn die Daten am RX anliegen löst ein Interrupt aus. In der aufgerufenen Methode wird der Empfangspuffer in eine Variable geschrieben, die dann im Hauptprogramm verfügbar ist. Würdest du das ganze schneller laufen lassen? Ich wollte an den 5 Hz festhalten, da die GPS Daten in der Frequenz kommen. Ok man könnte die Frequenz mit Faktor 10 multiplizieren und die GPS Daten dazwischen interpolieren.
Hi >Also wenn die Daten am RX anliegen löst ein Interrupt aus. In der >aufgerufenen Methode wird der Empfangspuffer in eine Variable >geschrieben, die dann im Hauptprogramm verfügbar ist. Also du bekommst die Daten z.B. in folgender Form: $GPGGA,161229.487,3723.2475,N,12158.3416,W,1,07,1.0,9.0,M, , , ,0000*18<CR><LF> In diesem String sind z.B. UTC Time, Latitude, N/S Indicator, Longitude, E/W Indicator, ... enthalten. NMEA-Strings fangen alle mit einem '$' an. Das must du erkennen und dann die Zeichen bis <CR><LF> speichern. Der Rx-Complete-Interrupt wird aber bei jedem Zeichen ausgelöst. In dem Interrupt kannst du die Anfang-, Ende-Erkennung und das Abspeichern erledigen. >Würdest du das ganze schneller laufen lassen? Ich wollte an den 5 Hz >festhalten, da die GPS Daten in der Frequenz kommen. Ok man könnte die >Frequenz mit Faktor 10 multiplizieren und die GPS Daten dazwischen >interpolieren. Das war mehr auf den Controller gemünzt. Eigentlich braucht dein Programm keinen 'Takt'. Der wird ja schon vom GPS-Empfänger vorgegeben. MfG Spess
Hi, der Empfang von dem String ist eigentlich kein Problem - ich erkenne das <cr> und speichere dann den String. Was mir etwas Sorgen macht ist folgendes: Der Sensor liefert ja alle 250ms einen Datensatz. Ich weiß aber nicht von "wann" der Wert im Buffer ist. Das Hauptprogramm sammelt jetzt also die Werte der weiteren Sensoren und liest dann einmal den Empfangsbuffer. In dem Moment ist dann aber unbekannt, ob der GPS Wert 249ms alt ist oder eben nur 2ms. Ein weiteres Problem bzw Frage: Der Interrupt kann ja jederzeit ausgelöst werden, ich glaube das ist aber nicht zulässig, wenn gerade ADC gelesen wird, oder? Ich messe noch mit PB0 (Capture1) eine angelegte Taktfrequenz. Gibt es ein Problem mit den beiden Interrupts, wenn die sich in die Quere kommen? Das sind alles Anfängerfragen - sorry!
Hi >der Empfang von dem String ist eigentlich kein Problem - ich erkenne das ><cr> und speichere dann den String. Dann sollte er schon gepeichert sein. Die UART kann nur einzelne Zeichen puffern. >Das Hauptprogramm sammelt jetzt also die Werte der weiteren Sensoren und >liest dann einmal den Empfangsbuffer. In dem Moment ist dann aber >unbekannt, ob der GPS Wert 249ms alt ist oder eben nur 2ms. Dann starte doch die Messungen nach Empfang der Strings. Eine ADC_Messung (First Conversation) dauert ca. 200µs. >Ich messe noch mit PB0 (Capture1) eine angelegte Taktfrequenz. Gibt es >ein Problem mit den beiden Interrupts, wenn die sich in die Quere >kommen? Ein laufender Interrupt wird nicht unterbrochen und andere Interrupts werden in der Zeit gespeichert. Bei hinreichend kurzen Interruptroutinen kein Problem. MfG Spess
Stimmt, das ist eine gute Idee - dann wäre der Rest mit dem GPS synchronisiert. Danke für die Anregung! Wie würdest du es lösen, fallst das Hauptprogramm doch mit einem höheren Takt als der GPS-Sensoren laufen soll? Auf Anhieb fällt mir ein einfach den GPS-Buffer jedes mal mit zu schreiben und später in der Auswertung zu prüfen, ob die Werte gleich sind - falls es der Fall ist, werden die dann verworfen. Der ganze Vorgang würde sich dann am ersten GPS String synchronisieren.
Hi >Wie würdest du es lösen, fallst das Hauptprogramm doch mit einem höheren >Takt als der GPS-Sensoren laufen soll? So richtig verstehe ich nicht, was du mit 'Takt' meinst. Ein Programm führt Befehle mit der vom Controller-Takt vorgegebenen Geschwindigkeit aus. MfG Spess
Also die Logik ist folgende: Das Programm läuft in einer Endlosschleife. In jedem Durchlauf werden die Sensorwerte gelesen und dann auf einen USB Stick geschrieben. Um nicht unnötigen Overhead zu generieren, würde ich dann nach jedem Durchlauf eine künstliche Verzögerung a la waitms 125 einbauen. Dieser Wait ist dann den Takt, von dem ich spreche :) Grüße Alex
Hi Vielleicht sollte mal die Programmiersprache geklärt werden. >Um nicht unnötigen Overhead zu generieren, würde ich dann nach jedem >Durchlauf eine künstliche Verzögerung a la waitms 125 einbauen. Dieser >Wait ist dann den Takt, von dem ich spreche :) Warum 'wait'. Z.B. kann der ADC des ATMega von einem Timer getriggert werden (ADC Auto Trigger Source: Timer/Counter0 Overflow,Timer/Counter1 Compare Match B, Timer/Counter1 Overflow, Timer/Counter1 Capture Event). Das wäre auch für andere Aktivitäten die sinnvollere Methode. MfG Spess
Hallo Spess, also zu meiner Schande - ich programmiere in Bascom. Klar - man könnte das ganze mit einem Timer triggern, aber hat das Vorteile gegenüber einem Aufbau wie: do sammle werte speichere werte waitms x loop ? Grüße Alex PS. Gut dass ich nicht der einzige bin, der heute am PC hängt ;)
Hi >also zu meiner Schande - ich programmiere in Bascom. Als notorischer Assemblerprogrammierer bin ich Naserümpfen gewöhnt. >In jedem Durchlauf werden die Sensorwerte gelesen und dann auf einen USB >Stick geschrieben. Hast du das schon Hard- und Softwaremäßig abgeklärt? >Klar - man könnte das ganze mit einem Timer triggern, aber hat das >Vorteile gegenüber einem Aufbau wie: Ich persönlich lasse den Controller, das was er allein kann auch allein machen. Du solltest auch bedenken, das die Verwaltung des USB-Sticks einige Rechenzeit in Anspruch nehmen kann. MfG Spess
spess53 schrieb: > > Hast du das schon Hard- und Softwaremäßig abgeklärt? > Ja, ih benutze das STI100 Interface. Der Atmega644P-20 hat ja 2 UARTs. An UART 0 hängt das STI, an UART 1 der GPS Sensor. > > Ich persönlich lasse den Controller, das was er allein kann auch allein > machen. Du solltest auch bedenken, das die Verwaltung des USB-Sticks > einige Rechenzeit in Anspruch nehmen kann. > Stimmt an die Verwaltung habe ich nicht gedacht, wobei es eigentlich relativ schnell gehen sollte. Ich habe jetzt in der Spec. vom STI zwar keine Timings gefunden, Controllerseitig muss ich aber eigentlich nur die zu schreibenden Daten per UART an das Interface senden. Also die ideale Vorgehensweise wäre per Timer eine Methode aufzurufen, die die Sensordaten einliest und am Ende auf den Stick schreibt? Grüße Alex
Hi >Also die ideale Vorgehensweise wäre per Timer eine Methode aufzurufen, >die die Sensordaten einliest und am Ende auf den Stick schreibt? Ich würde es so machen. Ist aber meine persönliche Meinung. >Ja, ih benutze das STI100 Interface. Der Atmega644P-20 hat ja 2 UARTs. >An UART 0 hängt das STI, an UART 1 der GPS Sensor. Hast du es wirklich schon benutzt? MfG Spess
Jap, zwar ausserhalb von der aktuellen Platine, aber ich habe das Ding probehalber in einem Testaufbau ausprobiert. Warum fragst du? Kennst du das Teil? Hab ich da Probleme zu erwarten? Gruß Alex
Hi >Warum fragst du? Weil die mitgelieferten Sourcen in C sind. >Kennst du das Teil? Nur vom ELV-Magazin. >Hab ich da Probleme zu erwarten? Kann ich nicht sagen MfG Spess
Jap das stimmt, aber die Doku ist recht gut, so dass das Teil sich relativ Problemlos auch aus Bascom heraus ansprechen lies. Zumindest in meinen Versuchen war ich ziemlich zufrieden damit! Gruß Alex
Thread beobachten
Seitenaufteilung abschaltenBitte 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.