RS485: Busauslegung und alternativ: CAN-Treiber-Chips?

[Beta-User]

Hatte Probleme mit "Dauer-high"-Zuständen. Das passiert mit can-Bausteinen nicht.

[pikim]

Das dürfte durch einzelne Busteilnehmer passiert sein, die sich mit aktivem DE-Pin aufgehängt hatten, kann das sein? CAN-Transceiver verhindern das durch einen internen Timer.

[Beta-User]

...ebend. Genau darum ging es ursprünglich mal...

[pikim]

Genau. Und ein anderer großer Vorteil ist, dass Kollisionen erkannt werden können, indem ständig das Gesendete mit dem Empfangenen verglichen wird. Bei richtigem CAN passiert das Bit für Bit - das geht mit UART leider nicht.

Meiner Meinung nach sollte die Kollisionerkennung aber funktionieren wenn jeder Teilnehmer, der etwas senden will, als erstes seine ID/Adresse sendet und gleichzeitig empfängt. Hat er genau das empfangen was er gesendet hat, dann ist der Bus frei und er kann die eigentlichen Daten senden. Hat er etwas anderes empfangen, dann hat gleichzeitig ein anderer Teilnehmer begonnen zu senden. Über die ID findet damit auch eine Priorisierung statt: je niedriger die ID, desto höher die Priorität des Teilnehmers. Die ID darf logischerweise nicht 2x vergeben werden.

Alles zusammen erfordert aber ein eigenes Protokoll, das diese Eigenheiten berücksichtigt. Besteht hier Bedarf oder Interesse daran? Oder baut egtl. niemand mehr kabelgebundene Sensoren/Aktoren selber?

[frober]

Alles zusammen erfordert aber ein eigenes Protokoll, das diese Eigenheiten berücksichtigt. Besteht hier Bedarf oder Interesse daran? Oder baut egtl. niemand mehr kabelgebundene Sensoren/Aktoren selber?

Von meiner Seite habe ich im Moment keinen Bedarf und gerade andere Projekte am laufen.
Wie es zukünftig ausschaut, man weiß ja nie.

Bezgl. Protokoll, das betrifft doch eher MySensors direkt und müsste dann im Kontroller (Node/GW) verarbeitet werden und weniger auf der Fhemseite.

[pikim]

Richtig. Ich habe mich jetzt auch mal bei MySensors angemeldet und dort einen FeatureRequest gestellt. Die Reihenfolge der Daten ist in MySensors auch schon brauchbar. Es fehlt egtl. nur das Rücklesen und ggf. Abbrechen des Sendens.

[Ranseyer]

Richtig. Ich habe mich jetzt auch mal bei MySensors angemeldet und dort einen FeatureRequest gestellt. Die Reihenfolge der Daten ist in MySensors auch schon brauchbar. Es fehlt egtl. nur das Rücklesen und ggf. Abbrechen des Sendens.

Das ist doch eine gute Sache!


(Warum mir der Ist-Stand gut genug war ? -mySensors war ja ursprünglich ein reines Funk Protokoll. Und beim Funken sind Kollisionen vollkommen normal und werden vom Protokoll ausgeregelt...)

[rob]

@Ranseyer: Das Thema "aktive Terminierung" würde mich auch noch reizen. Hättest Du Muße das doch noch anzugehen? Oder macht das keinen Sinn mehr?

[Ranseyer]

Hi Rob, im Moment eher nicht...
Hast du hier krass starken Bedarf, oder warum fragst du ?
(Die Geschichte ist ja immer ein Kompromiss, und wenn es stabil läuft würde ich nichts ändern. Manchmal sind Sachen nach Verbesserung schlechter bis kaputt :-) )


Aber hier gibt es überigens zum geliebten Bus einen Sehr umfassenden und verständlichen Artikel: https://hackaday.com/2022/04/05/hacker-dictionary-rs-485-will-go-the-distance/

[rob]

Kein starker Bedarf, eher eine Mischung aus Neugier und dem Bedürfnis es von vornherein "richtig" machen zu wollen. Basst scho
Aktuell habe ich das Widerstandsnetzwerk im Einsatz, ohne Einschränkungen/ Ausfälle. Ich frage, weil ich Irgendwann deutlich verlängern muss. Sollte es dann zu Problemen kommen, kann ich u.a. auf frobers Erfahrungsberichte hier zurückgreifen.
Ich hätte gemeint ein aktiver Abschluss wäre das Optimum. Danke für die Klarstellung

VG
rob