UART empfängt eigene gesendete Daten

[Markus E. (opc)]

Hallo zusammen,

wie im Anhang lvlshft.PNG zu sehen, betreibe ich einen Raspberry Pi 4 
als "Bus-Master" an einem UART-"Bus" (s. uart.PNG) (den Aufbau habe ich 
von Falk hier aus dem Forum).

Es gibt im aktuellen Aufbau an dem UART-Bus nur einen Slave (Mega8), 
welcher auf die Datenübertragung vom RPi von zwei Bytes in Folge eine 
DEVICE_ID als seine eigene interpretiert und anhand des zweiten Bytes 
(SENSOR_ID) eine Sensormessung durchführt und die Ergebnisse an den 
Raspberry Pi zurückliefert:

Beispiel:
RPi --> Slave:
Byte 1 | Byte 2
   2       1

Antwort Slave --> RPi:
  DEV     SENS BLOCK_LEN   DATA     CRC_L  CRC_H
   2   |   1   |   1   |   255   |   0   | 255  |

Nun zum Problem:
Sind der RPi und der Slave (ein Mega8 Controller), wie in den Anhängen 
miteinander über den UART-Bus verbunden, so führt das Absetzen der 
beiden Request-Bytes vom RPi an den Slave dazu, dass am RPi die beiden 
Bytes direkt wieder im Eingangspuffer landen und vom RPi RX gelesen 
werden.
Der Slave antwortet darauf hin mit seinem Response, dessen Daten nun 
zusätzlich am RPi ankommen. So sieht die ungewünschte Datenübertragung 
in der Antwort des Slaves am RPi also so aus:

2, 1, 2, 1, 1, 255, 0, 255

>> Verbinde ich die RX und TX Leitungen von RPi und Slave direkt miteinandern 
(schon mit Levelshifter am RPi), so werden die ersten beiden ausgegebenen Bytes am 
RPi nicht direkt eingelesen.

Ich kann mir das Verhalten leider nicht erklären und suche an der Stelle 
Hilfe. Ich bin für jeden Tipp dankbar!

LG und einen schönen Sonntag,
Markus

[Christian K. (the_kirsch)]

Nochmal zum Aufbau
Du hast ein "UART-Bus"?

Wie meinst du das. Du hast N-Teilnehmer, bei dem der Tx vom Vordermann 
mit dem Rx zum Nachfolgendem verbunden ist. Und der letzte Tx ist wieder 
mit dem Rx vom Master verbunden.

Und jeder Teilnehmer leitet die empfangenden Daten 1 zu 1 weiter, es sei 
den er wird durch seine ID angesprochen?

[A. S. (Gast)]

Könntest Du einmal den Signalpfad für RX und TX skizzieren?

[Carl D. (jcw2)]

Alle TXe senden per Dioden-AND auf die selbe Leitung und alle RXe hören 
diese ab. Warum sollte das selbstgesendete nicht gehört werden?

[bronko (Gast)]

Hi Markus,

leider sind die Schaltpläne etwas unklar.

Welchen Level-Shifter verwendest du denn und was ist der Kasten im 
unteren Schaltplan? Was machen die Dioden da?

Vlt. ist der UART des RPi mit sowas wie Loopback konfiguriert.

Tritt das von dir beschriebene Verhalten bei jeder Übertragung auf, oder 
nur bei der ersten Übertragung?

Etwas Code wäre auch hilfreich.

Was passiert, wenn du vom Slave unaufgefordert an den RPi sendest?

Grüße

[Markus E. (opc)]

Christian K. schrieb:
> Nochmal zum Aufbau
> Du hast ein "UART-Bus"?
>
> Wie meinst du das. Du hast N-Teilnehmer, bei dem der Tx vom Vordermann
> mit dem Rx zum Nachfolgendem verbunden ist. Und der letzte Tx ist wieder
> mit dem Rx vom Master verbunden.
>
> Und jeder Teilnehmer leitet die empfangenden Daten 1 zu 1 weiter, es sei
> den er wird durch seine ID angesprochen?

Die RX aller Teilnehmer sind miteinander verbunden. Und die TX mit 
Dioden daran angekoppelt (s. Anhang).
Es gibt einen Bus-Master, den Raspberry Pi, welcher zwei Bytes auf den 
Bus legt (darunter ein DEVICE_ID Byte) und der entsprechende Slave der 
sich anhand der DEVICE_ID angesprochen fühlt, antwortet. Es bekommen 
also alle Slaves die Daten des Master und ein Slave antwortet.

A. S. schrieb:
> Könntest Du einmal den Signalpfad für RX und TX skizzieren?

Also im Anhang hab kann man die Pfade nachvollziehen. Habe auch Labels 
verwendet um von Skizze 1 (lvlshft.PNG) zu Skizze 2 (uart.PNG) 
gedanklich überspringen zu können. Oder was meinst du?

[Wolfgang (Gast)]

A. S. schrieb:
> Könntest Du einmal den Signalpfad für RX und TX skizzieren?

Schon passiert

Markus E. schrieb:
> uart.PNG

Markus E. schrieb:
> Ich kann mir das Verhalten leider nicht erklären und suche an der Stelle
> Hilfe. Ich bin für jeden Tipp dankbar!

So wie dein Bus aufgebaut ist, landet alles, was auf der Sammelleitung 
gesendet wird, bei all deinen Empfänger. Worüber wunderst du dich jetzt?

[Mario M. (thelonging)]

Markus E. schrieb:
> Der Slave antwortet darauf hin mit seinem Response, dessen Daten nun
> zusätzlich am RPi ankommen.

Du musst beim Empfangen so viele Bytes ignorieren, d.h. verwerfen, wie 
Du vorher gesendet hast.

Markus E. schrieb:
> Verbinde ich die RX und TX Leitungen von RPi und Slave direkt miteinandern
> (schon mit Levelshifter am RPi), so werden die ersten beiden
> ausgegebenen Bytes am
> RPi nicht direkt eingelesen.

Ist ja logisch, nur der Atmega hört mit.

[Carl D. (jcw2)]

Markus E. schrieb:
> Christian K. schrieb:
>> Nochmal zum Aufbau
>> Du hast ein "UART-Bus"?
>>
>> Wie meinst du das. Du hast N-Teilnehmer, bei dem der Tx vom Vordermann
>> mit dem Rx zum Nachfolgendem verbunden ist. Und der letzte Tx ist wieder
>> mit dem Rx vom Master verbunden.
>>
>> Und jeder Teilnehmer leitet die empfangenden Daten 1 zu 1 weiter, es sei
>> den er wird durch seine ID angesprochen?
>
> Die RX aller Teilnehmer sind miteinander verbunden. Und die TX mit
> Dioden daran angekoppelt (s. Anhang).
> Es gibt einen Bus-Master, den Raspberry Pi, welcher zwei Bytes auf den
> Bus legt (darunter ein DEVICE_ID Byte) und der entsprechende Slave der
> sich anhand der DEVICE_ID angesprochen fühlt, antwortet. Es bekommen
> also alle Slaves die Daten des Master und ein Slave antwortet.

Der Master bekommt seine eigene Anfrage aber auch!

was aber nicht schlimm sein muß, denn er erfährt damit, daß seine 
Anfrage unverfälscht auf dem Bus lag. Nur müßte eine "Message" eben 
irgend eine Art von Ende haben, um sie von der nächsten Message, der 
Antwort, unterscheiden zu können.

[Markus E. (opc)]

Carl D. schrieb:
> Der Master bekommt seine eigene Anfrage aber auch!
>
> was aber nicht schlimm sein muß, denn er erfährt damit, daß seine
> Anfrage unverfälscht auf dem Bus lag. Nur müßte eine "Message" eben
> irgend eine Art von Ende haben, um sie von der nächsten Message, der
> Antwort, unterscheiden zu können.

Ok jetzt bin ich runter vom Schlauch. Ihr habt natürlich Recht, dass das 
TX des Master auch gleich zum RX wird was die Daten angeht.

Danke für euere Zeit!

[A. S. (Gast)]

Wolfgang schrieb:
> Schon passiert

Eben nicht. Das ist ein aufwändigerVerdrahtungsplan mit nichtssagenden 
Symbolen. Und das zweite Bild nur durch raten interpretierbar.

Wenn der TO sich das aufmalt, hatte er die Verdrahtung auch verstanden. 
Sonst wäre die Gefahr, dass alles irgendwie ganz anders gemeint war. 
Z.b. der levelshifter oder der R, der irgendwo drangemalt ist, ... Ohne 
Kontakt.

[Pandur S. (jetztnicht)]

Das Ganze ist viel einfacher. Denn die selbst gesendeten Byte sind ja 
sofort im eigenen Rx Buffer, waehrend die slaves ja erst antworten 
koennen, wenn sie die Meldung komplett empfangen haben.
Daher muss der Sender nach seinem senden erst mal den eigenen Rx Buffer 
loeschen. Man sollte sowas mit einer Zustandsmaschine loesen.

1. Senden
2. RxBuffer loeschen
3. Empfangsmode einschalten

[georg (Gast)]

A. S. schrieb:
> dass alles irgendwie ganz anders gemeint war

Ich habe ähnliche Multi-RS232-Anschlüsse schon verwendet, aber nicht so: 
Tx und Rx zu verbinden ist ziemlich unsinnig. Ich sende die Masterdaten 
(Tx) an alle Slaves, und die Antworten von den Slaves werden verodert 
(hier mit Dioden, geht auch anders) und kommen an Rx des Masters. Dann 
ist die ganze Diskussion völlig überflüssig.

Vielleicht hat das der TO auch einfach bloss falsch abgezeichnet.

Georg

[A. S. (Gast)]

georg schrieb:
> Ich sende die Masterdaten (Tx) an alle Slaves, und die Antworten von den
> Slaves werden verodert (hier mit Dioden, geht auch anders) und kommen an
> Rx des Masters. Dann ist die ganze Diskussion völlig überflüssig.
>
> Vielleicht hat das der TO auch einfach bloss falsch abgezeichnet.

Genau. Zumal er ja auch von slave spricht. Von daher wäre eine Zeichnung 
(mit echten Verbindungen) gut (oder gut gewesen). So interpretiert jeder 
was er kennt.