Hallo zusammen, ich habe einen Seriellen Bus (für Modellbau), der theoretisch bis zu 16000 Devices zulässt. In diesem Bus gibt es einen Befehl, der es ermöglicht das sich alle Devices mit Adresse, Seriennummer, Software Nummer usw... zu erkennen geben. Die Devices bekommen nicht automatisch Adressen von 1 - 16000, sondern können mit individuellen Adressen versehen werden. Zuerst habe ich überlegt, die Adresse mit einer Wartezeit von 10ms zu multiplizieren und entsprechend nach dieser Wartezeit sich zu identivizieren. Aber das gibt bei bis zu 16000 Adressen enorme Wartezeiten :( Nun wollte ich mal fragen, wie man so eine abfrage von den Devices machen könnte, ohne das es zu langen Wartezeiten kommt. Der Abstand von ca. 10ms zwischen den Nachrichten wird leider benötigt... Mit bestem Dank! Sven
@ Sven (Gast) >Nun wollte ich mal fragen, wie man so eine abfrage von den Devices >machen könnte, ohne das es zu langen Wartezeiten kommt. Mit Teile und Herrsche. Man fragt erstmal eine Breich ab. http://de.wikipedia.org/wiki/Teile_und_herrsche_(Informatik) Hallo, ist hier jemand mit Adresse größer gleich 8000? Wenn dann keiner antwortet, hat man schon mal die Hälfte der Adressen abgearbeitet, und das mit EINER Anfrage. Wenn mehrere gleichzeitig antworten gibt es Kuddelmuddel, ist aber egal, man weiß, das ist jemand. >= 8000 keine Antwort, keiner da. <8000 irgendweine Antwort, da ist jemand Nun das ganze von Vorn. >=4000 jemand da?, irgendeine Antwort. <400 jemand da? keine Antwort. Usw. Das Ganze macht man einfach binär, Sprich man sendet die binäre Adresse mit einer dazugehörigen Maske. Adresse 0b 0000 0000 0000 0000 Maske 0b 1000 0000 0000 0000 D.h. Die Angefragten vergleichen nur die Bits, welche in der Maske auf 1 stehen, damit macht man die Adressbereichsfilterung. Bei 16 Bit braucht man nur 32 Anfragen, um jeden einzelnen Teilnehmer zu finden. Macht 320ms, damit sollte man leben können ;-)
Sven schrieb: > Nun wollte ich mal fragen, wie man so eine abfrage von den Devices > machen könnte, ohne das es zu langen Wartezeiten kommt. Was für eine Antwort erwartest du auf deine Frage? Soll hier jemand schreiben "Versuch es doch mal mit 0x2b anstelle 0x3a als Abfrage-Befehl, der macht das so und so anders" ?? Nur du alleine kennst deinen Bus, und die Befehle, welche abgesetzt werden können, und was die bewirken.
Hallo, erst einmal danke für die Antworten! Das Protokoll in diesem Bus (LocoNet) ist schon festgelegt. Bei diesem Protokoll gibt es nur einen Befehl, wonach sich alle angeschlossenen Devices identivizieren sollen. Also geht Falk's Vorschlag mit der geteilten abfrage leider nicht. Ziel meiner frage ist, ob es jemandem gibt, der schon mal vor einem ähnlichen problem stand und heraus gefunden hat wie man es löst... Mr. Google hat dazu auch nichts passendes anzubieten :( Gruss Sven
Wenn das Protokoll diese Art der ABfrage nicht vorsieht, dann wird es auch nicht gehen. Was sagt denn die Spezifikation dazu?
Hallo Stefan, das Protokoll besteht aus Opcodes und Kommandos... (ich möchte jetzt nicht das ganze Protokoll durchgehen, weil das eigentlich nicht so eine Rolle spielt...) Also wenn die angeschlossenen Devices einen! bestimmten Opcode+Kommando empfangen, sollen sich alle mit ihrer Adresse, Seriennummer usw... zu erkennen geben. Der Device soll nun eine Nachricht versenden mit Opcode, Kommando und den o.g. Daten. Welcher Device nun als erstes Antwortet ist eigentlcih nicht so wichtig, schön ist es aber schon, wenn sich die Devices, ihrer Adresse entsprechend zu erkennen geben. Der abstand zwischen den einzelnen Nachrichten beträgt ca. 10ms... Meine erste idee war eben, Die Adresse mal 10ms zu multiplizieren und nach dieser Wartezeit die Nachrichten zu versenden.... Nun gehen wir mal vom schlimmsten aus: Ich habe am Bus 3 Devices, mit Adr. 1 , 4 , und 16000 .... Nun ist zwischen der Adresse 4 und 16000 eine relativ lange "Wartezeit". Nehmen wir jetzt mal den Device Nr. 16000, er empfängt ja ebenfalls die Nachricht wo sich Device Nr 4 identifiziert hat. Ich müsste jetzt im µC einen Programmteil haben der erkennt, dass nach Device 4 sich niemand mehr zu erkennen gegeben hat, und daher nun der Device 16000 senden kann... Gruss Sven
@ Sven (Gast) >das Protokoll besteht aus Opcodes und Kommandos... (ich möchte jetzt >nicht das ganze Protokoll durchgehen, weil das eigentlich nicht so eine >Rolle spielt...) Ach ne? >Also wenn die angeschlossenen Devices einen! bestimmten Opcode+Kommando >empfangen, sollen sich alle mit ihrer Adresse, Seriennummer usw... >zu erkennen geben. Das ist ein Bus. ALLE Teilnehmer empfangen die Nachricht. Woher sollen die einzelnen Empfänger wissen, dass genau SIE gemeint sein? Das geht nur über eine Adresse. Denn wenn ALLE antworten, wird das ein schönes Durcheinander. Dann müssen alle mehrfach senden, mit zufälligen Wiederholzeiten. So ählich macht es Ethernet. >Der Device soll nun eine Nachricht versenden mit Opcode, Kommando und >den o.g. Daten. Beim LON-Bus gibt es an jedem Teilnehmer eine Servicetaste, damit identifiziert sich das Gerät auf dem Bus. >nicht so wichtig, schön ist es aber schon, wenn sich die Devices, ihrer >Adresse entsprechend zu erkennen geben. Das muss man halt mit dem Busprotokoll machen können. Wenn das das Protokoll nicht hergibt, Pech gehabt. >Meine erste idee war eben, Die Adresse mal 10ms zu multiplizieren und >nach dieser Wartezeit die Nachrichten zu versenden.... Dieser Ansatz scheitert bei 16000 Adressen, es sei denn du hast 160s Zeit, auf alle zu warten.
Sven schrieb: > Welcher Device nun als erstes Antwortet ist eigentlich > nicht so wichtig, schön ist es aber schon, wenn sich die Devices, ihrer > Adresse entsprechend zu erkennen geben. Hallo Sven, schau dir mal die verschiedenen CSMA-Algorithmen an. Für deinen Anwendungsfall wird wohl am ehesten CSMA/CA (http://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_Avoidance ) in Frage kommen. Grüße Stefan
Hallo Falk, >Das ist ein Bus. ALLE Teilnehmer empfangen die Nachricht. Woher sollen >die einzelnen Empfänger wissen, dass genau SIE gemeint sein? Das geht >nur über eine Adresse. Denn wenn ALLE antworten, wird das ein schönes >Durcheinander. Dann müssen alle mehrfach senden, mit zufälligen >Wiederholzeiten. So ählich macht es Ethernet. Das LocoNet ist auch eine art Netzwerk, was nach dem "Peer to Peer" Prinzip arbeitet. Das Timing auf dem Net ist geregelt und auch kein problem für mich... >Dieser Ansatz scheitert bei 16000 Adressen, es sei denn du hast 160s >Zeit, auf alle zu warten. Die Zeit hätte ich schon, wäre Programmiertechnisch auch nicht so kompliziert, aber so richtig schön ist das nicht. Ich dacht eben, ob es da nicht eine elegantere Methode gibt...
Sven schrieb: > Die Zeit hätte ich schon, wäre Programmiertechnisch auch nicht so > kompliziert, aber so richtig schön ist das nicht. Ich dacht eben, ob es > da nicht eine elegantere Methode gibt... Eine elegantere Lösung gibt es immer, sicher auch eine die du einfach nicht siehst oder sehen willst (Das Bus-Befehlsrepertoire hältst du ja zurück). Es gibt also nur zwei Möglichkeiten: 1. du bist zu blöde den Bus richtig zu verstehen bzw. die Befehle richtig zu verwenden, oder 2. der Designer des LocoNet war zu blöde einen anständigen Bus zu konstruieren Wenn wir von letzterem ausgehen, hast du wohl Pech gehabt.
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.