Guten Abend, ich habe den Tag nun damit verbracht, mir die Unterschiede zwischen I2C, RS-485, sowie CAN zu Gemüte zu führen (One-Wire ebenfalls), konnte mir aber eine Frage nicht beantworten, nachdem ich mich nun auf RS-485 festgelegt habe. Mein Ziel/Ablauf: - alle Slaves (Sensoren gleichen Typs, Anzahl zwischen 1 und 10) senden nur, wenn diese sich zwischen zwei Schwellenwerten befinden - Die Sensoren werden in einem Netzwerk über ein 2 adriges Kabel (half-duplex) über eine Adapterplatine auf den Raspberry gebracht (wird noch gebaut). - Das Datenpaket hat den Aufbau (falls wichtig für Antwort): SeriaIDWert1Wert2Wert3 (gesamte Nutzdaten mit 19 Bytes Länge) 10St 4St 4St 1St Nun meine Verständnisfrage(n): Können alle Slaves einfach so auf dem RS-485 senden (bspw. SN65HVD72D) und der Master (in dem Fall Raspberry) zeichnet alles auf, was auf dem Bus "los" ist oder muss der Master (Raspberry) die einzelnen Slaves reihum abrufen und denen erlauben, dass sie senden dürfen (die ich dann vorher bekannt machen muss)? Aktuell habe ich half-duplex angedacht mit zwei verdrillten Adern oder ist für diesen Anwendungsfall Full-Duplex notwendig? Habt vielen Dank für eine Antwort, Daniel
Daniel Seichter schrieb: > Aktuell habe ich half-duplex angedacht mit zwei verdrillten Adern oder > ist für diesen Anwendungsfall Full-Duplex notwendig? Full-Duplex geht nur mit 2 Teilnehmern! Bei RS485 darf immer nur ein Gerät senden, alle anderen können die Daten lasen. Wie du das sicherstellt ist dir überlassen.
Daniel Seichter schrieb: > Können alle Slaves einfach so auf dem RS-485 senden (bspw. SN65HVD72D) Sollten sie nicht, denn dann kommt es zu Kollisionen, wenn nämlich zwei gleichzeitig senden. Außerdem wären es dann keine "Slaves". > oder muss der Master (Raspberry) die einzelnen Slaves > reihum abrufen und denen erlauben, dass sie senden dürfen (die ich dann > vorher bekannt machen muss)? So wird ein Single-Master/Multiple-Slave-Bus üblicherweise betrieben. Wenn sich an Deinen Sensoren nichts ändert, könnten sie auf eine Anfrage des Masters auch mit einem kürzeren "nix los"-Paket antworten, statt ein vollständiges Paket zu senden. Das verkürzt den Abfragezyklus auf dem Bus. Dafür genügt eine Halbduplex-Verbindung, also ein RS485-Kanal. Beachte, daß die Sender-/Empfänger-Umschaltung des RS485-Treibers ein kritischer Punkt ist. Wenn Du keine UART-Hardware verwendest, die das von sich aus erledigen kann, musst Du das in Software selbst ansteuern. Das bedeutet, daß Du nach dem Senden von Daten abwarten musst, bis die Daten auch wirklich das Schieberegister der UART verlassen haben, bevor Du umschaltest. Beim Rpi bietet sich der Gebrauch eines USB-RS485-Wandlers auf Basis eines FT232 an, der beherrscht die Sender/Empfänger-Umschaltung in Hardware.
Hallo, danke für die Antworten und dem Hinweis auf den FT232. Habe mir für den RS485 Treiber den TI SN65HVD72D ermittelt, da er u.a. mit der Versorgungsspannung von 3,3V des Raspberry zu betreiben ist, sowie der dahinterliegende ATmega328P-AU ebenfalls damit betrieben werden kann. Zusammenfassend: Somit muss ich nun die ID der Slaves im Master eintragen (diese würde der serialID entsprechen), der fragt reihum die Slaves ab und sobald einer etwas zu melden hat, sendet dieser die Daten in den Bus und der Master greift diese ab. Ich werde mir hier ggf. etwas überlegen, um neue Sensoren (bzw. Mit geänderter serialID) mit etwas in der Art von "bin neu hier lieber Master, hast Du mich?" automatisch hinzufügen zu können. Bzgl FT232 werde ich morgen das DB ansehen, da ich die BUS-Platine erst noch aufbauen/anfertigen muss und mir noch das ein oder andere Bauteil fehlt :( Danke nochmals und einen schönen Abend, Daniel
Daniel Seichter schrieb: > Ich werde mir hier ggf. etwas überlegen, um neue Sensoren (bzw. Mit > geänderter serialID) mit etwas in der Art von "bin neu hier lieber > Master, hast Du mich?" automatisch hinzufügen zu können. Ist das bei der begrenzten Anzahl von Slaves am RS485 (offiziell 32) nicht ein bisschen zu aufwendig? Ein 8-Bit-Wert ist zur Adressierung ausreichend, und den kann man mit 'nem DIP-Schalter oder zwei 4-Bit-Drehschaltern am Slave einstellen. > Bzgl FT232 werde ich morgen das DB ansehen Das lohnt, denn darin ist eine Beispielschaltung für die Ansteuerung eines RS485-Treibers enthalten.
Wenn Du nicht mehr als 8 Bits zur Adressierung verwendest, dann ist es sicher praktikabel, dass der Master einfach alle möglichen Adressen nacheinander abfragt und schaut, ob er eine Antwort erhält. Ansonsten brauchst Du eine Kollisions-Erkennung mit Lösungs-Algorithmus. Wie gesagt finde ich da den Ansatz bei CAN schön einfach.
Das dynamische Hinzufuegen von neuen Stationen ist nicht trivial. Der Codieransatz mit Dipschaltern sollte zumindest ueberlegt werden. Falls die Position des Slaves wichtig ist, ist das der beste Ansatz. Meist sollte man ja wissen welcher Slave wo steht. Sei es fuer Wartungsarbeiten, oder man muss irgend eine Funktionalitaet einem Standort zuweisen. Kollisionserkennung ist nicht ganz so einfach.
Stefan schrieb: > Wenn Du nicht mehr als 8 Bits zur Adressierung verwendest Wozu sollte man das tun? "Offiziell" sind nur 32 Teilnehmer möglich, auch inoffiziell wird es schwierig, mehr als 100 zu betreiben. Also reichen 8 Bit. Eine Möglichkeit zur Adresszuweisung ohne Kollisionserkennung, die allerdings Zugang zu den einzelnen Slaves erfordert, könnte wie folgt aussehen: Jeder Sensor bekommt einen "Anmeldetaster". Wird der gedrückt, reagiert der Slave auf eine spezielle im Protokoll festgelegte Adresse. Der Master sendet in seinem Abfragezyklus alle ihm bekannten Adressen und diese Spezialadresse. Reagiert ein Slave auf diese Adresse, teilt der Master ihm seine neue, dauerhaft zu verwendende Adresse zu, die der Slave daraufhin in seinem EEPROM (oder wo auch immer) unterbringt und fortan verwendet. Der Master erweitert seine Liste von bekannten Adressen - fertig. Somit ist für die Inbetriebnahme an jedem Slave einmal der Anmeldetaster zu betätigen. Das kann gegebenenfalls auch vor Installation der Slaves an ihren jeweiligen Betriebsorten geschehen.
Rufus Τ. Firefly schrieb: > Wozu sollte man das tun? "Offiziell" sind nur 32 Teilnehmer möglich, > auch inoffiziell wird es schwierig, mehr als 100 zu betreiben. Also > reichen 8 Bit. Nö. Es gibt auch 1/8load-Transceiver. Funktioniert zuverlässig. Schon mit >200 Teilnehmern aufgebaut. Aber 8Bit-Adresse reicht trotzdem.
Daniel Seichter schrieb: > Ich werde mir hier ggf. etwas überlegen, um neue Sensoren (bzw. Mit > geänderter serialID) mit etwas in der Art von "bin neu hier lieber > Master, hast Du mich?" automatisch hinzufügen zu können. Ich habe das folgendermassen geregelt: der Master hat eine Tabelle für z.B. 32 oder 64 Slaves, ob diese online oder offline sind. Der Master fragt die online Slaves reihum ab, antwortet einer nicht mehr, wird er offline (die anderen liefern Daten). Nach dem Durchgang fragt der Master noch einen der offline Slaves ab (auch reihum), antwortet der, wird er online. Das Abfragen neuer Slaves dauert länger, weil meistens die maximale Antwortszeit abgewartet werden muss, daher frage ich nur immer einen ab. Die Folge ist, dass es bis zu n Zyklen dauert, bis ein neuer Slave online ist. Man kann auch mehr abfragen, dementsprechend wird die Zeit bis zum Einloggen kürzer und dafür die Zykluszeit länger. Ganz nach Bedarf. Funktionierende Slaves sollten IMMER antworten, notfalls eben mit "Nichts los hier", sonst wird Zeit verschwendet. Gruss Reinhard
Hallo, in CAN habe ich mich auch schon eingelesen, allerdings ergab die Suche nach Treibern, die über Txd/RxD das Signal auf den CAN-Bus bringen können, kein wirkliches Ergebnis. Oder sind hier immer bereits CAN-fähige µC erforderlich? Nichts desto trotz finde ich den Lösungsansatz über "Anmeldetaster" eine gute Idee. Somit könnte man auch, wenn man einen Sensor auf einen anderen Master setzt, diesen wieder zurücksetzen (muss ja nur verhindert werden, dass der Taster versehentlich gedrückt werden kann). Nach DIP-Schalter-Beispiele hatte ich gestern ebenfalls bereits gesucht, war aber, wahrscheinlich aufgrund falscher Suchbegriffe oder falschen Vorstellungen von mir, nicht von Erfolg gekrönt. Wie muss ich mir das Vorstellen? Setze ich durch die unterschiedlichen Stellungen eine Adresse und der µC kann diese Adresse dort auslesen oder verbindet man die DIP-Schalter mit bspw. 8 Ports und je nach Zustand (0/1), wird daraus die Adresse festgelegt? Könnte man, wenn über einen Port(eine Leitung möglich, die DIP-Schalter nicht auch direkt am Master anbringen und somit, je nach angeschlossener Buchse, die Adresse stets gleich halten (Buchse 1 = Adresse 1, Buchse 2 = Adresse 2,...)? Danke für eure Hilfe, Daniel
Daniel Seichter schrieb: > Wie muss ich mir das Vorstellen? Setze ich durch die unterschiedlichen > Stellungen eine Adresse und der µC kann diese Adresse dort auslesen Am transparentesten (soll ja einfach bedienbar sein) ist es natürlich, wenn du z.B. bei 64 Slaves ein 6poliges Mäuseklavier verwendest und jeder Schalter einem Adressbit entspricht. Die Schalterstellung muss der Prozessor beim Starten einlesen und als seine Adresse benutzen. Noch anwenderfreundlicher wären 2 Dezimalschalter. Hat der Slave eine Bedien-Schnittstelle, kann man die Adresse auch eintippen. So oder so ist der Nachteil, dass man Zugang zum Slave haben muss (Administration by Walking) und beim Schalter ev. sogar das Gerät öffnen muss - aber das kann auch ein Vorteil sein, damit nur qualifizierte Leute was ändern. Die erwähnte automatische Vergabe von Adressen ist natürlich hinderlich bei einer Fehlersuche. So hat eben alles seine Vor- und Nachteile. Gruss Reinhard
Guten Abend zusammen, habe mich nun für folgende Lösung entschieden: - RS-485 Schnittstelle - Taster für die Initialisierung der Slave Adresse (Abfrage bei Master und Speicherung in Slave) - Initialroutine sendet die vorher selbst definierte Seriennummer, die wiederum im Master bzw. RPi (also Raspberry) gespeichert wird. (1:1 Zuordnung Bus-ID mit Seriennummer) - auf dem RPi läuft über den Webserver eine Statusseite, die mir die Slaves, deren Seriennummer, sowie weitere Informationen (manuell in Web eingetragen) auflistet und ich deren Status somit prüfen kann - Mit Hilfe des Taster, realisiere ich auch die Abmeldung eines Sensors am BUS (quasi Reset) Die Zusammenführung der Daten werde ich dann in einem neuen Projekt durchführen. Nun gilt es, den Schaltplan voll fertig zu stellen und mich ans Platinendesign zu machen :) Wünsche einen schönen Abend und Danke für Eure Anregungen. Die haben mir weitergeholfen!! Daniel
wenn Du immer nur einen neuen Slave anschließt kannst Du dir den Taster auch sparen: jungfräuliche Slaves haben eine bestimmte Adresse die der Master regelmäßig abfragt, dann bekommen sie vom Master die "richtige" Adresse und du kannst den nächsten Slave anschließen usw.
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.