USART Problem beim ATMEGA88 A ( STUDIO 7 )

[wkrug]

Masseschleife gebaut (GND von beiden UARTS verbunden + gleiche Versorgung) oder Masseproblem zwischen den Boards (mal'n Oszi drangehalten)?

Stimmt, da hatte ich schon mal Probleme.
Ich werd da mal ein Laptop mit Akkubetrieb ranhängen und gucken ob es da geht.
Da komm Ich aber erst heute Abend dazu!
Die Verkabelung zu den Controllern ist Sternförmig, allerdings noch auf einem Breadboard.
Der ATMEGA 88 ist aber incl. Peripherie schon auf einer Platine.

Vergessen, den BrownOut auf unter 3,3V zu fusen (Verkabelung vom Netzteil zu den Boards sternförmig)?
Welcher "Mist" kommt denn am PC an?

Brownout ist auf unter 3,3V eingestellt.
Der ATXMEGA sendet ASCII Zeichen.
Auf dem PC ( mit Putty ) kommen immer irgendwelche Zeichen an.
Manchmal undefinierbare, manchmal ASCII Zeichen, allerdings nicht die gesendeten.
Wie gesagt, wenn Ich mich an die Verbindungsstelle zwischen den Controller anschalte scheinen die gesendeten Daten vom XMEGA in Ordnung zu sein.

Und die Empfindlichkeit auf unterschiedlich große Baudratenabweichungen sind bei unterschiedlichen Empfängern (und Baudraten) eben verschieden.

Darum auch der Quarz mit dem krummen Wert.
Denn mit dem geht es bei 115200 genau auf = Abweichung 0,0%.
Hab auch schon die 2 möglichen Einstellungen einmal mit 2x und einmal ohne ausprobiert.
Auch der XMEGA Läuft mit 115200 auch, laut Berechnung, mit 0,0% Abweichung beim internen 32MHz Generator.

[wkrug]

Hab soeben den Test mit dem Laptop im Batteriebetrieb durchgeführt.
Am Ergebnis hat sich nichts geändert.
Nach wie vor werden nach dem MEGA 88 nur kryptische Zeichen ausgegeben.
Nun hab Ich irgendwie keine Idee mehr.

[Ceos]

justiere die baudraten mal minimal, stell den baudgen mal um 1 nach oben oder unten ob das hilft, vielleicht hast du nur timing artefakte

[Holomino]

Hmm, wenn es an der Baudrate liegen würde, wäre das Ergebnis bei konstantem "U" (0x55) eher systematisch.

Bist Du sicher, dass beide Controller rundlaufen? Kannst Du z.B. durch einen kontinuierlich hochlaufenden Zähler auf dem Display oder eine blinkende LED sicherstellen, dass nicht ein Partner durch ne elektrische Störung komplett aussteigt?

[Gnom67]

Hast du es mal generell mit geringeren Baudraten probiert? Was passiert bei 9600 Baud?
Vielleicht ist deine ISR zu umfangreich, um schnell genug abgearbeitet zu werden.
Vielleicht ist der Atmega auch zu langsam... Mit welchem Takt (Quartz) läuft er ? Ist der Clock-Divider ausgeschaltet? Und wieso hast du diesen krummen Wert F_CPU 7372800?
Wieso benutzt du keinen 16 MHz-Quartz mit Divider 1 und F_CPU 16000000?

[Ceos]

wäre das Ergebnis bei konstantem "U" (0x55) eher systematisch.

Jein ... du denkst heir an einer erkennbare Schwebung oder ein Muster, aber mit hinreichend viel Zufall und Parametern wird eine schöne Schwebung/Muster auch zum RNG

Daher der Vorschlag es mal damit zu probieren (vergiss nicht auch ein verpasstes stopp-bit kann zu lustigen Daten im DATA Register führen obwohl im Status Register alle roten Lämpchen leuchten)

Ein weiterer Vorschlag wäre es Fehlerbehandlung einzubauen, also das Statusregister zu prüfen und weiterzuleiten. Vielleicht ergibt sich dann mehr Einsicht.

Abweichung 0,0%

Wir reden hier zwar von Atmega zu Atxmega, aber ich kann aus meinem Job heraus sagen, dass manchmal zu viel genauigkeit auch Grenzwertprobleme verursacht ... in unserem Fall ein Device und ein Master, bei dem das Device sich zu exakt ans minimale Timing hält und der Master, schon aus Toleranzgründen für zu lange Bytes, deswegen manchmal ein Byte schlicht verpasst (okay das ist ein Problem mit der Protokollspezifikation die eine Schnittmenge von 0uS, statt weniger uS Toleranz-Pause beim Timminig hat aber ein schönes Beispiel für Grenzwertprobleme)

[Holomino]

Dann wäre der Test denkbar schlecht gewählt. Wenn Du alle 100ms ein Byte sendest, kommt es zu keiner Schwebung, da das Startbyte keine Zweideutigkeit zulässt.
Wenn ich die Baudrate teste, fange ich eigentlich auch mit ner 0 als Testbyte an und schaue, ob's nen Frame Error gibt (Stopbit nicht erkannt, Baudrate (beim Sender) zu langsam) oder ob der empfangene Wert systematisch <>0 ist (Baudrate zu schnell).

[wkrug]

justiere die baudraten mal minimal, stell den baudgen mal um 1 nach oben oder unten ob das hilft, vielleicht hast du nur timing artefakte

Hab am ATXMEGA mal die nächst niedrigere und dann die nächst höhere Einstellung probiert - Beides Erfolglos.
Der Fehler bleibt!

EDIT!
Hab jetzt beide Controller auf 9600BAUD umgeflashed nun geht es auch mit dem PC nicht mehr.
Ich hab immer mehr den Verdacht der USART des Controllers hat ne Macke!
Ich werd morgen mal nen ATMEGA 328 rein löten.

Und wieso hast du diesen krummen Wert F_CPU 7372800?

Der Controller läuft mit 3,3V der ATMEGA88 ist da nur bis max 10MHz spezifiziert.
Der krumme Quarz Wert kommt daher, weil ich nur damit gerade Teiler für die standard Baudraten her bekomme.
Die Schaltung arbeitet als reines Display interface.
Die seriellen Daten sollen nur auf einem 128x64 Display angezeigt werden.