Mega8 - RS232 super beim Mega16 bescheiden - warum???

[m@rkus33]

Hallo Leute,

ich brauch mal Eure Hilfe.

Ich habe auf einem Board einen Mega8 laufen auf dem anderen einen Mega16.

Die beiden erledigen eine identische Anwendung. Software (bis auf die Pinouts, Fuesbits usw.) auch identisch, Hardware von der Beschaltung auch.

Mein Problem:

Ich habe beim Mega8 eine super Funktionierende RS232 von der Qualität, beim Mega16 aber eine sehr bescheidene. Viele Fehler, Aussetzer usw.

Taktung Mega16 mit 3,686 MHz Quarz, 22pF, Baudrate 4800,
Taktung Mega8 mit 12 Mhz Quarz, 22pF, Baudrate 4800,

Woran kann die besch... Qualität beim Mega16 liegen? Ich würde auch ganz gerne die Taktung auf die max. von 8 Mhz (ist ein "L" Modell) erhöhen. Nur was nehme ich dann am besten für ein Quarz, damit die RS232 gescheit funktioniert?

Das komische ist, je weniger Bytes ich über die RS232 zum Mega16 schicke, desto weniger Fehler werden produziert.

Ohne Fehler läuft es mit einem Starbyte, 5 Datenbytes, Checksum

wenn ich aber: Starbyte , 6 Datenbytes, Checksum übertrage funktioniert es kaum noch und eine sehr hohe Fehlerrate habe ich zur Folge.

Was kann das sein?

[johannuhrmann]

Hi Markus,

wenn die Fehlerrate mit der Länge des Datenworts (Startbit + Daten + Partity + Stopbits)
zunimmt, dann ist das Problem häufig, dass die Baudrate nicht exakt stimmt.
Laut Datenblatt muss für den ATMega16 bei 3.6864MHz ein UBRR von 47 eingestellt
werden für 4800 Baud. Vermutlich liegt da der Fehler.

Hintergrund des ganzen ist die Synchronisierung auf Empfängerseite:
Empfängt der Empfänger die erste Flanke des Startbits, dann synchronisiert er
seinen Abtasttakt. Stimmen die Baudraten beim Sender und Empfänger exakt überein,
dann wird jedes Bit genau "in der Mitte" vom Empfänger abgetastet und gelesen.
Sind die Baudraten leicht verschieden, dann kann es passieren, dass der Empfänger das
erste Datenbit "ziemlich in der Mitte", das zweite "einigermaßen in der Mitte",
das dritte "gerade noch so eben am Rand" erwischt und das vierte überspringt...

Der Fehler wird also mit der Länge des Datenworts immer größer. Vermutlich
funktioniert es deshalb bei Dir noch bei 5 Datenbits aber nicht bei 8 Datenbits.

Grüße,

Hans

[m@rkus33]

Hallo Hans,

danke für den Tip. Jetzt stehe ich vor der Frage:

Entweder gleich eine andere bessere (schnelleres Quarz) Taktung oder am UBRR schrauben. Das Problem: Ich weis nicht, wie ich das in Bascom verstellen kann.

Hast Du Erfahrungen, bei welchen Taktungen der Mega16 die stabilste Baudrate von 4800 hat? Die Baudrate kann ich leider nicht verändern, da das alles auch noch über Funk läuft.

Gruß
Markus

[linux_80]

Hallo,
mit 7,3728 MHz liegt man am besten, ist nur knapp unter den erlaubten 8 und bringts genau auf 4800bps.
mit 3,6864MHz sollte es aber genauso klappen, error 0% !
Siehe Datenblatt des M8 S.157.

[m@rkus33]

Hallo Linux80

danke für Dein Posting.

Hmm... es ist komisch, das der Mega8 in der Anwendung super!! läuft, der Mega16 aber enorme Probleme bei der Kommunikation bringt.

Bei der 3,6864MHz Taktung habe ich komischerweise einmal selten Fehler, schalte ich aber aus und wieder an braucht er teilweise 10 Sek. bis er die Daten auswerten kann. Dann ein anderes mal wertet er die Daten sofort aus, bringt aber im Betrieb alle paar Sekunden Fehler. Als ob er aus der Taktung laufen würde oder er sich schwer tut "einzurasten".

Ist beim 16er irgendetwas besonders zu beachten, das beim Mega8 nicht auffällt? Evtl. stimmt was mit der Abstimmung der Kondenstoren und Quarz nicht. Ich habe am Quarz 22pF Kondensatoren drin. Beim Mega8 funktioniert das bis rauf auf 12 Mhz sehr gut.

Gruß
Markus

Gruß
Markus

[uwegw]

Bei 3,686 MHz wie schon gesagt 0% Abweichung, bei 12 Mhz aber auch nur 0,16%. Macht normalerweise keine Probleme.

Die 22pF am Quarz haben keinen Einfluss auf die genaue Taktfrequenz. Sie sorgen nur dafür, dass der Quarz überhaupt anfängt zu schwingen.

[Kaiser-F]

Hi, ich arbeite schon immer mit ATMega32, und es gab nie Probleme.

Wie schon erwähnt sollte man ein Quarz nehmen, welches sozusagen eine im Binärsystem "gerade" Zahl ist.

7372800 / 1024 = 7200
dagegen:
8000000 / 1024 = 7812,5

Daraus resultieren die Fehler. Weil die Baudrate nicht exakt erreicht werden kann( bei Dezimal "geraden" zahlen). Irgendwann tritt eine verschiebung auf und es werden Bits nicht richtig übertragen.

Jeweils auf der Letzten Seite im UART-Kapitel in den AVR-Datenblättern stehen viele Frequenzen und wie oft bei diesen Fehler auftreten in %.

Wie gesagt, man sollte 7,3728MHz nehmen, oder sowas.... oder 14,7456MHz.... Lohnt sich, Man tut sich allgemein dann beim Einstellen der Timer leichter.

[darwin.nuernberg]

Ich hatte nie Probleme weder mit einem M8, M16 nich mit M32 und auch mit 8MHz oder 16MHz.

Außer ich hatte im Bascom oder am PC die falsche Baudrate eingestellt oder sonstigen Quatsch eingestellt welcher so eigentlich sowiso nicht hätte funktionieren können/dürfen.

Also keine Problähmä...

[Kaiser-F]

Hm, hast eigendlich recht. Weil ja mit jedem Startbit neu synchronisiert wird.

Ich lass die Baudrate vom Compiler so berechnen (C):

#define F_CPU 7372800
#define UART_BAUD_RATE 115200
#define UART_BAUD_SELECT (F_CPU/(UART_BAUD_RATE*16L)-1)

Muss also nur F_CPU anpassen und meine gewünschte Baudrate wählen.