freebus.org

Hallo Ihr Freebus'ler,

erst einmal ein dickes *DANKE* an die Entwickler hier - toll, was Ihr auf die Beine gestellt habt!

Ich möchte mich nun auch näher mit dem Thema Freebus auseinandersetzen, da bei mir ein EFH-Neubau mit KNX ansteht und ich gerne das ein oder andere DIY-Gerät auf Freebus-Basis mit einbauen möchte. Besonders das RS-Interface hat es mir angetan, dieses würde ich gerne zu Kommunikation mit einem µC einsetzen. Dazu werde ich dann auch das ein oder andere Gerät hier vorstellen, so dass im Sinne einer Community auch alle etwas davon haben.

Ein paar Fragen habe ich zum RS-Interface, ich hoffe Ihr könnt mir helfen:

- Welchen Zweck hat die Möglichkeit, das Interface mit einer physikalischen Adresse zu versehen? Muss man diese in der ETS eintragen - und falls ja, als welchen Typ? Das habe ich noch nicht verstanden. Zur Kommunikation mit dem Bus bräuchte ich die Möglichkeit, z.B. von einem Sensor an anderer Stelle im Bus einen ASCII-Text (EIS15) an das RS-Interface zu senden.

- Ist es möglich, vordefinierte Gruppenadressen in der internen Tabelle zu speichern? Das wäre super, denn bei mehr als 265 vorhandenen Gruppenadressen im Bussystem würden ja neu hinzukommende nicht mehr angenommen. Gerade für die Anbindung an einen µC wäre das Interface z.B. für Visualisierungszwecke optimal - es könnte dann als "Zwischenspeicher" für vordefinierte Gruppenadressen dienen. Diese könnte man dann auslesen, ohne den Bus mit read_value_requests zu belasten.

Vielen Dank schonmal vorab!

P.S.: Ich beteilige mich auch gerne in Richtung Hardwaredesign - Eagle-Erfahrung ist vorhanden!

_________________
Gruß
Stefan

Hi Stefan,

die PA braucht das RS Interface, wie jedes andere Gerät auch. In einem Telegramm ist immer auch die Absender Adresse enthalten. In der ETS muß man nichts eintragen, lediglich dem RS-Interface eine freie Adresse geben.

EIS15 kann das RS senden und empfangen, also no prob.

Vorbelegen kann man die Tabelle nicht. Aber 256 GAs müssen auch erstmal zusammenkommen.

Gruß
Kubi

Hallo Kubi,

vielen Dank für die Erläuterung!

Ich baue nun mal alles zusammen...ich glaube, es wird noch mehr an Fragen kommen

_________________
Gruß
Stefan

Hallo,

ich hätte da noch eine Frage zum RS-Interface:

Ich möchte dieses zur Anbindung eines µC nutzen. Im Normalfall werden ja alle vom Bus empfangenen Telegramme seriell an den µC weitergereicht.

Da man dem Interface ja eine physikalische Adresse (PA) vergeben kann, wäre folgende Funktion für mich in Verbindung mit den EIS15-Telegrammen sehr interessant:

- Das Interface "lauscht" am Bus. Wird ein EIS15-Telegramm im Bus an das RS-Interface gesendet (welches per PA ja eindeutig identifizierbar ist), wird der Inhalt des Telegramms (String mit max. 14 Zeichen) an den µC ausgegeben. Der führt dann eine entsprechende Funktion aus, die in dessen Anwendungssoftware hinterlegt ist.

Was meinen die Profis? Wäre das möglich?

Problem im Moment:
Die momentane RS-Firmware sieht ja vor, dass ALLE Telegramme auf dem Bus über das Interface seriell ausgegeben werden. Da sind in meinem Fall natürlich jede Menge Daten dabei, die gar nicht für den angehängten µC bestimmt sind. Diese würde ich gerne blocken, so dass nur die für die vergebene PA bestimmten Telegramme durchkommen.

Vielen lieben Dank vorab für Eure Hilfe!

_________________
Gruß
Stefan

Hallo stejak,

also ich habe jetzt noch nicht so arg viel mit den EIB Bus in eigentwicklung gemacht, aber von CAN Bus her kenne ich das ja auch.
Es muss doch für dich ein leichtes sein den Apllikations µC deinerseits einen einfachen Filter einzubauen, ich meine dein µC taktet ja bestimmt nicht
gerade langsam und für den ist das Filter nach Adresse ja ein langweiliges Kinderspiel ?!

Oder habe ich jetzt was nicht bedacht?

Gruß

Freakster!

Hallo Freakster,

theoretisch könnte man das natürlich auch im µC filtern. Das könnte jedoch bei hohem Datenaufkommen im Bus zu Problemen führen - der µC sollte sich hauptamtlich um die Verabeitung der für ihn bestimmten Telegrammen kümmern.

Eine definierte Sender-Empfänger-Konstellation würde mir besser gefallen, so wie man das bei KNX gewohnt ist

Trotzdem danke für den Hinweis!

_________________
Gruß
Stefan

Hallo Stefan,

also um die Filterung zu verdeutlichen: im Telegramm ist immer die PA des Senders und die GA des/der Empfänger(s) enthalten. Beim Empfang eines Telegramms muß man also die GA filtern. Eine Filterung anhand des EIS Typs ist in der regel nicht möglich, da dieser nicht irgendwie codiert im Telegramm enthalten ist.

Im RS-Interface ist keine Filterung vorgesehen. Aber da dein µC Programm vermutlich eh über Interrupt einen Empfangspuffer füllt, braust du ja nur die beiden Bytes der GA zu prüfen. Das sollte m.E. kaum Rechenzeit verbrauchen.

Gruß
Kubi

Hallo Kubi,

vielen Dank für die Erläuterung!

Ich bin mir ehrlich gesagt nicht sicher, mit welcher Buslast (Telegramme/sec) im Praxisbetrieb zu rechnen ist. Die Gefahr in meiner Anwendung ist halt, dass der µC vor lauter Prüfen der ankommenden Bytes andere Dinge nicht mehr rechtzeitig ausführen kann.

Wenn ich das alles richtig verstanden habe, besteht ein Telegramm aus 7...23 Bytes, wobei das Byte 3+4 dann die Zieladresse darstellen (das wäre in meinem Fall das RS-Interface). Sobald in einem ankommenden Telegramm diese beiden Bytes mit der zuvor programmierten PA des RS-Interface übereinstimmen, müsste ich im DRL-Byte 6 die Länge der Nutzdaten finden und dann in den Bytes 7-22 die Nutzdaten (bei EIS15), die ich dann weiterverarbeiten kann.

Die Zieladresse kann nach meinem Verständnis auch eine PA sein und nicht zwangsläufig eine GA. Wäre es da nicht relativ einfach, durch eine kleine Modifikation der RS-Software die Filterung mit einzubauen? Das würde sich in meinem Fall natürlich anbieten und der LPC922 wertet die ankommenden Daten doch eh schon aus, um diese dann an die UART zu schicken. Das dürfte dieser dann nur tun, wenn die programmierte PA des RS-Interfaces mit Byte 3+4 im Telegramm übereinstimmen...

Was meinst Du?

_________________
Gruß
Stefan

Hi Stefan,

eine PA als Zieladresse gibt es nur bei sog, unicast-Telegrammen. Ein EIS15 ist aber ein Multicast, somit ist die Zieladresse eine GA. Du kannst die Filterung natürlich auch in die Soft des RS-Interface einbauen. Das EIS15 muß übrigens nicht zwangsläufig 15 Zeichen enthalten, es kann auch nur eines sein.

Gruß
Kubi

Hallo Kubi,

nochmals ein dickes DANKE für die Erläuterungen - dass ein EIS15-Telegramm nur an GA geht, wusste ich nicht

Wie schätzt Du denn den Aufwand ein, die gewünschte Filterung bereits in das RS-Interface zu integrieren?

Wenn Du das hinbekommen würdest...das wäre superklasse und ich wäre Dir zu großem Dank verpflichtet. Wenn ich etwas in irgendeiner Form beisteuern könnte - ich bin dabei

Viele Grüße und danke nochmal für Deine Hilfe! Der FREEBUS ist mit großem Abstand das beste Projekt, dass ich in den letzten Jahren kennengelernt habe....ich glaube, das der süchtig macht

_________________
Gruß
Stefan

Ich sehe ein,

7 Tage ohne Rückmeldung ist auch eine Antwort. Schade.

_________________
Gruß
Stefan

So macht das keinen Spaß! Bin dann tatsächlich raus aus der Nummer!

Hallo Andreas,

wie in meinem anderen Thread beschrieben: dickes *sorry*!

Ich bin hier mit der falschen Erwartungshaltung ins Forum eingestiegen, das ist ganz eindeutig mein Fehler. Ich verstehe und akzeptiere Deine Reaktion - schade, denn ich hätte mit der Implemetierung der gewünschten Funktionen viele neue Ideen in Richtung Sensorik/Aktorik umsetzen können. Da wären auch bestimmt für andere User hier interessante Sachen dabei gewesen.

_________________
Gruß
Stefan

Warum implementierst du das nicht einfach slebst wenn du das benötigst?
EIS 15 und 5 sind auch nur implementiert weil ich das brauchte und da hab ichs halt gemacht(mit Kubis und oldis Hilfe). Und nun haben alle was davon.
Also daran solls jetzt nicht scheitern...

Das Problem dabei ist, dass ich hardwaremässig ganz fit bin, bei der Software aber leider überhaupt nicht. Das würde vermutlich erstmal Monate benötigen, um die einzelnen Softwaremodule im µC zu verstehen.

_________________
Gruß
Stefan