RS485 eigenartiges Verhalten

[Juergen G. (jup)]

Ich bin mit meinem Latein wieder mal am Ende und brauche eine zuendende 
Idee.

Ich habe zwei Platinen mit je einem Atmega8 die ueber den UART und RS485 
(MAX485) komunizieren sollen.

Um am Bus zu lauschen habe ich einen MAX485 an einem FT232RL.
Alles Eigenbau und sauber auf Platinen.

Das eigenartige Verhalten besteht darin, dass wenn ich je eine der 
beiden uC-Platinen ueber die MAX485/FT232RL mit dem PC verbinde, 
funktioniert die Kommunikation einwandfrei. Ich kann Befehle die die 
Atmel "verstehen" im Terminal des PC eintippen und die Atmel reagieren 
wie sie sollen.
Schalte ich nun die beiden uC-Platinen zusammen auf den Bus, und einer 
der beiden sendet einen Befehl, dann versteht der andere den Befehl und 
sendet die entsprechende Antwort, doch der Befehl sendende uC empfaengt 
andere Zeichen als der erste sendet.

zBsp:  einer sendet ein "o" dann soll der andere mit "oCCS" antworten.

der eine sendet ein "o" der andere sendet "oCCS" doch der der das o 
gesendet hat empfaengt "k0x0DM0x0D".

Schalte ich das "Lauschgeraet" mit auf den Bus, dann sehe ich im 
Terminal des PC das "o" des Befehl-sendenden uC und das "oCCS" des 
antwortenden uC

Ich habe mit und ohne Terminierung versucht, Pull-Ups an A und Pull-Down 
an B, ohne Erfolg.

Das "k0x0DM0x0D" scheinen keine Hyroglyphen zu sein, denn wenn ich im 
antwortenden uC statt "oCCS" mit "oXXX" antworte kommen andere Zeichen, 
aber immer die selben.



hat einer von Euch eine Idee wo ich suchen soll?

Ju

[Purzel H. (hacky)]

Mit einem Scope mal die Signale anschauen ? Die drei Busteilnehmer haben 
einen gemeinsamen, mit dem Kabel durchgezogenen GND ? Muessen sie 
unbedingt haben.

[Juergen G. (jup)]

@hacky

Da wird es noch verwirrender, aber der Idee werd ich mal nachgehen.


Die beiden uC-Platinen haben einen gemeinsamen GND, da eine der beiden 
durch die Stromversorgung der anderen gespeist wird.

Das "Lauschgeraet" ist nur durch A und B mit dem Bus verbunden.

Ju

[Sascha W. (sascha_w)]

ich nehme an du arbeitest im Halbduplexbetrieb?
Schaltet der zu erst sendende µC den TX-Treiber zu spät aus, so das es 
beim Senden des 2. µC auf dem Bus zu einer Kollision kommt?

Sascha

[Juergen G. (jup)]

@sascha_w

Halbduplexbetrieb, clar doch, hatte ich vergessen zu erwaehnen.

Das mit dem TX-Enable macht Sinn, das wuerde erklaeren warum andere 
Zeichen ankommen als gesendet werden.

In meinem Programm wird der TX-Enable "manuell" auf High gesetzt wenn 
Daten zu senden vorhanden sind, und der TXC Interrupt des Atmega8 setzt 
Ihn wieder auf Low.
Ich dachte das geht so.

Dann muss Ich jetzt herausfinden wer da zu spaet ist.

Ju