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
:
Bearbeitet durch User
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?
Könntest Du einmal den Signalpfad für RX und TX skizzieren?
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?
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.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?
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
:
Bearbeitet durch User
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.