Was bedeutet UART Frame Error genau?

Mit den Stop-Bits, der Datenlänge (6-9Bits) und / oder der Parität haut 
etwas nicht hin. Oder Du hast Dich tatsächlich bei der Baudrate 
verrechnet. 4Mhz und 9600 Baud ist kein Problem, der Fehler wäre nur 
0.2%.
Ich tippe mal auf ein falsch initialisiertes UART Controllregister.

Bei der Fleury-lib reicht doch:

1

#define UART_BAUD_RATE   9600

2

...

3

uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) );

zum initialisieren, oder?
Ich glaube man muss 8 Datenbits, ein Stopbit, und keine Parität 
einstellen, und das ist doch in der Fleury-lib schon voreingestellt, 
oder?

Kann es dann daran liegen, dass ich das ganze auf einem 
Reicheltsteckbrett aufgebaut habe, und deswegen die Baudraten nicht 
klappen?
Ach ja: der Oszillator sitzt auch nicht direkt nebem dem µC, und ist mit 
einem etwa 7cm langen isolierten Drahtsück mit diesem verbunden.


Gruß, Steffen

>Kann es dann daran liegen, dass ich das ganze auf einem
>Reicheltsteckbrett aufgebaut habe, und deswegen die Baudraten nicht
>klappen?

Normal nicht - wenn alle Bauteile fest sitzen und keine Drahtbrücke 
fehlt / zuviel ist. Womit programmierst Du (Software, Programmiergerät)? 
Hast Du F_CPU richtig definiert?

Zum Programmieren verwende ich USBprog, und AVR Studio, als Software. 
F_CPU, habe ich meiner Ansicht nach überall richtig definiert.
Drahtbrücken sind eigentlich keine zu viel, und es fehlen auch keine, 
also angeschlossen müsste alles richtig sein.

Wenn ich wie gesagt, den PC zwischen µC und GPS- Empfäger hände, kommt 
am PC alles richtig an...
Ich werde jetztmal den GPS- Empfänger komplett weglassen, und direkt vom 
PC Sachen zum µC schicken, mal schauen, ob das funktioniert....

Gruß, Steffen

PS: @travelrec: Ich habe dir eine Mail geschrieben, bzgl. deiner 
Schutzschaltung mit den Widerständen für den Dragon - hast du die 
bekommen?

Ich habe etwas sehr interessantes herausgefunden: Ich hab nun einfch mal 
in meinen Code geschrieben, dass der Mega8 immer ein Zeichen empfangen 
soll, das am Display ausgeben, und über den UART zurückschicken. Nun hab 
ich also mein Terminalprogramm am Pc aufmemacht (HTerm), alles 
ordentlich verbunden, und mal ein Zeichen (l) an den Mege8 geschickt.
Und was passiert? Er zeigt mir auf dem Display das große E an, dass er 
schon immer angezeigt hat, und sendet mir dieses auch über den UART 
zurück.
Der Mega8 empfängt also immer nur ein E, egal was der GPS- Empfänger 
sendet...
Woran kann das liegen?
Ich hab nochmal meinen Code angehängt.

Gruß, Steffen

Steffen O. wrote:

> Was bedeutet das genau?

Dass zum erwarteten Zeitpunkt kein Stopbit zu finden war.  Nach dem
Startbit (Wechsel des Pegels vom aktiven zum inaktiven Zustand)
tastet die UART n-mal (n = Zeichenlänge in Bits) die Datenbits ab,
bei der nachfolgenden Abtastung eine Bitperiode danach erwartet sie
ein Stopbit in Form eines aktiven Pegels.  Ergibt diese Abtastung
einen inaktiven Pegel, hast du einen framing error.

Konnte man bei RS-232 für ein out-of-band-signalling benutzen, das
sogenannte "serial break": man hat einfach für eine bestimmte Zeit
(relativ unkritisch, deutlich mehr als 10 Bitzeiten) den Pegel auf
inaktiv gezogen.  Mit entsprechendem Pulling an den Eingängen ergibt
auch das Abschalten eines seriellen Terminals einen BREAK.

Ok, danke für deine Erklärungen!!!
Und das beudeutet, dass, wenn der GPS Empfänger an meinem Mega8 hängt, 
kein Stopbit übertragen wird?

Wenn ich ihn den Mega8 aber am PC hängen habe, kommt der Frame Error 
nicht, aber der ATmega8 gibt, egal welches Zeichen ich per UART sende, 
auf dem LCD, und am UART ein großes E aus. Wodurch lässt sich das 
erklären?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

Steffen O. wrote:

> Und das beudeutet, dass, wenn der GPS Empfänger an meinem Mega8 hängt,
> kein Stopbit übertragen wird?

Naja, der wird das Stopbit schon richtig übertragen, aber die
Abtastung deines ATmega8 läuft in der Zeit so weit aus dem Ruder,
dass er das Stopbit nicht zu dem Zeitpunkt sieht, da er es erwartet.
Das riecht alles nach Taktfrequenzproblemen.

Da du einen ATmega8 hast (und keinen ATmega88), hast du noch kein
CKOUT, mit dem du den internen Takt überprüfen kannst.  Ein einfacher
Trick ist aber, einen Timer im CTC-Modus zu betreiben und auf "toggle
OCx on compare match" zu stellen.  Das entsprechende OCRx setzt du
auf 0, den Vorteiler auf 1:1, dann hast du am OCx-Ausgang genau die
halbe CPU-Frequenz, die du dann messen kannst.

Ok, habe nun mal direkt nach dem Quarzoszillator mit meinem Oszilloskop 
gemessen, und da wurde mir eine fast saubere Rechteckschwingung(?) 
angezeigt. Der Oszillator funktioniert also....

Wie du das mit dem Timer meinst, habe ich nicht verstanden, könntest du 
eventuell ein Codebeispiel posten?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

Steffen O. wrote:

> Ok, habe nun mal direkt nach dem Quarzoszillator mit meinem Oszilloskop
> gemessen, und da wurde mir eine fast saubere Rechteckschwingung(?)
> angezeigt. Der Oszillator funktioniert also....

Das bedeutet noch lange nicht, dass der Controller sich auch für
diesen Takt interessiert...  (Du schreibst ,Quarzoszillator', daher
nehme ich mal an, du hast einen externen Oszillator und nicht nur
einen Quarz direkt am Controller.)

> Wie du das mit dem Timer meinst, habe ich nicht verstanden, könntest du
> eventuell ein Codebeispiel posten?

Naja, richtig ,auf Lager' habe ich die nicht, das bisschen hacke ich
immer live zusammen.  OK, dann mach ich mal deine Hausaufgaben:

1

#include <avr/io.h>

2

3

int

4

main(void)

5

{

6

  TCCR2 = _BV(WGM21) | _BV(COM20) | _BV(CS20);

7

  OCR2 = 0;

8

  DDRB = _BV(3);

9

  for (;;) /* wait */;

10

  return 0;

11

}

Das sollte an PB3 den halben CPU-Takt ausgeben.

Jörg Wunsch wrote:
> Steffen O. wrote:
>
>> Ok, habe nun mal direkt nach dem Quarzoszillator mit meinem Oszilloskop
>> gemessen, und da wurde mir eine fast saubere Rechteckschwingung(?)
>> angezeigt. Der Oszillator funktioniert also....
>
> Das bedeutet noch lange nicht, dass der Controller sich auch für
> diesen Takt interessiert...  (Du schreibst ,Quarzoszillator', daher
> nehme ich mal an, du hast einen externen Oszillator und nicht nur
> einen Quarz direkt am Controller.)
 Ja, genau, ich habe einen externen Oszillator 
(http://www.reichelt.de/?;ACTION=3;LA=4;GROUP=B42;GROUPID=3174;ARTICLE=13706;START=0;SORT=preis;OFFSET=16;SID=27P4F8uKwQARsAAF3XFT4edb3e29a5ceb6edbe4961c07fe3e72a3)

>> Wie du das mit dem Timer meinst, habe ich nicht verstanden, könntest du
>> eventuell ein Codebeispiel posten?
>
> Naja, richtig ,auf Lager' habe ich die nicht, das bisschen hacke ich
> immer live zusammen.  OK, dann mach ich mal deine Hausaufgaben:
Danke ;-)

>

1

> #include <avr/io.h>

2

> 

3

> int

4

> main(void)

5

> {

6

>   TCCR2 = _BV(WGM21) | _BV(COM20) | _BV(CS20);

7

>   OCR2 = 0;

8

>   DDRB = _BV(3);

9

>   for (;;) /* wait */;

10

>   return 0;

11

> }

12

>

>
> Das sollte an PB3 den halben CPU-Takt ausgeben.

Ja, macht der Code auch. An PB3 liegt der halbe Takt an, wie den, den 
ich am Oszillator messe, also der CPU- Takt.

Der Takt scheint also zu stimmen, woran kanns dann noch liegen? Soll ich 
nun mal einen Baudratenquarz kaufen, und mal so einen testen?

Vielen Dank schon einmal im Voraus.
Gruß, Steffen

>An PB3 liegt der halbe Takt an, wie den, den
>ich am Oszillator messe, also der CPU- Takt

Und mit welcher Frequenz? Was sagt der Oszi bezüglich der Zeit?