USART Problem beim ATMEGA88 A ( STUDIO 7 )

[oberallgeier]

.. ein Problem mit dem USART an einem ATMEGA 88A ..

Meine Probleme mit unpassenden UARTS sind (waren ?) zahllos. Irgendwann hatte ich dann entweder standardmässig oder fallweise diese Routine eingebunden und verwendet :

// ============================================================================= =
// ==  Auslesen der UBBR0-Werte und Ausgabe auf UART
// ============================================================================= =
  void UBBR0tst ( void )        // UBBR auslesen und auf UART ausgeben       <main
 {                              //
  u16   bdv, iword;             // Bauddivider und iword für Anzeige auf UART
// - - - - - - - - - - - - - - - -
//      Testweise Ausgabe des UBBR0 vorbereiten
//      Rechenformel :  ( (u16)(F_CPU / BAUD / 16 - 0.5) )
//  bdv       = (u16)(F_CPU / 115200 / 16 );
// In main: = (u16)(F_CPU / BAUD / 16 - 0.5 );
  bdv       = (u16)(F_CPU / BAUD / 16 - 0.5 );
  iword     = uniq ( bdv, (bdv >>8));
  
//      Hier anschließend  - - - f Datenaustausch

  uputs0  ("\r\tUBRR0 Rechnung: "); uputs0u ( iword ); // Anzeige UBRR0
  wms ( 1000);

  iword     = uniq ( UBRR0L, UBRR0H );
  uputs0  ("\t => Register ~L/H: "); uputs0u ( iword ); // Anzeige UBRR0
                                //
  return;       // Ende  void UBBR0tst ( void )
 }           
// ============================================================================= =

Damit hatte ich dann Tipp-, Bibliotheks-, Rundungs- und sonstige -fehler oder so entdecken können. Sieht am Terminal, nach Reset oder Kaltstart der Platine, so aus (die Farbe rot ist rein"getürkt"):

    NaCo x50 5 Mar 2019 13:20
    UART0_64 256 kBd, Datenuebertrgg ebenso
    Datenformat je 3 Bytes [ENQ][Sensora][Sensorb]
    Übertragung ca 1 x je 3 Bytes / sek

    UBRR0 Rechnung: 4     => Register ~L/H: 4

    ?Addr I²C-Dev 0xE0-0xFE; NoDev =: '-'
    I²Cdevaddr aktiv    224 0xE0
    I²Cdevaddr aktiv    226 0xE2
    --------------        I²C_look Ende @ Addr.:  254 /  0xFE

    #> ~r1n~/Tst1prsc: 1 Messung pro Sekunde
    ¼.¼.¯.¼.¼.½.!.¼.½.¼.¼.¼.¼.¼.¼.¼.¼.¼.¼.

Ne ausführlicher Anmerkung, so kurz nach dem Frühstück, geht grad nicht . . .

Nachtrag:
Warum das Ganze? Es gehört natürlich die Berechnung des Baudratenfehlers dazu - Vorsicht: manche Schritte ganzzahlig rechnen. Die Abweichung (klick) kann erheblich sein, mit meinem neuen "Scope" sieht man wie deutlich :-/ so etwas sein kann. Und die Empfindlichkeit auf unterschiedlich große Baudratenabweichungen sind bei unterschiedlichen Empfängern (und Baudraten) eben verschieden.

[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).