RS232 (Hardware) Buffer

Hallo,

ich suche eine Möglichkeit einen seriellen Datenstrom zwischenzuspeichern und verzögert auszugeben. Da ich nicht sehr viel Platz habe wäre mir ein SMD-Chip recht. RS232 ist auch etwas übertrieben, die seriellen Signale sind 0V / 3,3V. die Versorgungsspannung ebenfalls 3,3V.

Der Grund des ganzen: Ich möchte einen GPS-Empfänger an einem Atmel abfragen. Mit meinem Test-Empfänger hat alles wunderbar geklappt. Jetzt habe ich den richtigen angeschlossen (Navilock NL501 ETTL), aber der sendet die Zeichen zu schnell. Die Baudrate ist zwar schon 2400, aber die Pause zwischen den Zeichen ist zu kurz. Ich schreibe im Atmel bereits in einen Buffer, aber trotzdem werden Zeichen verschluckt.

Da immer ca. 20 bis 50 Zeichen gesendet werden und danach eine Sekunde Pause ist müsste ich diese Zeichen in einem Buffer zwischenspeichern und dann mit Pausen Zeichen für Zeichen ausgeben.

Mein AVR läuft bereits mit 8 MHz, deswegen denke ich das ich mit einem weiteren Atmel keinen Buffer bauen kann, auch wenn dieser sonst überhaupt nichts zu tun hat.

Kennt jemand einen (SMD) Chip der so etwas bewerkstelligt, meinetwegen mit Abfragen der RTS Leitung oder änliches?

Viele Grüße
Andreas

Wenn Du im AVR die serielle Schnittstelle Interruptbasiert behandelst, und einen FIFO Buffer mit ausreichender Grösse softwaremässig implementierst, sollte es kein Problem sein, das ganze on Chip zu erledigen.

Im RN-Wissen Berecih gibt es den kompletten Code für Interrupt-UART und FIFO in C, funktioniert ohne Probleme.

Eventuell könntest Du noch Deine Berechnungen i-wie optimieren (zur Not an kritischen Stellen mit inline-Assembler).

mfg

pongi

Hallo pongi,

genauso ist es ja gelöst. Ich habe jetzt zum testen folgenden Code verwendet:

U8 Pos;
U8 Err;
U8 Buf[255];

Err = 0;
Buf[0] = 0;
Pos = 1;

while (Buf[Pos - 1] != '$')
{
if ((UCSR1A & (1<<DOR1)) != 0)
Err++;

if ((UCSR1A & (1<<RXC1)) != 0)
Buf[Pos++] = UDR1;
}

Die GPS-NMEA-Datensätze beginnen immer mit einem $-Zeichen, deshalb nutze ich das als Trenner für diese kurze Test-Schleife. Das ganze läuft auf einem AT90USB1287 als einziger Code mit einem 8MHz-Quarz. Die Baudrate beträgt 4800.

Die Datenzeilen kommen im Sekunden-Takt und sind immer zwischen 40 und 80 Byte lang. Aber selbst hier bekomme ich in der Schleife oben zwischen 20 und 30 Err-Counts. (Data Overrun des USART)

Wenn ich mir nach der Schleife auf einem angeschlossenem Display den empfangenen Datensatz anzeigen lasse fehlen tatsächlich ca. so viele Zeichen. Ich habe zum testen parallel den TXD-Pin über mein STK500 mit Hyperterminal angeschaut und hier ist alles da.

Das ganze ist für mich jedoch etwas unlogisch, da bei 4800 Baud der Prozessor ja theoretisch 2ms Zeit hat bis das nächste Zeichen kommt. In dieser Zeit schafft er bei 8MHz knapp 4000 Clocks, oder bei einem Durchschnitt von 3 Clocks pro Befehl über 1000 Befehle.

Der Quarz stimmt, da ich im selben Prozessor ein Wave mit 11025 Hz aufzeichne und diese Aufzeichnung passt.

Einen Frame- oder Parity-Error bekomme ich nicht, das habe ich in der Schleife auch schon zählen lassen. Einzig die DOR-Anzahl erhöht sich wenn ich diese beiden Bits mitzähle.

Wo ist das Problem bzw. mein Denkfehler? Sollte ich das ganze eventuell noch mal im AVR-Software-Forum posten?

Viele Grüße
Andreas

Ich steh' wahrscheinlich auf dem schlauch, ggf. bitte ich um Schläge.
Deine Schleife bricht doch genau dann ab, wenn grad ein $ gekommen ist.
dann geht aber doch die Message erst los ?

Woran erkennt man, daß die Message zu Ende is ? Irgendwelche Längenangaben in der Message ?

Hallo PicNick,

du bist nicht doof. Ich habe zur Übersicht nur den wichtigen Teil gepostet. Vorher kommt noch eine kurze Schleife die auf das erste $ wartet. Die Messung erfolgt dann über einen ganzen Datensatz. ($GPRMC-Meldung) Der GPS-Empfänger ist so konfiguriert das er nur diesen im Sekunden-Takt sendet.

I see. d.h heisst, du checkst die Message dann, wenn die nächste kommt ?
nix gut.
Das Ende einer Message muß doch zu erkennen sein ? gibt's da doku ?
Irgendein Standard ? (GPS-mäßig bin ich tot)

EDIT: Wiki lesen bildet.

Das Ende ist offenbar ein Asteriks (*) dann würde ich

Code:

---

pos = 0
while (1)
{ 
        errorcheck
        if zeichen
        {
            temp = UDR
            if temp == $
                    pos = 0;
            if temp == *
                    break;
            buf [pos++] = temp
        }
}
workout  buf[0...pos]

---

Hallo PicNick,

in meiner tatsächlichen Anwendung mit IRQ und FIFO prüfe ich auch auf den * und sogar die Checksumme. Nur in diesem kleinen Test wollte ich den Prozessor nicht mit komplizierten Prüfungen belasten.

Aber wenn ich den Test auf den * als Prüfung umschreibe funktioniert es tatsächlich. Komisch ist nur, warum er dann vorher Zeichen verschluckt.

Aber da werde ich jetzt mal eine Nacht drüber schlafen und hoffen das mir dazu was einfällt.

Vielen Dank und Viele Grüße
Andreas

Zitat:

---

..eine Nacht drüber schlafen ..

---

Recht so. Rühr dich halt wieder.
Wie gesagt, bis 9600 muß das LOCKER auch so gehen, das gibt's nicht.

keine Info zu GPS-Modulen:

Sehr viele GPS-Module, welche das NMEA-Protokoll unterstützen, lassen sich auch konfigurieren. Da können so einige Sachen wie z.B. der Einsatzzweck (Mobiler einsatz, Stationärer Einsatz usw. ) aber auch einige Dinge zum Protokoll eingestellt werden. Dazu gehören z.B. welche Messages das Modul schicken soll, wie oft es Daten senden Soll und vieles mehr.

Trotz alle dem kommt ein AVR mit 8MHz getaktet, wenn er nicht anderweitig ausgelastet ist, ohne Probleme mit nem GPS bei 9600 Baud un 3..5 Updates pro Sekunde klar.

Gruß, Volker

Hallo Volker,

selbstverständlich habe ich mein GPS-Modul konfiguriert. Das habe ich auch in einem meiner Beiträge angedeutet.

Das Modul ist ein Sirf3-Chip den ich auf 4800 Baud und nur die Meldungen $GPRMC und $GPGSA im Sekunden-Takt konfiguriert habe. Wenn ich mir die geschickten Daten im Hyperterminal ansehe kommen die beiden Nachrichten fast auf einen Schlag in der Reihenfolge RMC und GSA, danach eine Sekunde Pause und wieder die Nachrichten...

Ich habe ja dank des Denkanstosses von PicNick festgestellt das der Controller schnell genug ist um die Daten zu Empfangen. Bei 4800 Baud habe ich wie gesagt über 2ms Zeit zwischen den Zeichen. Das sind bei 8Mhz auf jeden Fall über 1000 Befehle.

Ich speichere die empfangenen Zeichen im USART-IRQ in einen Buffer und setze ein Flag, wenn eine Nachricht vollständig angekommen ist. Wenn im Hauptprogramm Zeit ist wird dieses Flag überprüft, und wenn gesetzt der Buffer ausgewertet. Ich arbeite sogar mit 2 Buffern, um einen auswerten zu können und im anderen schon wieder die nächste Nachricht aufzuzeichnen.

Allerdings funktioniert irgendwas nicht. Ich habe heute fast den ganzen Tag an dem Problem gesessen, aber keinen Fehler gefunden. Vermutlich sehe ich den Wald vor lauter Bäumen nicht mehr. Deshalb wäre es nett wenn mal hier jemand schnell über den Quellcode gucken kann wo mein brutaler Denkfehler ist.

Erst mal die Deklarationen der Buffer, Flags, Pointer, etc.:

volatile U8 Akt_GPS_Rekord_Buffer= 0;
volatile U8 Akt_GPS_Rekord_Ende= 254;
volatile U8 GPS_Buffer_Auswerten[2];
volatile U8 GPS_Buffer_Pointer[2];
volatile char GPS_Buffer1[255];
volatile char GPS_Buffer2[255];

#define Aus 0
#define Ein 1

Und hier die IRQ-Behandlung:

ISR (USART1_RX_vect)
{char Zeichen;

Zeichen = UDR1;

if (Zeichen == '$')
{if (Akt_GPS_Rekord_Buffer == 0)
{if (GPS_Buffer_Auswerten[1] == Aus)
Akt_GPS_Rekord_Buffer = 1;

if (GPS_Buffer_Auswerten[2] == Aus)
Akt_GPS_Rekord_Buffer = 2;
}

if (Akt_GPS_Rekord_Buffer > 0)
{GPS_Buffer_Pointer[Akt_GPS_Rekord_Buffer] = 0;
Akt_GPS_Rekord_Ende = 254;
}
} else if ((Zeichen == '*') & (Akt_GPS_Rekord_Buffer > 0))
{if (GPS_Buffer_Pointer[Akt_GPS_Rekord_Buffer] < 253)
Akt_GPS_Rekord_Ende = GPS_Buffer_Pointer[Akt_GPS_Rekord_Buffer] + 2;
else
Akt_GPS_Rekord_Buffer = 0;
}

if (Akt_GPS_Rekord_Buffer > 0)
{switch (Akt_GPS_Rekord_Buffer)
{case 1: {GPS_Buffer1[GPS_Buffer_Pointer[Akt_GPS_Rekord_Buffer]++] = Zeichen;
break;}
case 2: {GPS_Buffer2[GPS_Buffer_Pointer[Akt_GPS_Rekord_Buffer]++] = Zeichen;
break;}
}

if (GPS_Buffer_Pointer[Akt_GPS_Rekord_Buffer] > Akt_GPS_Rekord_Ende)
{if (Akt_GPS_Rekord_Ende < 254)
GPS_Buffer_Auswerten[Akt_GPS_Rekord_Buffer] = Ein;
Akt_GPS_Rekord_Buffer = 0;
}
}
}

Für alle die nicht wissen wie eine NMEA-Nachricht aufgebaut ist: Sie fangen mit einem Dollar ($) an, und enden mit einem Asteriks (*) gefolgt von zwei Zeichen für die Checksumme. Also zum Beispiel:
$GPRMS.......*AA

Viele Grüße
Andreas

Moin,

ich habs. Im Hauptprogramm war noch ein Teil auf den alten Empfänger bei dem die Flags GPS_Buffer_Auswerten fälschlicherweise auf Aus gesetzt wurden.

Mannomann, das war eine harte Nuss. Das nächste mal entwickle ich gleich mit dem richtigen Empfänger.

Vielen Dank und Viele Grüße
Andreas

ich hab hier auch n GPS modul rumliegen bekomm aber immer nur warnmeldung und keine positionsdaten ... kannst du mir eventuell rat geben ?

$gprmc XXX.XXX,V,,,,, da wo V steht sollte A stehen tut es aber nicht und alle folgenden werte sind Void, wie man sehen kann Q_Q

EDIT: kommando zurück ... gestern waren noch alle lämpchen rot ... jetzt sind se alle grün und es funkt ^_^ kA wieso der gestern das signal net bekommen hat

Wenns "nur" ein Sirf2 ist bekommen die nur im freien richtigen Empfang. Alles außer Sirf3 kann man IMHO vergessen. Ein Sirf2 bekommt hier im Haus überhaupt keinen Empfang, der Sirf3 bekommt auf meinem Schreibtisch bis zu 8 Sateliten und das nach nicht aml einer Minute, wenn er über Nacht stromlos war.

gestern abend hab ich das ding praktisch zum allerersten mal eingeschalten, der akku war praktisch tot und musste ersetzt werden ... deshalb wars ja auch so spot billig ^^
gestern ging gar nix ... über nacht war er ausgeschalten und jetzt funkt er einwandfrei ... sieht so aus als hätt ich hier nur 4 satteliten aber die realtive positionsbestimmung iss ja doch viel besser als erwartet ... wenn ich das ding ein paar cm bewege ist das sogar messbar ... eventuell probier ich meinen plan mit dem ferngesteuerten asuro doch per GPS aus ... mal sehen wie brauchbar die lokalisierung ist

Das kannst du nach meinen Erfahrungen vergessen. Auch wenn du meinst eine von ein paar cm Abweichung messen zu können, ab und zu springt der Empfänger wie wild, teileise sogar um km wenns kein Sirf3 ist. Selbst die Sirf3 springen ein paar hundert Meter. Kommt wohl ganz auf die ganzen stratosphärischen und sonstwas Störungen an.

Falls du das trotzdem probieren willst, solltest du aus der $GPGSA Meldung die DOP's abfragen und auswerten, google hilft dir hier weiter.

ich weis ich weis, hab mich gestern abend schon damit befasst, ich bekomme auch so ziemlich alles was der empfänger empfangen kann inklusive korrektursignal, nur auswerten und verrechnen muss ich es von hand so wie es scheint

Äh, die DOP's geben nur an wie "gut" die Position ist, also eine Qualitätsangabe. Ich verwerfe einfach alle Positionen die keine gute "Qualität" haben. Verrechnen musst du da gar nichts. Wenn du es genau haben möchtest musst du mal mit DGPS oder ähnlichem gucken, da habe ich aber auch noch nichts mit gemacht.

ich dachte das GPGGA die korrekturwerte liefert ? ich hab mich leider noch nicht so ganz mit dem protokoll auseinandergesetzt aber ich bastel mir grad nen kleinen parser um mir die werte ansehen zu können.

Also ich meine GSA nicht GGA. Ich wüßte aber auch nicht das irgendwelche Korrekturwerte gesendet werden. Wäre ja auch quatsch, warum korrigiert der Empfänger dann seine Position nicht selbstständig?

ok nachdem ich "mal wieder" kontakt bekommen habe .... in der wohnung iss das echt scheusslich ... habe ich nach längerem testen genau das bemerkt was du gesagt hast .... ich konnte cm-weise bewegungen messen, aber nach 20 min hatte ich einen ziemlich intensiven drall in eine richtung obwohl der empfänger nur rumlag .... meine frage an der stelle .... müssten die abweichungen sich nicht THEORETISCH auf 2 empfänger gleich auswirken ? dann könnte ich zur not ja einen referenzempfänger aufstellen .... einen zu bekommen ist in der beziehung kein problem für mich ... und dann die relativen korordinaten zum bezugsempfänger rechnen ? als weitere ausrichtungs-referenz hab ich ja den kompass aufm asuro

Also das habe ich noch nicht mit 2 Empfängern getestet und traue mir über das Ergebnis dieses Tests auch keine Aussage zu.

Ich habe bei mir gegen das springen einen Filter eingebaut, der die gemeldete Geschwindigkeit des Empfängers abfragt. Für Sirf3-Chips hat sich der Wert 5 KM/h für mindestens 7 Sekunden als perfekt herausgestellt. (Wir bauen damit gewerblich GPS-Tracking-Systeme) Mit diesem Wert erkennen wir bei KFZ eine sichere Bewegung, haben aber auch für über eine Woche stillstand ohne Sprünge auch wenn der GPS schlechten Empfang hat (z.B. unter einem Carport)

Wie die Filter für deinen Roboter und GPS-Emfpänger sein müssen kann ich dir leider nicht sagen, da ist probieren angesagt.

Viele Grüße
Andreas

jap so sieht es aus ... ich werd mich nächstes jahr nochmal melden, so schnell komm ich leider nicht an den 2ten empfänger ran XD derweilen kümmer ich mich erstmal um den kompass und um ein weiteresprojekt >_<

Hallo zusammen,

Zitat:

---

Zitat von Ceos

meine frage an der stelle .... müssten die abweichungen sich nicht THEORETISCH auf 2 empfänger gleich auswirken ? dann könnte ich zur not ja einen referenzempfänger aufstellen ... und dann die relativen korordinaten zum bezugsempfänger rechnen ?

---

Ja, genau diese Idee liegt DGPS zu Grunde. Zwei räumlich nahe beieinander liegende Empfänger, von denen einer ortsfest montiert ist (auf dem Tisch liegt) und der andere sich bewegt (auf dem Asuro z.b.). Der Ortsfeste nimmt also die scheinbare Bewegung auf und stellt das Korrektursignal zur Verfügung.

Die beobachtete Bewegung ist übrigens kaum auf Atmosphäre und so zurückzuführen! Dies ist eine künstliche und gewollte Überlagerung der Satellitensignale um die militärische Anwendung zu unterbinden. Das militäriche GPS-Signal erlaubt eine Präzision auf +/-1cm genau. An DGPS mit den zivilen Empfängern hat freundlicherweise keiner gedacht =D>

Gruß H.A.R.R.Y.

naja in der theorie sind alle mäuse grau ... ich muss das mal praktisch testen

Servus,

ich betreibe das NL 501ETTL Modul an einem ATmega128. Ich logge damit den GGA Datensatz auf SD Karte. Wenn ich meine gefahrene Route auf Google Earth übertrage, erscheint die ganze Tour um ca 200m nach links unten versetzt. Woher kann das kommen? Ein Rundungsfehler beim Umrechnen der Daten? Zu wenig empfangene Sateliten (8 warens eigentlich immer)?
Kann man bei dem Modul eigentlich EGNOS verwenden und wenn ja, muss man es einschalten?
Wer hat Erfahrung mit diesem Modul, die vom Navilocksupport auf jeden Fall net :-(