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
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?
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
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?
A. S. schrieb:> Könntest Du einmal den Signalpfad für RX und TX skizzieren?
Schon passiert
Markus E. schrieb:> uart.PNGMarkus 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?
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.
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.
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!
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.
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
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
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.
lvlshft.PNG
(13 KB)
uart.PNG
(3,4 KB)
