-
-
Erfahrener Benutzer
Roboter Experte
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
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- Anhänge hochladen: Nein
- Beiträge bearbeiten: Nein
-
Foren-Regeln
Lesezeichen