RS232 - Emfpang Daten klappt nicht

[Olaf R. (gruser)]

Hallo,

ich möchte von einem PIC-Prozessor Daten auf einen PC übertragen. Den 
PIC habe ich testweise so programmiert dass er immer wieder den Wert 
01011101 sendet. Leider kann ich am PC aber nix empfangen, anbei das 
Bild vom Speicheroszilloskop, vielleicht habt ihr ja Ideen.

Danke und Gruß
Olaf

[Falk B. (falk)]

http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Was ist das für ein Protokoll???
RS232 kann es eigentlich nicht sein, denn
- die Baudrate ist 6 kBit/s (6 Bit/ms),
- es gibt kein (erkennbares) Start- oder Stop-Bit,
- der Pegel der Leitung wechselt irgendwann beliebig zwischen hi und lo

Ist das ein Soft-UART?

Wenn du am D-Sub gemessen hast, sollte deine Hardware i.O. sein,
denn die Pegel (+-8V) passen schon mal...

[Stefan E. (sternst)]

Lothar Miller wrote:

> - es gibt kein (erkennbares) Start- oder Stop-Bit,

Also ich erkenne sie schon. Startbit, Datum (mit LSB-First) und 
mindestens ein Stopbit.

> - der Pegel der Leitung wechselt irgendwann beliebig zwischen hi und lo

Sieht nach einem vorangehenden Break aus.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Stefan Ernst wrote:
> Also ich erkenne sie schon. Startbit, Datum (mit LSB-First) und
> mindestens ein Stopbit.
Danke für die Brille, jetzt sehe ich sie auch...

>Sieht nach einem vorangehenden Break aus.
Am PC wird da aber Käse angezeigt, oder?

>Leider kann ich am PC aber nix empfangen...
Welches Terminalprogramm verwendest du?
Irgendein Müll sollte da aber schon kommen.

[Stefan E. (sternst)]

Lothar Miller wrote:

>>Sieht nach einem vorangehenden Break aus.
> Am PC wird da aber Käse angezeigt, oder?

Also eigentlich sollte das auch als Break erkannt werden, oder zumindest 
als Frame-Error.

> Irgendein Müll sollte da aber schon kommen.

Na ja, er sendet ja immer wieder das selbe Byte. Wenn die Baudraten 
ungünstig differieren, kann das auf PC-Seite auch immer nur ein weiterer 
Frame-Error sein.

[Ralph (Gast)]

Die meisten Terminal programme interpetieren die Datenbytes als ASCII 
code, und zeigen nur darstellbare Zeichen an.

Verwende zum testen einen ASCII code für einen Buchstaben zb 65d ; 41h; 
1000001b ; für den Buchstaben "A".
Bekommst du auch hier keine Anzeigen, dann prüf alle Einstellungen, wie 
Baudrate, Anzahl der Bits, Start/Stopbits nach. Und das prüfen auf PIC 
und PC.

Willst du Datenprotokolle aus deinem PIC auf den PC übetragen, hast du 2 
Möglichkeiten.
1. Du verwendest am PC ein Programm das die Rohdaten aufzeichnet und 
KEINE Terminal software
2. du wandelst jeden Datenwert in eine ASCII Zeichenfolge um, bevor du 
sie vom PIC zum PC sendest. zb du hast im PIC die Zahl 255 zu 
übertragen, dann sendest du an den PC 3 Byte. 1. Byte 32h "2"; 2. Byte 
35h "5"; 3. Byte 35h "5". Ergibt im Terminalprogramm die Anzeige 255.

Terminalprogramme zeigen NUR ASCII Zeichen an, es sei denn sie haben 
einen Rohdatenmodus

[Stefan E. (sternst)]

Ralph wrote:
> Die meisten Terminal programme interpetieren die Datenbytes als ASCII
> code, und zeigen nur darstellbare Zeichen an.
>
> Verwende zum testen einen ASCII code für einen Buchstaben zb 65d ; 41h;
> 1000001b ; für den Buchstaben "A".

01011101 ist ein darstellbares ASCII-Zeichen, nämlich ']'.

[Ralph (Gast)]

Das "]" gehört zum erweiterten ASCII Satz, und wird nicht unbedingt 
überall als ASCII Zeichen akzeptiert.

Besser sind hier nur Zahlen und Buchstaben zu verwenden.
Deutsche Umlaute sind zwar auch Buchstaben gehören aber ebenfalls zum 
erweiterten ASCII Satz.

0Ah ist ebenfalls ein gültiger ASCII Code, nur zu sehen ist da nicht 
viel.

[Simon K. (simon)]

Ist der erweiterte ASCII-Zeichensatz nicht über 127 angesiedelt? ...

[Ralph (Gast)]

Nicht ganz.

Der erste Version hatte nur die Buchstaben, Zahlen, einige Steuerzeichen 
( Stichwort Fernschreiben).
Dann wurde die ersten 7 Bit, also 0 bis 127 aufgefüllt, und dann später 
nochmal die Zeichen 128 bis 255

[Stefan E. (sternst)]

Ralph wrote:
> Das "]" gehört zum erweiterten ASCII Satz, und wird nicht unbedingt
> überall als ASCII Zeichen akzeptiert.

Nein, 93 (dezimal) wird immer als ASCII-Zeichen interpretiert, nur auf 
ganz alten Gurken (z.B. Apple II) kann es passieren, dass dann ein 'Ü' 
(oder anderes nationales Sonderzeichen) zum Vorschein kommt und kein 
']'.
Und zum "erweiterten"-ASCII gehört es aber auf keinen Fall.

[Stefan E. (sternst)]

Ralph wrote:

> Der erste Version hatte nur die Buchstaben, Zahlen, einige Steuerzeichen
> ( Stichwort Fernschreiben).
> Dann wurde die ersten 7 Bit, also 0 bis 127 aufgefüllt, und dann später
> nochmal die Zeichen 128 bis 255

Ach, dann sollte man zum Testen also auch die kleinen Buchstaben nicht 
verwenden, die sind nämlich auch erst später dazu gekommen und gehören 
damit wohl auch zum "erweiterten" ASCII.

[Ralph (Gast)]

Die Frage ist halt welches ASCII Codeversion vom verwendeten Terminal 
Programm mit den gewählten Einstellungen verwendet wird.

Es ist eben möglich das eine solche Kombination aus Programm und 
Einstellung da ist.

[Olaf R. (gruser)]

Sorry, meine Angaben waren ein wenig knapp. Meine Signalstrecke sieht so 
aus:

IC (sendet Daten) -> MAX485-Baustein -> 485-Bus -> MAX485-Baustein -> 
MAX232-Baustein -> PC

Und gemessen habe ich was am Kabel zum PC ankommt, also im Prinzip ein 
RS232-Signal (RX gegen Masse gemessen).

Die Übertragungsrate ist 57.600 Bit/s, also rund 17µs pro Bit.

Mein COM-Terminal zeigt nix an, auch keine blödsinnigen Werte, ich 
fürchte das Ding ist einfach überfordert weil es mit Werten kurz 
hintereinander erschossen wird. Ich versuche einmal die Pausen zwischen 
den einzelnen Bytes zu erhöhen (ca. 1 sek) vielleicht wird dann etwas 
angezeigt.

Ich melde mich noch mal wenn ich den IC umprogrammiert habe.

So long ;)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Zum Bild:
Offenbar gilt die 1ms nicht pro div sondern für die gesamte Breite.
Dann stimmt auch deine Baudrate.

>Mein COM-Terminal zeigt nix an...
Dann ist da was faul. Probier mal ein Einfachst-Terminal z.B. vom Typ 
OC-Console. Wenn da die falsche Baudrate eingestellt ist, kommen falsche 
Zeichen, aber es kommt etwas. Und ich habe es bisher nicht geschafft, 
das Ding zu "überfahren". Wenn da ein Zeichen zu wenig protokolliert 
war, dann war auch ein Zeichen zu wenig gesendet worden.

[Stefan E. (sternst)]

> Wenn da die falsche Baudrate eingestellt ist, kommen falsche
> Zeichen, aber es kommt etwas.

Wie ich bereits sagte: nicht zwingend. Insbesondere da das MSB 0 ist, 
besteht bei geringer Abweichung der Baudrate eine gute Chance, dass der 
PC nur Frame-Errors "sieht". Aber auch bei größeren Abweichungen ist das 
natürlich möglich.

[Olaf R. (gruser)]

Einen kleinen Erfolg konnte ich heute noch verbuchen. Und zwar verwende 
ich das COM-Terminal (www.cc5x.de). Wenn ich dort auf DTR klicke und das 
Flag wieder rausnehme, dann zeigt das Ding plötzlich brav die Daten an - 
keine Fragen keine Lügen - bin aber froh es rausgefunden zu haben. Die 
Daten werden aber nur angezeigt, wenn ich den IC so programmiere dass er 
ständig auf Senden steht (TX_Enable des MAX485 immer auf "1"), ansonsten 
klappt es nicht. Der Versuch über Visual Basic die Daten einzulesen 
klappt auch noch nicht - habe mal wieder aufgezeichnet, der 
Spannungsverlauf ist seltsam verzerrt (s. Bildchen). Habt ihr auch schon 
mal so eine verwackelte Spannung gemessen?

[spess53 (Gast)]

Hi

Hast du an deinem RS232-Stecker nur TXD/RXD/GND angeschlossen?

MfG Spess

[Olaf R. (gruser)]

Als viertes noch DTR. Das brauche ich um TX_Enable zu schalten am 
MAX485. Das Problem mag vielleicht auch nur das Oszi sein, ist nicht das 
tollste Gerät. Das COM-Terminal konnte die Werte ja auch lesen... werde 
wohl noch ein wenig probieren müssen.

Grüße
Olaf