Guten Tag zusammen, ich habe hier ein Problem, bei dem mir bisher keiner helfen konnte. Ich habe hier 2 Bauteile einer Maschine, bei welchem eines davon der Tester ist. Damit werden aktuelle Werte ausgelesen, Ein und Ausgänge geschalten etc. Nun wird für selbige Maschine eine PC-Software benötigt, die die gleichen Funktionalitäten wie der besagte Tester hat. Das ganze ist ungefähr 10 Jahre alt, und es existiert nur in sehr begrenztem Umfang eine Dokumentation. Aus diesem Grund möchte/muss ich nun nachbauen, wie der Tester mit der Maschine kommuniziert. Das ganze dann in beliebiger Programmiersprache nachzubauen, ist nicht das Problem sondern... der Tester hat einen MAX Rs485 Transceiver und funktioniert mit einer Halb-Duplex Kommunikation (2 Drähte, + Spannungsversorgung Tester und GND). Wenn ich nun die die Kommunikation mitlese (probeweise einen billigen RS485 auf RS232 getestet), sieht man natürlich nicht welche Daten der Tester sendet, und welche die Anlage selbst. Ich suche also nach einer Möglichkeit, möglichst ohne teure Hardware, die Richtung der Daten ersichtlich zu machen (was kommt vom Tester, was von der Maschine). Kommunikation mal eben unterbrechen und die Funkion nochmal auslesen war meine Idee... leider wird das Display des Testers blank, sobald die Kommunikation unterbrochen wird. Es wird permanent gesendet. Bei RS232 wäre das ja ganz einfach, aber hier leider nicht. Zur Richtungserkennung bei Halb-Duplex RS485 finde ich leider online auch nicht viel. Habe gesucht, ob das mit einem Raspberry Pi realisierbar wäre (mit Zusatzhardware), da wir einen haben... Am Ende wird wohl auf jeden Fall ein Adapter RS485 auf USB, oder RS485 auf 232 (und dann auf USB) erforderlich sein. Hat jemand einen nützlichen Tip? Es gibt online ein Gerät, welches RS485 Richtungserkennung bietet, aber 500€ für ein solches eher privates Projekt ist eine etwas hohe Investition. Danke
Logic Analyzer an den Transceiver klemmen, da siehst Du dann neben gesendeten und empfangenen Daten auch das Ein- und Ausschalten von Treiber und Empfänger.
Richard B. schrieb: > Hat jemand einen nützlichen Tip? Setze Widerstände in die Leitung. Der Spannungsabfalls darüber verrät dir, woher die Daten kommen.
Nun, der Tester sendet zuerst, das Geraet antwortet. Eine Frage des Timings, welches aufgeloest werden muss.
Richard B. schrieb: > der Tester hat einen MAX Rs485 Transceiver und > funktioniert mit einer Halb-Duplex Kommunikation (2 Drähte, + > Spannungsversorgung Tester und GND). Wenn ich nun die die Kommunikation > mitlese (probeweise einen billigen RS485 auf RS232 getestet), sieht man > natürlich nicht welche Daten der Tester sendet, und welche die Anlage > selbst. Der "Tester" muß ein weiteres Signal haben, mit dem die Kommunikationsrichtung gesteuert wird, da ja Halbduplex, üblicherweise bezeichnet als TXEN o.ä. Das muß man einfach nur auswerten und irgendwie an die mitlauschende Einheit melden. Z.B. dadurch, die Kommunikation mit dem Spion auf 9Bit aufzublasen und im neunten Bit halt den aktuellen Status des TXEN-Signals abzubilden. > Ich suche also nach einer Möglichkeit, möglichst ohne teure Hardware, > die Richtung der Daten ersichtlich zu machen (was kommt vom Tester, was > von der Maschine). Tja, ich würde da definitiv einen kompetent programmierten, spottbilligen µC empfehlen...
Entweder setzt du dich auf beide Platinen und schaust dir dort jeweils die TX-Leitung zwischen Mikrocontroller und Bus-Treiber an (Logic-Analyzer, Oszilloskop) oder du baust dir ein Device aus Bustreiber-Mikrocontroller-Bustreiber was du in die Kommunikation einschleifst. Der Mikrocontroller leitet die Nachrichten 1:1 weiter aber du siehst ja ob sie von der Seite Bustreiber1 oder Bustreiber2 kommen. Ist natürlich ziemlich aufwändig.
c-hater schrieb: > Der "Tester" muß ein weiteres Signal haben, mit dem die > Kommunikationsrichtung gesteuert wird, da ja Halbduplex, üblicherweise > bezeichnet als TXEN o.ä. Warum? Wenn der Tester speziell für dieses Gerät ist, weiß er höchstwahrscheinlich, wie sich das Gerät benimmt. Dann ist oft schon aus dem Kommunikationsprotokoll klar, wann und in welche Richtung die Daten laufen.
Wolfgang schrieb: > Warum? > > Wenn der Tester speziell für dieses Gerät ist, weiß er > höchstwahrscheinlich, wie sich das Gerät benimmt. Dann ist oft schon aus > dem Kommunikationsprotokoll klar, wann und in welche Richtung die Daten > laufen. Weil die Kommunikation halt letztlich physisch nur in eine Richtung laufen kann und die Hardware, die die entsprechenden Baugruppen des Businterface ansteuert, halt wissen muss, wann sie was enablen muss. Dieser simple, durch die dem System selber innewohnende Gesetzmäßigkeit findet sich dann auch in Steuerleitungen ALLER gemeinhin verwendeten RS485-Transceiver. Und aus ökonomischen Gründen ist sehr stark anzunehmen, dass auch der "Tester" so ein Teil benutzt...
c-hater schrieb: > Weil die Kommunikation halt letztlich physisch nur in eine Richtung > laufen kann und die Hardware, die die entsprechenden Baugruppen des > Businterface ansteuert, halt wissen muss, wann sie was enablen muss. Bei entsprechendem Protokoll (Master/Slave) kann der Sender direkt durch die Datenübertragung gesteuert werden, i.e. derjenige der etwas senden will, schaltet selber sein TXen. Der/die Slaves dürfen nur das Mikrofon ergreifen, nachdem der Master ihnen das Wort erteilt hat. Nach außen siehst du von dem TXen dann nichts.
Wolfgang schrieb: > Bei entsprechendem Protokoll (Master/Slave) kann der Sender direkt durch > die Datenübertragung gesteuert werden Ja, wäre möglich. Denn dann müßte die Haltezeit für das Umschaltsignal für die Hardware sozusagen "vordefiniert" sein und durch Aktivität des "masters" getriggert werden. Auch das kann ein kompetent programmierter µC natürlich problemlos abbilden. Er braucht halt dann genau dieselbe Information vorab, die auch die Elektronik des Businterface des Testers braucht: die Haltezeit für das (dann selbsterzeugte) TXEN-Signal. Trivialste Trivialitäten, jedenfalls, wenn man das Grundprinzip der Halbduplex-Kommunikation kapiert hat...
Man könnte auch einen rs485 repeater ausprobieren, der hat eine richtungsanzeige, vielleicht gibt es den auch als ic. Oder 2 rs485 zu serial und einen mikrocontroller als passthrough dazwischen.. bzw einen 2ten dazu.. dann könnte man beide seiten der kommunikation protokollieren. Nachtrag.. mit nem Arduino wäre das in einer halben Stunde aufgebaut, programmiert und als csv auf dem Rechner.
:
Bearbeitet durch User
Beitrag #6416409 wurde von einem Moderator gelöscht.
c-hater schrieb im Beitrag #6416409:
> Sicher nicht von der weit überwiegenden Mehrheit der Arduidioten...
Vielleicht, vielleicht auch wirklich einfach.
Hört sich aber nach rs422(2 Teilnehmer rs485) an? Das wäre absolut Uart
kompatibel.. dann einen billigen arduino mega2560 mit 3 seriellen Ports,
2 ports direkt an die rs485 Wandler und der dritte am USB.. dann pass
through und die Bytes mit Richtung csv kompatibel auf usb in die
Konsole. Ein Telegramprotokoll.
Wir haben auf der Arbeit voll konfigurierbare Repeater zur
Signalverstärkung.. die haben für beide Seiten Rx tx lämpchen. Ob man
rs485 als mehrteilnehmer Bus durchreichen kann, da bin ich mir nicht so
sicher.. die repeater müssen aufwendig über dip Schalter konfiguriert
werden und es klappt nicht in jeder rs485 Anwendung.
Wenn Du an den Chip kommst: dort das Signal für txen abgreifen. Falls nein und wenn die Übertragung gut ist und auch ohne Abschlusswiderstände lauft, kannst Du: Eine Leitung auftrennen und beide Seiten mit ~1k an halbe Spannung legen. Bei richtiger Wahl der Leitung und Rs kannst Du meist direkt mithören. Sonst ein Pegelwandler dahinter.
Mit einem RS485-USB Adapter (für 5€ zu kaufen) kann man doch einfach mithören: An einen PC Anschliessen; mit Hterm oder LKterm oder auch den guten alten Hyperterminal der Komminkation von Master und Slave zuhören. Mit Hterm kann man die Baudrate (und den Rest wie z.B. Parity) im laufenden Betrieb umstellen bis es passt. Wenn man dann einen der Teilnehmer abklemmt, dann weiss man wer Master und wer Slave ist. Der Master schickt zyklisch Datenpakete, der Slave nur nach Aufforderung. Dann geht es als nächstes ans Dekodieren. In der Regel gibt es einen Startidentifier (gerne STX) und ein Endidentifier (ETX, CR, LF,...) Gerne wird ASCII in hex übertragen. Ich so unseren alten Klimaschrank an einen PC angebunden; jetzt können wir schöne Kurven fahren usw.
Philipp K. schrieb: > Hört sich aber nach rs422(2 Teilnehmer rs485) an? RS422 ist eher RS232 differentiell: also jede Datenrichtung eigene Leitungen, was dann RS485-4Wire entspräche. c-hater schrieb im Beitrag #6416409: > Sicher nicht von der weit überwiegenden Mehrheit der Arduidioten... ja. ja, ja, bla, bla, bla Arduino ist doch als Einstieg für Anfänger gedacht (gewesem).
Trenne die Verbindung auf. Lese die Daten von beiden Seiten. Wenn einer was sendet Protokolliere es und schicke es weiter. @c-hater Ich kann auch jedes Bit in ASM einzeln behandeln. Muß es aber nicht. Arduino (in vielen inkarnationen) ist für mich einfach in vielen Fällen nur praktisch. Anstöpseln ein paar Zeilen Code reinhauen rauf auf das Dingens fertig. Aber du bohrst ja wohl auch Stahlbeton mit der Handleier.
Einer schrieb: > Trenne die Verbindung auf. > Lese die Daten von beiden Seiten. Das funktioniert bei reinem Master-Slave, wenn man die Verbindung zum Master auftrennt. Bei einem Bus bei dem jeder mit jedem redet funktioniert das nicht. Georg
c-hater schrieb im Beitrag #6416409:
> Sicher nicht von der weit überwiegenden Mehrheit der Arduidioten...
Das ist er wieder beleidigend!
Was hast du davon, alle Arduino User zu beleidigen?
Warum beleidigst du mich?
Was habe ich dir getan, dass dir dieses Befriedigung verschafft?
Arduino Fanboy D. schrieb: > Was hast du davon, alle Arduino User zu beleidigen? c-hater braucht das für sein Ego. Betrifft keineswegs nur Arduino-Benutzer, sondern alle. Georg
georg schrieb: > Das funktioniert bei reinem Master-Slave, wenn man die Verbindung zum > Master auftrennt. Bei einem Bus bei dem jeder mit jedem redet > funktioniert das nicht. Doch. Wie von mir beschrieben. Bei Fragen einfach melden A. S. schrieb: > Eine Leitung auftrennen und beide Seiten mit ~1k an halbe Spannung > legen. > > Bei richtiger Wahl der Leitung und Rs kannst Du meist direkt mithören. > Sonst ein Pegelwandler dahinter. natürlich nur mit satten Reserven, nicht wenn Leitungslänge oder Geschwindigkeit fast ausgenutzt sind.
Wie schon gesagt wurde, müssen die Tranceiver bei Halb-Duplex enabled werden und ein Richtungssignal bekommen. Warum schraubst du die Kisten nicht einfach auf und greifst diese Signale ab? Du willst den Tester doch sowieso nachbauen... Gruß Rainer
Arduino Fanboy D. schrieb: > Das ist er wieder beleidigend! > > Was hast du davon, alle Arduino User zu beleidigen? Sehe ich nicht so, das ist wenn bei Dir halb voll zu halb Leer wird ;) Man kann sich aber auch wie ein kleines Kind anstellen.. ich benutze auch meistens Arduino, könnte es auch händisch und fühle mich NULL angesprochen. (Eher geschmunzelt, mal schauen wer sich angesprochen fühlt.) Ich würde eine Bridge mit Analyzer bauen.. ich glaube sowas gibt es irgendwo auch fertig.. irgendnen Logik Analyzer glaube ich..
:
Bearbeitet durch User
Philipp K. schrieb: > Man kann sich aber auch wie ein kleines Kind anstellen.. ich benutze > auch meistens Arduino, könnte es auch händisch und fühle mich NULL > angesprochen. (Eher geschmunzelt, mal schauen wer sich angesprochen > fühlt.) Der c-hater verhält sich wie ein Arschloch, aber du bist ein Arschloch! So besser?
Irgendeiner schrieb im Beitrag #:
> belangloses
Man seif ihr peinlich, man könnten meinen das euer IQ bei
Zimmertemperatur liegt.
Warum schafft ihr es nicht bei sachlichen Fragen eure dümmlichen
gegenseitigen Beleidigungen sein zu lassen. Weil irgendein Vollidiot
damit anfängt?
Zum Thema:
Wie schon geschrieben gibt es Repeater. Man kann auch am Transceiver das
Richtungssignal abgreifen. Das funzt wenn es nur einen Slave gibt.
An einfachsten ist imo Widerstände zu nehmen und einen OP zum auswerten.
Das kann man überall einschleifen.
A. S. schrieb: > Doch. Wie von mir beschrieben. Bei Fragen einfach melden Frage: du trennst den Master von Rest des Busses mit 3 Slaves ab, wie erkennst du wenn sich Slave 1 mit Slave 3 unterhält, wer was sendet? Wahrscheinlich bin ich zu doof, aber du erklärst es sicher. Georg
georg schrieb: > des Busses mit 3 Slaves ab, wie erkennst du wenn sich Slave 1 mit Slave > 3 unterhält, wer was sendet? Was immer auch der Unterschied zwischen master und Slave sein soll, ... Wenn Du 4 devices hast, dann halt 4 Widerstände und 4 mitlesekanäle. Du trennst die Leitung notfalls direkt am Gerät ab.
georg schrieb: > wie > erkennst du wenn sich Slave 1 mit Slave 3 unterhält, wer was sendet? Seit wann dürfen slaves miteinander kommunizieren? Alle Aktivitäten gehen vom Master aus und der ist auch immer beteiligt.
georg schrieb: > Wie überaus praxisgerecht. Wenn Du 4 Kanäle getrennt monitoren willst, ... dann ist das am einfachsten mit 4 seriellen Schnittstellen, wo Du deren TX an je einen RX hängst. Was kostet ein 4-fach 232 zu USB? 10€? Das dies ein temporärer und provisorischer Zustand ist, in dem weder Leitungslängen noch Groundanhebungen ausgereizt werden, sollte klar sein. Wenn Du unter worst-Case-Bedingungen testen willst, musst Du halt analog Aufwand treiben. So geht es ohne. Du musst halt wissen, ob es Dir um Prinzipien geht, oder darum, die Information einmal mitzulesen.
Dieter W. schrieb: > Seit wann dürfen slaves miteinander kommunizieren? Wo steht in der RS485-Norm, dass sie das nicht dürfen? Man kann das auch Multi-Master nennen, aber das ist Wortklauberei. RS485 ist jedenfalls ein any-to-any-Bus. Georg
georg schrieb: > Wo steht in der RS485-Norm, dass sie das nicht dürfen? Man kann das auch > Multi-Master nennen, aber das ist Wortklauberei. RS485 ist jedenfalls > ein any-to-any-Bus. Nicht in der Halbduplex-Inkarnation!!! Diese Feinheit ist dir wohl entgangen...
Arduino Fanboy D. schrieb: > Der c-hater verhält sich wie ein Arschloch Naja, mag sein. Aber immerhin ein kompetentes Arschloch... Von kompetenten Arschlöchern kann man lernen. Die meisten Uni-Profs sind welche, überhaupt die überwiegende Mehrheit der Wissenschaftler und Ingenieure. Das Arschlochtum kommt übrigens oft nur für die als solches rüber, die keine Ahnung haben. Also das Problem: von jeder beliebigen Stufe im Wissensstand sieht alles durch höhere Wissenstand getriebene oft einfach nur wie Arroganz aus... Das ist kein wirklich neues Phänomen. Schon in den schriftlichen Hinterlassenschaften der Antike sind solche Sachen nachweislich häufig zu finden. Vermutlich war es aber schon immer so, seitdem Gehirne überhaupt mit Abstraktionen umgehen konnten. Den Blinden Wichsern vor der Zeit der Schrift fehlte halt einfach nur die (Schrift-) Sprache und /oder das entsprechende Medium, um das aktenkundig zu machen...
c-hater schrieb: > Nicht in der Halbduplex-Inkarnation!!! > > Diese Feinheit ist dir wohl entgangen... Wie sieht bitte ein RS485-Bus aus, der NICHT halbduplex ist? Auf dem Bus kann immer nur einer auf einmal senden weil eben nur ein Leitungspaar vorhanden ist, aber das besagt überhaupt nichts über Master- oder Slave-Rollen. Daran ändern auch deine Pöbeleien nichts. Georg
c-hater schrieb: > georg schrieb: > >> Wo steht in der RS485-Norm, dass sie das nicht dürfen? Man kann das auch >> Multi-Master nennen, aber das ist Wortklauberei. RS485 ist jedenfalls >> ein any-to-any-Bus. > > Nicht in der Halbduplex-Inkarnation!!! > > Diese Feinheit ist dir wohl entgangen... RS(!)-485 spezifiziert überhaupt kein Protokoll, insofern kann man da natürlich auch bei Halbduplex vom Master eine Kommunikation zwischen zwei Slaves initiieren lassen (man sehe sich für so ein Protokoll einfach mal IEEE-488 an, wo so etwas explizit vorgesehen ist). Das hängt alles vom Protokoll ab. Wenn du einen anderen Standrad meintest, der auch ein bestimmtes Protokoll wenigstens für Halbduplex spezifiziert, dann nenne bitte auch genau jenen Standard, sonst führt das leicht zu Missverständnissen.
georg schrieb: > Wie sieht bitte ein RS485-Bus aus, der NICHT halbduplex ist? Nun, wie ein Vollduplex-Bus halt. Er besitzt zwei differentielle Leitungspaare. Wenn man sich die "Differentialität" wegdenkt, entspricht das dann logisch einer 3-Draht-UART. > Auf dem Bus kann immer nur einer auf einmal senden Das ist immer so, bei jedem Bus. Die Hauptunterschied besteht darin, ob es möglich ist, gleichzeitiges Senden zu detektieren (um dann auf höheren Protokollschichten eine Busarbitrierung implementieren zu können).
c-hater schrieb: > Naja, mag sein. Aber immerhin ein kompetentes Arschloch... Deine fachliche Kompetenz ziehe ich ja gar nicht in Zweifel. Die blitzt oft genug auf. c-hater schrieb: > Antike Dass du für den antisoziales Verhalten allerdings die Antike als Rechtfertigung bemühen musst, kommt mir sehr befremdlich vor. Ich schätze, dass man auf die Art jegliches Verhalten begründen kann. Denn in der Vergangenheit wurde sicherlich jegliche Schweinerei schon mal begangen. Und das auch in Serie. Nee, das glaube ich dir nicht. Die Ursache für dein Verhalten hier im Forum liegt nicht in der Antike. Klar, ich habe Vermutungen.... z.B. dass man dir als Koten die Spiegelneuronen aus dem Leib geprügelt hat. Da wärst du nicht alleine mit und hättest auch keine Schuld daran. Auf Grund deiner Intelligenz, welche ich dir mal zuspreche, könntest du diese "emulieren". Aber genau das tust du nicht und genau das werfe ich dir vor. Ein paar mal habe ich dich gefragt, "Warum du das tust?" Da du darauf nicht antwortest, nehme ich mal an dass du gar nicht weißt was du damit anrichtest, oder warum. Oder bist du einfach nur von Natur aus böse? Solche Leute hat man in der Antike gerne hingerichtet, oder auch zu Königen gemacht. Beides steht dir wohl nicht zur Verfügung.
Arduino Fanboy D. schrieb: > Ein paar mal habe ich dich gefragt, "Warum du das tust?" Ob c-haters Bösartigkeit angeboren ist, ihm anerzogen wurde oder ob er sie sich mühsam erarbeitet hat spielt hier doch keine Rolle. Dies ist ein Elektronik-Forum und keine Psycho-Selbsthilfegruppe (an die sich c-hater sowieso nie wenden würde, dazu fühlt er sich viel zu wohl). Georg
Arduino Fanboy D. schrieb: > Ein paar mal habe ich dich gefragt, "Warum du das tust?" Ich frage mich wieso Du überhaupt eine Diskussion Fern vom Thread-Thema anfängst nur weil da jemand Arduidioten (oder so ähnlich) geschrieben hat. Bevor ich mit dem Arduino angefangen habe, bzw- überhaupt mit C etc.. habe ich Jahrelang Java und JRE programmiert. Mir ist bewusst das Arduino für Idioten ist, war ich ja auch mal ohne C Vorkenntnisse (Steiniger weg von Java).. Ich nutze es weil es schnell geht, schaue aber auch mal in Register oder beim esp in die IDF. arduino.cc/forum/Deutsch ist da die richtige Ecke.. da gibt es schon viele Leute die unter den ganzen Noobs als Alltgashelfer auf wolke7 schweben und sich selbst beweihräuchern. ;)
von Richard B. schrieb: >Zur Richtungserkennung bei Halb-Duplex RS485 finde ich leider online >auch nicht viel. Habe gesucht, ob das mit einem Raspberry Pi >realisierbar wäre (mit Zusatzhardware), da wir einen haben... Weil es hardwaremäßig einfach nicht möglich ist die Richtung zu detektieren, daß machen die angeschlossenen Geräte mit einen Übertragungsprotokoll, daß mußt du studieren. https://www.eltima.com/de/article/rs485-communication-guide/
Einer am Bus muss ja die Kommunikation starten. Durch Auftrennen kann man schauen wer pingt. Der wird in seinem Protokoll stehen haben wie er heißt und wer antworten soll ... der Rest ist Fleißarbeit. Knifflig wird’s eventuell bei Prüfsummen
Günter Lenz schrieb: > Weil es hardwaremäßig einfach nicht möglich ist die > Richtung zu detektieren Ist es natürlich, aber an anderer Stelle. Und da kann der TO doch offensichtlich dran...aber so kommen wir wohl nicht weiter... Gruß Rainer
Richard B. schrieb: > Hat jemand einen nützlichen Tip? Es gibt online ein Gerät, welches RS485 > Richtungserkennung bietet, aber 500€ für ein solches eher privates > Projekt ist eine etwas hohe Investition. Lol. 2 RS485=>USB Adapter kaufen (1.5E für beide), Leitung auftrennen, Adapter jeweils an einem Ende anschliessen, in 2 USB-Ports einstecken und ein kleines Programm schreiben, welches Daten von USBPort_A zum USBPort_B schickt (und umgekehrt) und gleichzeitig eine Aufzeichnung mit Richtung und Timestamps erzeugt. P.S. Oder einfach mit Wireshark die beiden Ports beobachten und aufzeichnen. P.P.S Du hast zwar Verspätung von einem Byte, aber das wissen die beiden ganz einfach nicht :-)
:
Bearbeitet durch User
Beitrag #6420012 wurde vom Autor gelöscht.
Angehängte Dateien:
-
RS.PNG
4,6 KB
Wow, nun habe ich wirkliche viele Antworten mit Ideen bekommen. Erstmal vielen Dank. Nun hat mir die Idee, mit einem RS485 Repeater gefallen, da ich weder ein Oszi, noch Arudino besitze ;) Aber irgendwie ist für mich nicht ersichtlich, wie ein solcher die Richtung der Daten ersichtlich machen würde. Habe da an allen Repeatern nur einen Eingang gesehen, also einmal A+B. Dann 2x oder mehr Output. Hatte nun selbst noch eine Idee, aber ich weiß nicht, ob das so einfach ist... Ich würde jeweils am Tester und an der Hautplatine 2 Drähte an A und B anschließen. "Einer" (jeweils an A und B) ganz normal mit dem anderen Teilnehmer verbunden, und einer geht direkt auf einen USB RS485 Adapter zu A und B. Nun die wichtigste Frage dazu: Würde, beim Aufbau wie als Screenshot angefügt, die Antwort des jeweils anderen Teilnehmers auch an den RS495 USB Adapter weitergeleitet werden, oder würde man nur die gesendeten Daten des jeweiligen Gerätes sehen? Sollte das nicht funktionieren, wäre es wohl am einfachsten, das TX Signal am Transceiver abzugreifen, diesen muss ich nur finden ;) Zum mitlesen generell (bisher ja probeweise nur mal "dazwischen"), nutze ich den Eltima-Serial-Port-Monitor, dieser hat die Baudrate etc. selbstständig erkannt sodass ich dann in Klartext mitlesen konnte. Nun weiß ich ehrlich gesagt nicht, wie ich hier, beim ständiger Anfrage vom Tester, und Antwort von der Platine (der Tester hat einen blinkenden Punkt, der ausbleibt, wenn die Platine nicht mehr reagiert, deshalb wird ständig gesendet), hinterherkommen soll, wenn ich das TX Signal einer Seite abgreife, aber vielleicht funktioniert meine Idee (siehe Screenshot) ja doch. Vielen Dank schonmal.
Richard B. schrieb: > Nun die wichtigste Frage dazu: Würde, beim Aufbau wie als Screenshot > angefügt, die Antwort des jeweils anderen Teilnehmers auch an den RS495 > USB Adapter weitergeleitet werden, oder würde man nur die gesendeten > Daten des jeweiligen Gerätes sehen? Natürlich wird der gesammte Verkehr aufgezeichnet. Es wird also nix mit deiner genialer Idee. > Sollte das nicht funktionieren, wäre es wohl am einfachsten, das TX > Signal am Transceiver abzugreifen, diesen muss ich nur finden ;) Am einfachsten wäre es, die beiden Adapter so anzuschliessen, wie ich es dir vorgeschlagen habe. Aber du kannst natürlich nach TxD_EN suchen, Drähte anlöten und... Richard B. schrieb: > Das ganze dann in beliebiger Programmiersprache nachzubauen, ist nicht > das Problem sondern... Aber ein kleines Programm zu schreiben, um Daten zwischen 2 USB-Ports auszutauschen und gleichzeitig alles übersichtlich aufzuzeichnen, ist ein Problem für dich? Mannomann...
Wenn Du keine Leitung zwischen den Teilnehmern auftrennst, kannst du nicht unterscheiden, welche Seite sendet. Symmetrisch bedeutet, dass das Signal doppelt übertragen wird. Du kannst daher eine Leitung auftrennen. Dazu müsstest Du Dich aber mit den Signalpegeln befassen, zumindest in der Theorie.
Richard B. schrieb: > Sollte das nicht funktionieren, wäre es wohl am einfachsten, das TX > Signal am Transceiver abzugreifen, diesen muss ich nur finden ;) Ja und dann bist du doch auch soweit, das Richtungssignal am Tranceiver abzugreifen und weißt so, wann der sendet und wann der empfängt. Kannst du denn die verbauten Bausteine identifizieren? Gruß Rainer
Marc V. schrieb: > 2 RS485=>USB Adapter kaufen (1.5E für beide), Leitung auftrennen Kann jemand für dumme Mitleser erklären, wo man bei sowas eine Leitung auftrennt? es müsste ja so aufgetrennt werden, dass die Kommunikation zwischen beiden Teilnehmern noch läuft, man aber trotzdem sieht, was von jedem Teilnehmer kommt. Vielleicht zwei RS485 auf WiFi Adapter mit Pass through und dann schauen was welcher WiFi Adapter sendet?
Marc V. schrieb: > 2 RS485=>USB Adapter kaufen (1.5E für beide), Leitung auftrennen, > Adapter jeweils an einem Ende anschliessen, in 2 USB-Ports einstecken > und ein kleines Programm schreiben, welches Daten von USBPort_A zum > USBPort_B schickt (und umgekehrt) und gleichzeitig eine Aufzeichnung > mit Richtung und Timestamps erzeugt. Und woher weiß dieser Adapter, in welche Richtung er die Daten übertragen muss? Es geht ja nicht nur von A nach B, sondern auch von B nach A. und zwar über die selben zwei Drähte!
Angehängte Dateien:
-
RS485.png
40 KB
Johannes schrieb: > Kann jemand für dumme Mitleser erklären, wo man bei sowas eine Leitung > auftrennt? Hier.
Stefan ⛄ F. schrieb: > Und woher weiß dieser Adapter, in welche Richtung er die Daten > übertragen muss? Es geht ja nicht nur von A nach B, sondern auch von B > nach A. und zwar über die selben zwei Drähte! Weil der Adapter bisschen schlauer ist als du... Im ernst: Was von RS485 reinkommt wird nach USB weitergereicht, was von USB kommt wird nach RS485 weitergereicht. So schwer zu verstehen?
:
Bearbeitet durch User
Marc V. schrieb: > Weil der Adapter bisschen schlauer ist als du... Deine Skizze hat die Sache verdeutlicht, danke dafür. Hier müsste der schnüffelnde PC also beide Seiten auf "Empfangsbereit" stellen und dann (wenn er etwas empfängt) die Daten zur anderen Seite durch reichen. Das wird einen geringen Einfluss auf das Timing haben. Könnte klappen, gefällt mir.
Stefan ⛄ F. schrieb: > Hier müsste der schnüffelnde PC also beide Seiten auf "Empfangsbereit" > stellen und dann (wenn er etwas empfängt) die Daten zur anderen Seite > durch reichen. Ja, geschieht aber alles wenn der RxD-Event feuert. Jedesmal, wenn sich bei einem der beiden USB-Ports die Richtung ändert, wird im LogFile ein CR/LF, Teilnehmer und Timestamp gemerkt, alle weiteren Bytes werden in der selben Zeile geschrieben. Besser als das braucht es nicht. > Das wird einen geringen Einfluss auf das Timing haben. Im Normalfall 1 Byte, Max. 2 Bytes zwischen Nachrichtenende und Antwort, aber das merken die Teilnehmer nicht.
Johannes schrieb: > Kann jemand für dumme Mitleser erklären, wo man bei sowas eine Leitung > auftrennt? > es müsste ja so aufgetrennt werden, dass die Kommunikation zwischen > beiden Teilnehmern noch läuft, man aber trotzdem sieht, was von jedem > Teilnehmer kommt. Die Kommunikation ist symmetrisch. Das bedeutet, dass jede Leitung die Information überträgt. Mann kann also eine Leitung auftrennen (an jedem Transceiver) und "Mocken", hier per Widerstand auf einen Mittelwert ziehen. Beim Lesen des Transceivers reicht dieser Mittelwert, damit die andere Leitung mal 1, mal 0 melden kann. Beim Senden des Transceivers kann man an dieser Leitung mithören, was er sendet. Dazu muss man sich das aber aufzeichnen und sich mit den Signalen befassen.
Den Sniffer: http://jheyman.github.io/blog/pages/RS485Sniffer/ schon einmal angesehen? Unabhängig davon, könnte man sich ja auch die Schaltung des Masters rein elektrisch ansehen und dort einfach den Umschaltpunkt von senden zu empfangen abgreifen/mitloggen ...oder direkt: --> Beitrag "Re: RS485 Kommunikation zwischen zwei Geräten sniffen" "Wenn man Zugriff auf den RS485-Treiber des Masters hat, also den Mithörer zwischen dessen UART und dem Treiber anbringen kann, dann kann man auch die gesendeten von den empfangenen Daten unterscheiden."
Vergessen... Als Anregung zur Umschalt-Suche: in einer älteren c't war eine Umschaltung für RS485 von Empfang auf Senden beschreiben, ich habe auf die schnelle nur die furchtbare url der google-books-Sicht in der Raspi-Sonderausgabe dazu gefunden: https://books.google.de/books?id=HAo4DwAAQBAJ&pg=PA101&lpg=PA101&dq=rs485+c%27t+z%C3%A4hler&source=bl&ots=UhZRl0O3K-&sig=ACfU3U11t1BhWNgyl3g5oTwiANQWPJtrww&hl=de&sa=X&ved=2ahUKEwj27fCg9YvsAhXNT8AKHf2pBQcQ6AEwEnoECAkQAQ c't Raspberry Pi (2017): Raspi-Projekte auch für Raspbian Stretch
Wenn das fragliche Gerät 10 Jahre alt ist, dann ist da mit Sicherheit kein TTL-Grab ala CT oder Elektor verbaut. Wie ich schon schrob, haben die Halb-Duplex-Tranceiver einen Enable- und einen Richtungseingang. Und da der TO die Geräte ja eh nachbauen will, wäre es doch kluch, sich erst mal die verbaute Hardware anzuschaun. Auf der Leitung "herumsniffen" kann man dann doch immer noch... Gruß Rainer
junge, junge... tja, toll, nur nichts anderes habe ich ihm ja auch (von mir aus: dann noch einmal) "angeboten, zu machen"...
Marc V. schrieb: > Hier. Die Lösung gefällt mir, wenn das so einfach klappt. Rainer V. schrieb: > Und > da der TO die Geräte ja eh nachbauen will Fast. Gesetzt ist, das ein Laptop später das können soll, was der Tester kann. Muss also alle Funktionen die der Tester hat, in eine Windows Software implementieren. Und ohne Quellcode des Mikrocontrollers samt Lockbit vom Tester, bleibt eigentlich nur die Kommunikation mitzuschneiden (denke ich). Das ich von der Hardware tatsächlich eher wenig Ahnung habe, merkt man wahrscheinlich auch. Deshalb bevorzuge ich das reine "sniffen" der Daten die ich dann direkt weiterverwenden kann. Werde mich hier dennoch weiter einlesen. Nun hätte ich noch eine Frage... benötige ja 2 RS485-USB Converter für die Lösung von Marc V. Habe mir flüstern lassen einen FT232 oder CP2102 Adapter zu nehmen, weil die billigen aus China kein TX-Enable Ausgang haben... und der Adapter am Ende ja auch senden können muss. Wären 2 hier von in Ordnung? https://www.ebay.de/itm/USB-to-RS485-TTL-Serial-Converter-Adapter-FT232/143727923676?_trkparms=ispr%3D1&hash=item2176da11dc:g:kRcAAOSwaWtcrw~T&enc=AQAFAAACcBaobrjLl8XobRIiIML1V4Imu%2Fn%2BzU5L90Z278x5ickk7d4nremBkvNKtcC0ZwqXDBSAM7hcOCFA5iR1KGsg%2B7QMmuDAZA6xODSNDEjc0d0Dliwuir2HphYKGFxY8OCtaIfRopzi2JH3Gc7nRFCdA9nPcyK9xKJhItsNiXkSg2DmLd8mFB%2B3GUoRTacby%2FY01OaapnLKdod0DIW54ALJzVwwPAT19lGwnozftjyx7lVwA3lZrLxEvgs4YHu9%2FNbpsgI%2FJShI6jhCWlEMg0bT8AwdW38aOmf4ChOHBAUi1%2Fj8mlr7ZIpoqZAFnpo3ATrBJlGo49wMuW5Wt5W2OCrYmYojEpZIvDiQ74GkIy52QLhKdn9QngQOlWgBZYWh%2Fza8jyxdhfWRMsJ2%2F3ZJz3V5kml5AXNjRTw9r7X2fsHeIyTkqP0xzZpNwy9w0eAoW7F0Pp5MqPNvjJJbY32TvXjCEZ%2FebxqSymWyprmWXhvsAdBs3Vt%2BdLMJTXaB5eeHvCkVvfFmZ%2BO3lYL%2FxDle%2FHhr3vlrrYUu%2BpbuR2LR0JxSaHh1YoZRv%2Feqpep4JCIFqNDlTD3pkOWOuvKk8cTlR5CEFqnXZlryVw5UnutsIkPeEAAB11HQ7XHCaHGXxt3jjWtnitDaa2ylCwLGoy0d9onRYxsNa4XvRhP%2FfMiN%2BMyZGmNZYgke6EjSW0tJh%2FaSD7VgXN0gosXEdONoR83vJhZmxc4BCkNY2qWhUj%2FnmErbD%2FPnuCb4JUV%2BFP6MKdCM15nAn7z6%2BbjO61VFlEYxioqHiROOW6%2FuaFfSQ1w8J4%2FpE4xFSscYwylB9RA6kdzhAyme7A%3D%3D&checksum=14372792367635d94cb8d53f48fa82df73e34e673312 Danke euch.
Beitrag #6421135 wurde vom Autor gelöscht.
Angehängte Dateien:
-
DSC_0005.JPG
200 KB
Richard B. schrieb: > Habe mir flüstern lassen einen FT232 oder CP2102 Adapter zu nehmen, weil > die billigen aus China kein TX-Enable Ausgang haben... > und der Adapter am Ende ja auch senden können muss. Unsinn, falsch geflüstert. Jeder Adapter kann sowohl senden als auch empfangen. P.S. So sehen meine aus, waren damals 15E für 10 Stück. P.P.S. Wieso da auf einmal 2 Bilder sind...
:
Bearbeitet durch User
Richard B. schrieb: > Das ich von der Hardware tatsächlich eher wenig Ahnung habe, merkt man > wahrscheinlich auch. Deshalb bevorzuge ich das reine "sniffen" der Daten > die ich dann direkt weiterverwenden kann. Werde mich hier dennoch weiter > einlesen. Also mein lieber TO, du machst da ein Fass auf und ich hoffe inständig, dass du damit nicht deine Brötchen verdienen mußt! Ist aber wahrscheinlich so...also höre auf die Jungs mit den Sniffern. Mit einem Windoof-Laptop eine Testbox nachbilden zu wollen, käme mir - sorry - wie das hornberger Schießen vor. Was immer du auch auf W-Ebene draufhaben magst, das kann doch nur in die Hose gehen. Bitte verzeih den Pessimismus...bin trotzdem gespannt! Gruß Rainer
Naja... sich anzeigen zu lassen, welche Ein und Ausgänge aktiv sind / den Akkustand der Anlage anzeigen lassen etc., die die Hardware bei entsprechender "Anfrage" des Testers in Klartext (als HEX) ausgibt, lässt sich, wenn man mal in der Lage ist die einzelnen Funktionen mitzuschneiden, wohl auch von einem extrem unerfahrenen Anfänger in welche Programmiersprache auch immer, implementieren. Daten über einen seriellen Port senden und empfangen (eben mit der Voraussetzung, man weiß was man senden muss), sollte eigentlich jeder Anfänger hinbekommen. Aber wenn man (wie ich) das alles bisher nur mit RS232 gemacht hat (hier ist mitlesen samt Richtungserkennung natürlich überhaupt kein Problem) und eigentlich (muss ich zugeben) von Mikrocontrollern keine Ahnung hat, ist das mit RS485 erstmal nicht so leicht, aber ich bin hier ja gut aufgehoben ;)
...erlaube mir also - für mich - äußersten Zweifel. Du erzählst pausenlos, dass du quasi von überhauptnix keine bis garkeine Ahnung hast...was soll das denn werden? Blödsinn...sorry... Rainer
Es scheint hier etwas Unverständnis darüber zu geben, wie RS485 und dann auch so ein USB-RS485 Konverter funktioniert... Solange über USB keine Daten auf den Bus zu senden sind, hält der Konverter die Tx Enable Leitung der RS485 Seite inaktiv. Wenn Daten zu senden sind, wird das Tx Enable genau für die Dauer des Bytes auf aktiv gesetzt. Da der Konverter die Baudrate und Wortlänge und Format der RS485 Seite kennt, kann er punktgenau die Aktivierung des Busses timen. Im Gegensatz zu "handgesteuerten" RS485 Bussen ist das super komfortabel. Ich schreibe seit > 25 Jahren serielle Treiber, und es gibt gerade bei der Umschaltung etliche Fettnäpfchen. Aus Effizienzgründen ist es z.B. beim "manuellen" Steuern sinnvoll, das Hin-und Herschalten abhängig vom Datenstrom zu machen, d.h. die Tx Enable wird am Anfang eines Datenstromes aktiv gezogen und erst nach dem letzten Byte des Pakets inaktiv (die Zyklen zum Umschalten sind recht teuer). Die Logik dafür ist höchst abhängig davon, wie der Treiber programmiert ist (also ob DMA, FIFO, einzeln Interruptgesteuert oder über polling des DR empty registers etc) Darum braucht man sich mit einem Konverter nicht zu kümmern, der macht es selber, um der hat auch keine Effizienzprobleme. Den (und den Bus) stört es nicht, dass der Tx Enable zwischen zwei Zeichen sehr kurz auf inaktiv gezogen wird. Ein anderes typisches Problem besteht darin, daß manche UART Bausteine (also im Controller "vor" dem RS485 PHY) per barrel shift register funktioneren, d.h. logisch kommt der "data register empty" Interrupt schon bevor das Byte auf den Bus geschoben wird. Bereits an dieser Stelle den Bus beim letzten Byte umzuschalten ist keine gute Idee (manchmal wird genau aus diesem Grunde ein "Müllbyte" am Ende des Datenstromes definiert, was natürlich auch eine Krücke ist). Also das Syncronisieren der Tx Enable mit dem physikalischen Bus ist potentiell ein Ärgernis. Auch das ist mit dem Konverter kein Problem. All das ändert natürlich nichts daran, dass (wie vorher schon angemerkt wurde) im HD Bus (also Zweidraht RS485) Einigkeit darüber herrschen muss, wer den Bus aktiv beschrieben darf. Das ist durch das Protokoll vorgegeben, und daran hat sich jeder der Knoten zu halten, muss also auf dem Bus lauschen und davon abhängig entscheiden, wann er senden darf (oder muß). Das ist in der Regel eine SM-MS (Single Master, multiple slaves) Architektur (die nur der Vollständigkeit halber in einem FD Bus nicht möglich ist); es sind aber auch Protokolle denkbar, die im Zweidrahtbus alle Knoten symmetrisch behandeln (z.B. token passing). Solange protokollmässig sichergestellt ist, dass keine zwei Knoten gleichzeitg die Tx Leitung auf aktiv ziehen, ist Alles erlaubt. Jeder RS485 Knoten in einem Bus kann zum reinen mitlesen genutzt werden, solange er die Tx Enable Leitung niemals aktiviert. Den Aktivierungspegel im Bus verlässlich auswerten zu können ist illusorisch. Erstmal ist der (In)aktivitätspegel unterschiedlich für Knoten mit 3,3V und 5V Vcc (das sieht man sehr schön am Oszilloskop), und die maximale Länge eines RS485 Busses darf 1500m betragen, d.h. der Abstand zwischen zwei Knoten (und damit der Übergangswiderstand) kann sehr stark variieren. Wir haben mal mit Collision Detection in der Form experimentiert, dass wir versucht haben, die Rx Enable immer aktiv zu halten und damit zu "merken," ob Jemand anders während unseres Tx versucht zu senden (dann würde nämlich der zurück gelesene Datenstrom von dem gesendeten abweichen). Resultat: Ab einem gewissen Abstand und anderen physikalischen Charakteristiken zum nächsten Knoten war das kollidierende Signal so schwach, dass wir zwar unseren Datenstrom "richtig" zurückzulesen meinten, aber die Kollision war trotzdem da und wurde von allen Knoten jenseits des Nächsten natürlich so gesehen.
:
Bearbeitet durch User
Ruediger A. schrieb: > Es scheint hier etwas Unverständnis darüber zu geben, wie RS485 und dann > auch so ein USB-RS485 Konverter funktioniert... Endlich mal eine qualifizierte Aussage von jemand, der die Funktion begriffen hat - wahrscheinlich bekommst du dafür eine Menge negative Bewertungen. Nützen wird es eh nichts. Georg
Ruediger A. schrieb: > Ein anderes typisches Problem besteht darin, daß manche UART Bausteine > (also im Controller "vor" dem RS485 PHY) per barrel shift register > funktioneren, d.h. logisch kommt der "data register empty" Interrupt > schon bevor das Byte auf den Bus geschoben wird. So viel ich weiss, funktionieren alle auf diese Weise. Deswegen gibt es DataReg_Empty UND Transmit_Complete Flag. Und der "data register empty" Interrupt wird erst angesprungen nachdem DataRegister ins ShiftRegister kopiert wurde. Was ja auch logisch ist - man muss nicht warten bis das ganze Byte rausgeschoben wird - das Ganze wird dadurch viel schneller. Transmit Complete ISR ist aber gerade bei RS485 sehr wichtig - Tx_En wird erst in dieser ISR zurückgesetzt, neue Daten werden aber in DR_Empty ISR nachgeladen. Welche Probleme du damit gehabt hast ist mir unklar. Ruediger A. schrieb: > Den Aktivierungspegel im Bus verlässlich auswerten zu können ist > illusorisch. Erstmal ist der (In)aktivitätspegel unterschiedlich für > Knoten mit 3,3V und 5V Vcc (das sieht man sehr schön am Oszilloskop), Sicher. Nur wird bei RS485 nicht der Pegel, sondern die Differenz zwischen A und B ausgewertet... Schade um die Zeit, das alles abzuschreiben - ein Link wäre besser...
:
Bearbeitet durch User
Marc V. schrieb: > Ruediger A. schrieb: >> Ein anderes typisches Problem besteht darin, daß manche UART Bausteine >> (also im Controller "vor" dem RS485 PHY) per barrel shift register >> funktioneren, d.h. logisch kommt der "data register empty" Interrupt >> schon bevor das Byte auf den Bus geschoben wird. > > So viel ich weiss, funktionieren alle auf diese Weise. Nein. > Deswegen gibt es DataReg_Empty UND Transmit_Complete Flag. > Und der "data register empty" Interrupt wird erst angesprungen > nachdem DataRegister ins ShiftRegister kopiert wurde. > > Was ja auch logisch ist - man muss nicht warten bis das ganze Byte > rausgeschoben wird - das Ganze wird dadurch viel schneller. > Schon. ABER. Nimm z.B. eine MCU mit (e)TPU wie den Coldfire5235. Dort sind UARTs über die (e)TPU realisierbar. In der Konfiguration hast Du das Phänomen, dass der Transmit Complete Interrupt immer noch nicht das Ende des Transmits bestimmt, sondern den Zeitpunkt, an dem das letzte Datenbit auf den Bus geschoben wird. Der ISR kommt also (gerade bei langsameren Baudraten, die erstaunlich oft in der Entwicklung serieller Treiber die problematischsten Fälle sind) immer noch zu früh, was die Abschaltung angeht. Man muss also genau eine Bitzeit abwarten, bevor man umstellt. Zu früh ist schlecht, zu spät aber auch, weil man dann mglw. das erste Bit des nächsten Datenstromes killt. Da kann man sich richtig austoben und sehr kreativ werden. Mit genau diesem Fall habe ich sehr langjährige und "intime" Erfahrungen. > Transmit Complete ISR ist aber gerade bei RS485 sehr wichtig - > Tx_En wird erst in dieser ISR zurückgesetzt, neue Daten werden aber > in DR_Empty ISR nachgeladen. > Nicht in allen Fällen möglich, s.o. > Welche Probleme du damit gehabt hast ist mir unklar. > > Ruediger A. schrieb: >> Den Aktivierungspegel im Bus verlässlich auswerten zu können ist >> illusorisch. Erstmal ist der (In)aktivitätspegel unterschiedlich für >> Knoten mit 3,3V und 5V Vcc (das sieht man sehr schön am Oszilloskop), > > Sicher. > Nur wird bei RS485 nicht der Pegel, sondern die Differenz zwischen > A und B ausgewertet... > Ja, natürlich. Das macht der PHY, und darum geht es ja bei RS485. Darum ging es aber dem TO gar nicht. Die Diskussion ging darum (ausser ich hätte mich komplett verlesen), wie sich von aussen feststellen lässt, wer den Tx aktiv hat (deswegen der Titel "Richtungserkennung"?). Mit dem scope ist ein aktiver Pegel klar von einem inaktiven unterscheidbar, aber wenn Du Dir mal ein Signal angesehen hast, weisst Du auch, dass Signale von zwei verschiedenen Knoten klar unterscheidbar sein können. > Schade um die Zeit, das alles abzuschreiben - ein Link wäre besser... ? Ein link worauf? Wer hat wovon abgetippt?... ich jedenfalls von Nichts. Das war einfach ein braindump meiner noch recht präsenten Erfahrung.
:
Bearbeitet durch User
Ruediger A. schrieb: > Nimm z.B. eine MCU mit (e)TPU wie den Coldfire5235. Dort sind UARTs über > die (e)TPU realisierbar. In der Konfiguration hast Du das Phänomen, dass > der Transmit Complete Interrupt immer noch nicht das Ende des Transmits > bestimmt, sondern den Zeitpunkt, an dem das letzte Datenbit auf den Bus > geschoben wird. Der ISR kommt also (gerade bei langsameren Baudraten, > die erstaunlich oft in der Entwicklung serieller Treiber die > problematischsten Fälle sind) immer noch zu früh, was die Abschaltung > angeht. Man muss also genau eine Bitzeit abwarten, bevor man umstellt. Unsinn, stimmt nicht. Interrupt wird nirgendwo bei letztem Datenbit gesetzt, es wird aber bei allen erst nachdem der Stop bit rausgeschoben ist, gesetzt. Ansonsten hätte ein Protokoll mit 1 1/2 oder 2 Stop bits absolut keinen Sinn. P.S. Gerade nachgeschaut bei NXP:
1 | After the stop bits are sent, if no new character is in the transmitter holding register, the UnTXD |
2 | output remains high (mark condition) and the transmitter empty bit, USRn[TxEMP], is set. |
:
Bearbeitet durch User
Marc V. schrieb: > Ruediger A. schrieb: >> Nimm z.B. eine MCU mit (e)TPU wie den Coldfire5235. Dort sind UARTs über >> die (e)TPU realisierbar. In der Konfiguration hast Du das Phänomen, dass >> der Transmit Complete Interrupt immer noch nicht das Ende des Transmits >> bestimmt, sondern den Zeitpunkt, an dem das letzte Datenbit auf den Bus >> geschoben wird. Der ISR kommt also (gerade bei langsameren Baudraten, >> die erstaunlich oft in der Entwicklung serieller Treiber die >> problematischsten Fälle sind) immer noch zu früh, was die Abschaltung >> angeht. Man muss also genau eine Bitzeit abwarten, bevor man umstellt. > > Unsinn, stimmt nicht. > Interrupt wird nirgendwo bei letztem Datenbit gesetzt, es wird aber > bei allen erst nachdem der Stop bit rausgeschoben ist, gesetzt. > Ansonsten hätte ein Protokoll mit 1 1/2 oder 2 Stop bits absolut > keinen Sinn. Sorry, ich diskutiere das nicht. Ich kenne Controller mit (e)TPUs in grosser Tiefe (ich weiss sogar wie die TPU zu programmieren ist) seit weit über 15 Jahren. Glaub mir, ich weiss, wovon ich schreibe. Es ist ein Fakt, dass ein RS485 Bus bei diesen Controllern das letzte Byte verkrüppelt, wenn die Richtungsumschaltung im Transmit Complete Interrupt passiert. Das liegt daran, dass der Zeitpunkt, zu dem der Empfänger das Bit sampled, in der zu erwartenden Mitte des Bits liegt (unter Anderem dafür ist die Baudrate da, ich bin mir sicher, dass Du das weisst). Der Interrupt kommt aber (wie gesagt je länger die Bitzeit, also geringer die Baudrate, desto verlässlicher) VOR der Samplezeit eines Empfägers! Klar ist das Bit schon fertig, was den UART angeht, aber nicht was den Bus und den Empfänger angeht! Ein UART interessiert sich nicht dafür, welcher PHY dahinter sitzt und ob der Zusatzanforderungen wie eine Tx Enable Leitung hat. Solche Sachen müssen im Einzelfall drumrumentwickelt werden. Es macht aber (unabhängig davon, wer Recht hat - in diesem Fall habe ich Recht ;-)) keinen Sinn, diesen Spezialfall in die letzte Tiefe zu diskutieren. Ich wollte lediglich an Hand eines teasers anreissen, welche Probleme in der Praxis auftauchen können, wenn man als Entwickler tatsächlich damit konfrontiert wird, so etwas wie eine Richtungsumschaltung selber programmieren zu müssen (glaub mir, wir sind da noch lange nicht am Ende... ;-)). Ich habe selber lange daran gezweifelt, dass so etwas wie ein FTDI Konverter da eine tatsächliche Hilfe bringen kann. Aber ja, wenn der weiss, wann genau ein Byte anfängt und wann es verläßlich auf dem Bus ist, erspart einem so ein Konverter viele Stunden Spass und Freude mit Bits und Signalen (keine Ironie, ich mag solche Denksportaufgaben. Meine Auftraggeber aber nicht so gerne).
:
Bearbeitet durch User
Ruediger A. schrieb: > (unter Anderem dafür ist die Baudrate da, ich bin mir sicher, dass Du > das weisst). Der Interrupt kommt aber (wie gesagt je länger die Bitzeit, > also geringer die Baudrate, desto verlässlicher) VOR der Samplezeit > eines Empfägers! Klar ist das Bit schon fertig, was den UART angeht, > aber nicht was den Bus und den Empfänger angeht! Auch Unsinn. Sample rate ist (ungefähr, je nach bit) so 10-16 Mal die Baudrate - nix mit Samplezeit (was ist das überhaupt?) Und was ist mit Parity bit? Kommt auch erst nach dem letzten bit... > Hilfe bringen kann. Aber ja, wenn der weiss, wann genau ein Byte anfängt > und wann es verläßlich auf dem Bus ist. Dafür gibt es Start und Stop bit. > Es macht aber (unabhängig davon, wer Recht hat - in diesem Fall habe ich > Recht ;-)) keinen Sinn, diesen Spezialfall in die letzte Tiefe zu > diskutieren. Welchen Spezialfall? Daß irgendwelche Interrupts bei letztem Datenbit feuern? Lol.
Marc V. schrieb: > Ruediger A. schrieb: >> (unter Anderem dafür ist die Baudrate da, ich bin mir sicher, dass Du >> das weisst). Der Interrupt kommt aber (wie gesagt je länger die Bitzeit, >> also geringer die Baudrate, desto verlässlicher) VOR der Samplezeit >> eines Empfägers! Klar ist das Bit schon fertig, was den UART angeht, >> aber nicht was den Bus und den Empfänger angeht! > > Auch Unsinn. > Sample rate ist (ungefähr, je nach bit) so 10-16 Mal die Baudrate - nix > mit Samplezeit (was ist das überhaupt?) > Und was ist mit Parity bit? > Kommt auch erst nach dem letzten bit... > Ach meine Güte. Jetzt tu nicht so. Selbstverständlich ist mit "letztem Bit" das letzte bit gemeint, das auf den Bus geht - von RS485 aus gesehen das Bit vor der sicheren Umschaltung. Dass das je nach Konfiguration ein Datenbit, ein Stopbit oder ein Parity Bit sein kann, ist doch eigentlich klar, oder? Was das sampling angeht, würde ich mal hier anfangen: https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter speziell: "A UART usually contains the following components: a clock generator, usually a multiple of the bit rate *to allow sampling in the middle of a bit period* ..." das ist meines Wissens nach recht elementares Wissen, wie die Synchronisation in UARTs funktioniert. Ich bin mir sicher, dass Du das auch weisst. Wenn Du meinst, dass ich Unrecht habe, darfst Du mich gerne mal besuchen kommen, und wir tracen einen RS485 Bus mit TPU UART Knoten, in dem die Richtungsumschaltung im TC ISR stattfindet. Das Scope und die Empfängerknoten lassen sich nicht durch Worte wie "Unsinn" oder "Quatsch" dazu bringen, das fehlerhafte Zeitverhalten zu tolerieren. Für mich ist diese Diskussion hiermit beendet. Wir haben mit sehr vielen sehr schlauen Köpfen (ich beziehe mich nicht notwendigerweise damit ein) das Verhalten sehr genau analysiert und eine Lösung gefunden, die ganz genau darauf beruht, die Richtungsumschaltung um genau eine Bitzeit zu verzögern. Die funktioniert nun seit vielen Jahren in unzähligen Installationen sehr sauber und stabil. Solche Fakten und Erfahrungswerte zählen für mich. Ich bin mir sicher, dass auch Du über viel fundierte Praxiserfahrung verfügst, aber es wundert mich doch schon, dass Du einer real life experience hier widersprichst. Schönen Tag noch!
Marc V. schrieb: > und ein kleines Programm schreiben, welches Daten von USBPort_A zum > USBPort_B schickt (und umgekehrt) und gleichzeitig eine Aufzeichnung > mit Richtung und Timestamps erzeugt. Nur mal eine Überlegung. Der erste USB RS 485 Converter ist in Windows COM 1. Der zweite ist COM 2. Jeder halbwegs gute Serielle Monitor, zeigt was empfangen und was gesendet wird. Würde man also COM1 sniffen, würde alles, was von dem ersten Converter kommt und an den zweiten geschickt wird, als "gesendet", und alles was vom zweiten Converter an den ersten gesendet wird, als "empfangen" aufgezeichnet werden, oder sehe ich das falsch? TO müsste dann nur noch die beiden USB Ports irgendwie paaren, an denen die beiden Converter angeschlossen sind. Oder ich irre mich. Hoffentlich erfährt man, wie die Sache ausgeht. Achja: Baudrate muss man ja auch noch irgendwie ermitteln, oder wird diese automatisch erkannt? Kenne mich nur mit RS232 Kram aus.
Johannes schrieb: > Marc V. schrieb: >> und ein kleines Programm schreiben, welches Daten von USBPort_A zum >> USBPort_B schickt (und umgekehrt) und gleichzeitig eine Aufzeichnung >> mit Richtung und Timestamps erzeugt. > > Nur mal eine Überlegung. Der erste USB RS 485 Converter ist in Windows > COM 1. > Der zweite ist COM 2. > > Jeder halbwegs gute Serielle Monitor, zeigt was empfangen und was > gesendet wird. > Würde man also COM1 sniffen, würde alles, was von dem ersten Converter > kommt und an den zweiten geschickt wird, als "gesendet", und alles was > vom zweiten Converter an den ersten gesendet wird, als "empfangen" > aufgezeichnet werden, oder sehe ich das falsch? > Prinzipiell richtig, deckt aber das Szenario vom TO nicht ab, da der peer in seiner RS485 Kommunikation eine externe Hardware ist. Trotzdem stimmt deine Argumentation selbst mit einem COM Port, wenn z.B. über den PC ein USB Port angeschlossen ist, an dessen anderen Ende eine USB->RS485 Konverter hängt. Mit wireshark oder anderen tools läßt sich dann der USB Datenverkehr mitschneiden, und an der Stelle ist er ja noch in Rx und Tx unterscheidbar.
Das timing sollte dann doch im Wireshark erkennbar sein, inbsesondere wenn man den Kommunikationsanfang beim Einschalten mitschneiden kann..
c-hater schrieb: > georg schrieb: > >> Auf dem Bus kann immer nur einer auf einmal senden > > Das ist immer so, bei jedem Bus. Nö. Z.B. auf dem Meter-Bus können Master und Slave gleichzeitig senden. Der Master sendet über Spannungabsenkung, der Slave über Stromanstieg. https://m-bus.com/documentation-wired/04-physical-layer
.. und bei OpenCollector-Schaltungen oder CAN-Transceiver (jedesmal rezessive 0-Pegel) können auch mehrere senden (wobei sich da allerdings der Pegel evt. nicht mehr ändert, alles Definitionssache)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.