mikrocontroller.net

Forum: Compiler & IDEs USART nur mit Delay möglich?


Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe folgende Hardware mit Atmega128 und 16000000Hz Quarz:

http://www.chip45.com/download/Savvy128_V1.3_Schematic.pdf

darauf läuft folgendes Programm:

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
UBRR0H = 0;
UBRR0L = 51;   // 51 = 19200 Baud bei FOSZ 16000000
UCSR0B = (1<<TXEN0)|(1<<RXEN0);   // transmit, receive
UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);   // 8N1

  while(1)
  {
    while (!(UCSR0A & (1<<UDRE0)));
    UDR0 = 'A';
    _delay_us(1000);
  }//while
}//main


So funktioniert es auch. Wenn ich das Delay jedoch reduziere (ab 100us) 
kommt nur noch Schrott im Terminalprogramm auf dem PC an.

Die USART Checkliste habe ich bereits durch. Leider ohne Besserung.

Hat einer eine Idee was ich machen muss, damit ich das Delay entfernen 
kann ohne das es Datenmüll gibt?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe gerade keinen 16 MHz Takt zur Hand, nur den internen RC-Oszillator
mit 8 MHz, sodass sich 9600 Bd stattdessen ergeben.  Damit funktioniert
dein Test mit und ohne delay problemlos.  Habe auch mal spaßeshalber das
Zeichen in jedem Durchlauf hochgezählt, um zu zeigen, das keins verloren
geht, auch das klappt.

Kann es sein, dass dein Terminalprogramm, UART-Treiber oder was auch
immer eine Macke hat und nicht mit "Rücken an Rücken" gelieferten
Zeichen klar kommt?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn ich nicht viel Hoffnung habe dass es hilft, aber du könntest

* auf PC Seite nachsehen, ob auch wirklich 1 Stoppbit eingestellt ist
  (diese Einstellung sollte eigentlich für den Empfänger egal sein. Auf
  der anderen Seite: Wenn der Empfänger darauf besteht, dass auch
  wirklich mindestens 2 Bitzeiten Ruhe ist ...)

* auf µC Seite auf 2 Stoppbits hoch gehen.

Die 2 Stoppbits auf µC Seite vergrößern die durch die UART sowieso 
erzwungene Pause zwischen 2 Zeichen ein klein wenig.
Normalerweise ist es kein allzugroßes Problem, wenn die Einstellungen 
nicht übereinstimmen. Benutzt der Sender ein längeres Stoppbit, so 
verschafft er damit dem Empfänger einfach nur ein wenig mehr Zeit um die 
empfangenen Bytes abzutransportieren.

Benutzt du UART/USB Wandler?

Autor: Thomas Burkhart (escamoteur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wärs mit nem Bautratenquarz?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Burkhart schrieb:
> Wie wärs mit nem Bautratenquarz?

Was sollte der denn ändern?

Wenn der Empfänger aufgrund zu großer Baudratentoleranz daneben liegt,
dann sollte er das unabhängig von der Dichte der Zeichenfolge sein.
Alles andere wäre unlogisch.  Schließlich haben wir eine asynchrone
Übertragung, bei der jedes Zeichen neu synchronisiert wird.

Nein, die Toleranz bei 16 MHz und Vorteilerwert 51 ist 0,16 %,
das ist weit im Rahmen.  Die Flanke des Stopbits kommt gerade mal
750 ns zu zeitig, bei einer Bitzeit von 52 µs.  Er benutzt ja sogar
einen Quarz, bei mir lief das Ganze mit dem unkalibrierten 8-MHz-
RC-Oszillator jedoch auf Anhieb.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Kann es sein, dass dein Terminalprogramm, UART-Treiber oder was auch
>
> immer eine Macke hat und nicht mit "Rücken an Rücken" gelieferten
>
> Zeichen klar kommt?

Danke fürs ausprobieren!
Ich hab es auch mal mit einem Notboock und anderem Terminalprogramm 
probiert, das gleiche Problem. Von daher sollte es nich am Rechner oder 
Terminalprogramm liegen.

So wie ich dich verstehe ist der Code selbst OK (?). Von daher bleibt 
noch der UART-Treiber...

Karl heinz Buchegger schrieb:
> Auch wenn ich nicht viel Hoffnung habe dass es hilft, aber du könntest ...

Ja, mit 2 Stoppbits habe ich bereits auf beiden Seiten probiert, hilft 
leider nichts. Wenn ich die Baudrate im Terminalprogramm verändere ohne 
sie im µC an zu passen bekomme ich trotzdem immer Daten rein. Allerdings 
wirres Zeug.

Thomas Burkhart schrieb:
> Wie wärs mit nem Bautratenquarz?

Ja wie schon erwähnt, der Fehler liegt jetzt schon bei geringen 0,2%. 
Sollte also reichen.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Benutzt du UART/USB Wandler?

--> No, dierekt am RS232 PC Anschluss

Falk Brunner schrieb:
> http://www.mikrocontroller.net/articles/AVR_Checkl...

Wie gesagt, hab ich leider schon durch.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fly schrieb:

> Ich hab es auch mal mit einem Notboock und anderem Terminalprogramm
> probiert, das gleiche Problem.

Das ist in der Tat seltsam.
Das verschiebt die Zuständigkeit weiter zum AVR

> Von daher sollte es nich am Rechner oder
> Terminalprogramm liegen.

Seh ich auch so.

> So wie ich dich verstehe ist der Code selbst OK (?). Von daher bleibt
> noch der UART-Treiber...

Vielleicht ein Problem beim MAX3221

Das dem die Ladungspumpe und damit die Spannungen einbrechen.
Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen 
wieder aufzubauen.

Defekter Kondensator oder so was in der Richtung.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du den es mal mit einem Loop-Back auf seiten de uC versucht?
Würde nämlich auch darafu tippen:
Karl heinz Buchegger schrieb:
> Das dem die Ladungspumpe und damit die Spannungen einbrechen.
> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen
> wieder aufzubauen.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fly schrieb:
> Wenn ich das Delay jedoch reduziere (ab 100us)
> kommt nur noch Schrott im Terminalprogramm auf dem PC an.

Was bedeutet in diesem Zusammenhang der Begriff "Schrott"?

Sind es
a) ausgelassene Zeichen
b) veränderte Zeichen

Im Fall a) kann es sein, dass senderseitig neue Zeichen zu früh in den 
USART hineingeschrieben werden. Im Fall b) handelt es sich jedoch eher 
um ein Baudratenproblem oder elektrische Störungen.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Das dem die Ladungspumpe und damit die Spannungen einbrechen.
> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen
> wieder aufzubauen.
>
> Defekter Kondensator oder so was in der Richtung.

Solch ein Ladungspumpenproblem hatte ich auch schon einmal bei den 
Steuerleitungen. Wenn nämlich zwei Ausgänge gegeneinander geschaltet 
sind, bricht die Spannungsversorgung des gesamten Bausteins zusammen, 
selbst wenn die betreffenden Steuerleitungen nicht verwendet werden! 
Dies kann hier wahlweise auf der PC- oder AVR-Seite der Fall sein.

Um solch einen Fehler auszuschließen bzw. zu diagnostizieren, empfehle 
ich für einen Test, eine Verbindung mit nur zwei Leitungen (GND, TxD) 
vorzunehmen. Es sollten auch an den Steckern keine Brücken für die 
Handshake-Leitungen vorhanden sein.

Ggf. mit dem Oszilloskop die Datenleitung(en) auf ungültige 
Spannungspegel hin überprüfen; Ladungspumpenausgang auf 
Spannungseinbrüche überwachen.

Oder kann es sein, dass der Pegelwandler für 5V Versorgungsspannung 
spezifiziert ist, aber mit 3V betrieben wird? Das wäre auch solch ein 
Klassiker...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht hats wer im Kopf. Bin jetzt zu faul das Datenblatt zu suchen.

Stimmt das wirklich, dass am MAX3221 die Kondensatoren 100n, 470n, 470n, 
470n sind?
Kommt mir komisch vor, dass da einer wertmässig aus der Reihe tanzt.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mal so frei [1]:
Figure 6. Typical Operating Circuit and Capacitor Values
Vcc         C1      C2/C3/C4
3.3V ±0.3V  0.1μF   0.1μF
5V ±0.5V    0.047μF 0.33μF
3V to 5.5V  0.1μF   0.47μF

[1] Aus dem Datenblatt, das wo hier im Forum automagisch verlinkt wird: 
http://focus.ti.com/lit/ds/symlink/max3221.pdf

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich habe auch gerade ins Datenblatt geschaut, jedoch in das von 
Maxim. Dort steht wiederum explizit:
"However, do not increase C1 without also increasing the values of C2, 
C3, and C4 to maintain the proper ratios (C1 to the other capacitors)"

Die von g457 aufgeführten Tabellenwerte werden auch von Maxim genannt:
http://datasheets.maxim-ic.com/en/ds/MAX3221-MAX3243.pdf

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, Ok

Also das stimmt.
Kam mir nur seltsam vor, weil ich eigentlich was Symetrisches erwartet 
hätte.
Gut, dann kanns das auch nicht sein.

Was aber nicht heißt, dass die Hypothese 'MAX' damit vom Tisch wäre. Den 
Loopback Test würde ich immer noch machen. Aber nicht mit der Tastatur, 
das gibt wieder delays, sondern mit einem Textfile drüber jodeln.

PC -> Kabel -> MAX -> Brücke -> MAX -> Kabel -> PC

Wenn das Ergebnis vernünftig aussieht, würde ich den MAX von der 
Anklagebank runterlassen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fly schrieb:
> So wie ich dich verstehe ist der Code selbst OK (?).

So sehe ich das auch.

Ich hab's übrigens mit einem STK500+501 und dem Pegelwandler auf dem
STK500 getestet.  Gegenseite war Hardware-RS-232 (also kein USB)
und Kermit unter Linux.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen
> wieder aufzubauen.

--> nein läuft volle lotte durch


Läubi .. schrieb:
> Hast du den es mal mit einem Loop-Back auf seiten de uC versucht?

--> nein noch nicht, gute Idee mache ich. Und am besten auch die 
Gegenprobe mit PC.


Andreas Schweigstill schrieb:
> Was bedeutet in diesem Zusammenhang der Begriff "Schrott"?

--> c) Ich lasse den Controller laufen und schalte danach das 
Terminalprogramm ein. Jetzt kommt z.B.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAAAAAA....
und nach vielleicht 20 sec. kommt
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP 
PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP...
Dann noch was anderes und so weiter.
Jedesmal wenn ich das Terminalprogramm neu an mache kommt ein belibiges 
Zeichen (A und P bevorzugt) das dann eine Weile wiederholt wird.


Andreas Schweigstill schrieb:
> Um solch einen Fehler auszuschließen bzw. zu diagnostizieren, empfehle
> ich für einen Test, eine Verbindung mit nur zwei Leitungen (GND, TxD)
> vorzunehmen. Es sollten auch an den Steckern keine Brücken für die
> Handshake-Leitungen vorhanden sein.

OK, muss ich prüfen, bin zur zeit nicht am Platz...

Andreas Schweigstill schrieb:
> Oder kann es sein, dass der Pegelwandler für 5V Versorgungsspannung
> spezifiziert ist, aber mit 3V betrieben wird? Das wäre auch solch ein
> Klassiker...
Eingestellt ist 5V, messe es aber lieber nochmal nach...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fly schrieb:
> Karl heinz Buchegger schrieb:
>> Machst du Pausen dazwischen, gibst du dem Teil Zeit, die Spannungen
>> wieder aufzubauen.
>
> --> nein läuft volle lotte durch

Genau das meine ich ja.

lässt du full Speed laufen, hast du Fehler
Gibst du etwas Erholungszeit, hast du keine Fehler.

Das kann ein Zusammenhang sein, muss allerdings nicht. Einen Test wäre 
es mir aber wert.


> --> c) Ich lasse den Controller laufen und schalte danach das
> Terminalprogramm ein.

Schlechte Strategie!

Immer zuerst den Empfänger anmachen. Der Empfänger muss sich auf das 
Startbit synchronisieren. Der kann aber bei dem ganzen 0/1 Gezappel auf 
der Leitung nicht wissen, welche Flanke denn nun das Startbit ist. Also 
nimmt er die nächst beste (erste) Flanke als Startbit und tastet ab dort 
im Zeitraster ab. Da die Flanke, die der PC als Startbit annimmt aber 
nicht wirklich das Startbit sein muss sondern einfach nur eine Flanke 
aus irgendeinem Datenbit, steigt die PC-UART da 'schräg' in die 
Übertragung ein.
Gibst du ein wenig Zeit zwischen den Bytes, dann schafft es die 
Empfängeruart sich in dieser Pause korrekt auf das nächste Startbit 
einzuklinken und ab dann läuft alles richtig.

-> auf eine mit Full-Speed laufende UART Verbindung kann man sich nicht 
fehlerfrei einklinken. Die 100%-ige Synchronisierung findet erst mit der 
ersten Übertragungspause statt, die länger als die Übertragungszeit 
eines Bytes ist.


Edit: Hatte nicht fertig gelesen
> Jetzt kommt z.B. AAAAAAAAAAAAAAAAAA
Du kriegst ja das korrekte A, das dann nach einiger Zeit einem falschen 
Zeichen Platz macht. Das würde wieder darauf hindeuten, dass das Timing 
nicht stimmmt.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Fly schrieb:
> Jedesmal wenn ich das Terminalprogramm neu an mache kommt ein belibiges
> Zeichen (A und P bevorzugt) das dann eine Weile wiederholt wird.

Fällt dir an dem Bild was auf?

Je nachdem, zu welchem Zeitpunkt er den Empfänger einschaltet,
interpretiert er die gleiche Bitfolge mal als A, mal als P.

Wenn der Empfänger aber die ganze Zeit aktiv ist und sich trotzdem
verzählt, dann hat er irgendwie ein Synchronisationsproblem.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
!!ES GEHT!!

Ich mag fast garnicht sagen wiso. Es lag genau daran:

Karl heinz Buchegger schrieb:
>> --> c) Ich lasse den Controller laufen und schalte danach das
>
>> Terminalprogramm ein.
>
>
>
> Schlechte Strategie!
>
>
>
> Immer zuerst den Empfänger anmachen. Der Empfänger muss sich auf das
>
> Startbit synchronisieren. Der kann aber bei dem ganzen 0/1 Gezappel auf
>
> der Leitung nicht wissen, welche Flanke denn nun das Startbit ist. Also
>
> nimmt er die nächst beste (erste) Flanke als Startbit und tastet ab dort
>
> im Zeitraster ab. Da die Flanke, die der PC als Startbit annimmt aber
>
> nicht wirklich das Startbit sein muss sondern einfach nur eine Flanke
>
> aus irgendeinem Datenbit, steigt die PC-UART da 'schräg' in die
>
> Übertragung ein.
>
> Gibst du ein wenig Zeit zwischen den Bytes, dann schafft es die
>
> Empfängeruart sich in dieser Pause korrekt auf das nächste Startbit
>
> einzuklinken und ab dann läuft alles richtig.


Ich danke euch!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Fly (Gast)

>!!ES GEHT!!

Schön.

>Ich mag fast garnicht sagen wiso. Es lag genau daran:

http://www.mikrocontroller.net/articles/AVR-Tutori...

Wissen heißt wissen wo es steht.

MFG
Falk

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> http://www.mikrocontroller.net/articles/AVR-Tutori...
> Wissen heißt wissen wo es steht.


Asche auf mein Haupt, das habe ich überlesen.

Autor: Fly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> http://www.mikrocontroller.net/articles/AVR-Tutori...
> Wissen heißt wissen wo es steht.


Asche auf mein Haupt, dass habe ich überlesen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.