UART hält sein Versprechen nicht

Richtige Taktquelle gewählt?
Externer Quarz oder interner Oszillator (-> default!!)?
Welchen Takt benutzt Du?

Baudraten-Register richtig gesetzt?
Auf welchen Wert hast Du eingestellt?

Wie misst Du?
Verwendest Du die Hardware-UART oder die Software-Emulation, die BASCOM
anbietet?
Mal ein Oszilloskop an die TxD-Leitung gehängt, sind Pausen zwischen
den einzelnen Bytes zu sehen?
Könntest Du Deinen Quellcode posten?

Ein Byte dauert (1/19200)*10 Sekunden.. 1 Startbit und 1 Stopbit.

Mich würde auch interessieren, WIE du misst.. Wer misst, der misst Mist
:)

dave

Ich dachte wer mit Mist mißt, mißt mist? ;)

[es geht weiter:]
Misst Miss __ Mist? ;)

dave

Lassen wir sie erstmal antworten.. ;) bevor wir mit dem Mist weiter
machen G

dave

Also mit dem Oszilloskop in die TxD reingeschnuppert ergibt ein sehr
seltsames Muster welches sich nicht wiederholt aus einzelnen Bits und
Pausen/mehreren Bits mit dem gleichen Wert dazwischen. Scheint sich
aber nicht richtig zu wiederholen obwohl jedes Byte auf &B01010101
gesetzt ist. Jedes einzelne Bit ist 0,05 ms also 19200 kommen auch
raus. Quellcode kann ich nicht posten weil der auf dem Notebook ist und
ich meinen USB Key versaut habe. (Wilde Silvesterparty...) Er bersteht
aber zu Testzwecken aus in etwa:

Do
Portd.4 = 1  'Zur Kontrolle wie lang ein Zyklus dauert, daher meine
waitus 10    'Angaben
Portd.4 = 0
M = &B01010101 ' M isn Byte
Print M
Loop

Hi

hier ist was über die TxD Leitung fließt, wenn ich eine Pause einlege.
Wenn ich den AVR nicht warten lasse folgt exakt die gleiche Sequenz
ohne Abstand über die komplette Sendedauer. Dauert also für das Byte
01010101 insgesamt 2 ms (die Länge der Pulssequenz im Bild)

Viele Grüße,
Julia

bekommst du denn die daten sauber uebertragen??
wenn nicht such mal die einstellung, die passt

Das Oszillogramm scheint die Übertragung mehrerer Bytes darzustellen,
sieht aber sehr seltsam aus.

Statt Portd.4 auf 1 zu setzen, 10 µs zu warten und dann Portd.4 wieder
auf 0 zu setzen, könntest Du ja vor jedem Print (also vor jedem Senden
eines Bytes) den Zustand von Portd.1 invertieren.
Wenn das so erhaltene Ausgangssignal auch noch in Deinem Oszillogramm
auftauchen würde ...
Eine Zeitachse o.ä. wäre auch hilfreich.

Also die Dten werden einwandfrei übertragen nur halt zu langsam.
Aber auf das Oszillogramm kann ich mir auch keinen Reim machen. Wie
gesagt, das ist nur ein ganz simples Oszi und die Grafik ist matlab.
Wie gesagt, der pulsetrain ist 2 ms lang, ein einzelnes Bit 0,2 ms und
es wird exakt die im Bild gepostete Zeichenfolge immer und immer
wiederholt, der invertierende spike liegt genau zwischen zwei bits.
Leider kann ich schlecht noch ein Bild posten bis der Kamerakku wieder
voll ist (wie bereits erwähnt, der USB Key ist ner Party zum Opfer
gefallen).
Ich kann in dem Oszigramm absolut nicht die einzelnen Elemnte von 19200
8 Datenbits ein Stoppbit und keine Parität erkennen.

Viele Grüße,
Julia

Oh, der invertierte Spike liegt zwischen zwei "Bytes" also zwischen
exakt zwei von den Pulsetrains wie im Bild

Genau, das ist ja das setsame, denn dass sieht mir so gar nicht wie ein
"Byte" aus. Was könnte das sein?

Viele Grüße,
Julia

Hi, ich hab den Printbin Befehl ausprobiert, und der funktioniert
anscheinend für ein Byte ganz gut, auch wenn ich mir da nicht so ganz
sicher bin ob da evtl. der invertierte Wert ankommt, aber für ein
Single, Integer oder Word geht es nicht. Und wenn ich zwei Bytes
nacheinander sende geht auch nur noch Mist durch die Leitung.
Wie kann es sein dass Printbin schneller als Print ist???

Print liefert nicht ein Byte, sondern mehrere - nämlich die
ASCII-Repräsentation des (dezimal-)Wertes. Deren Länge ist vom Wert
abhängig.
Ist der Wert beispielsweise (dezimal) 65, dann liefert Print zwei Bytes
an der seriellen Schnittstelle ab, nämlich 0x36 und 0x35, '6' und
'5'.
Bei (dezimal) 204 sind's bereits drei Bytes (0x32, 0x30 und 0x34, halt
'2', '0' und '4'.

Steht hinter dem Variablennamen kein Semikolon, so wird noch ein
Zeilenvorschub angehängt, was ein oder zwei weitere Bytes (0x0d und
eventuell 0x0a) zur Folge hat.
Damit gibt

  Dim a As Byte
  A = 65
  Print A

deutlich mehr als nur ein Byte an der seriellen Schnittstelle aus,
nämlich den String 0x36, 0x35, 0x0d (0x0a).

Printbin gibt hingegen eine definierte Anzahl an Bytes, die vom Typ der
Variablen abhängt; ein Byte resultiert in einem Byte, ein Integer
resultiert in zwei Bytes und ein Long resultiert in vier Bytes.

(Das ist in der BASCOM-Dokumentation beschrieben)

Das dürfte das Phänomen klären - und darauf hinweisen, daß irgendwas
mit der Baudrate der seriellen Schnittstelle überhaupt nicht stimmt.

Vermutlich läuft der Controller mit einer anderen Taktfrequenz als
angenommen.