freebus.org

Hallo Community,

ich habe nun etwas mit dem bisherigen LPC-RS-Interface rumgespielt und stelle fest, dass für meine Anwendungen doch ein paar Features fehlen. Zum einen wären das KNX typische merkmal die Adresse des Gerätes über die ETS setzen zu können. Also Knöpfchen drücken und programmieren. Weiterhin ist durch die starke Abstraktion der Nachrichten nicht zu erkennen von wem ein Telegramm kommt oder welchen Typ es hat. Das lässt sich bisher an der Ausgabe nur erraten.

Daher möchte ich (wenn ihr mich lasst, mein SVN Zugang ist noch nicht freigeschaltet) die LPC-RS Firmware um ein paar Features erweitern, so dass wirklich jeder Mikrokontroller (so nenne ich im folgenden mal das nachgeschaltete Gerät) an den Bus gebracht werden kann. Dazu will ich folgendes ergänzen:

- Programmieren der Adresse über den Bus (KNX typisch)
- Weiterleiten von Nachrichten als generisches Binärformat

- Es muss nicht jeder Datentyp in der LPC-Firmware implementiert werden
- Alle Informationen stehen dem Mikrokontoller zur Verfügung

- Unicast Nachrichten werden weitergeleitet und auf dem Bus bestätigt

- Das ermöglicht die Programmierung des EEPROM vom Mikrokontroller über den Bus

- Mikrokontroller sendet Nachrichten ebenfalls im Binärformat

- Ermöglicht das bestimmen aller Parameter und sogar Unicast Telegramme
- Optional: LPC ergänzt notwendigen CRC

Das sind meine bisherigen Ideen dazu. Das schöne dabei wäre, dass damit andere Bastler komplette Geräte mit einem beliebigen Mikrokontroller selber bauen könnten (sogar Arduino ließe sich damit leicht anschließen). Was haltet ihr davon?

Gruß,
eJonny

Erst mal schön das sich jemand dem RS Annehmen will.
Ich habe schon mehrfach RS KNX Gateway Anbindungen Entwickelt für große Steuerungssystem und hier auch ein Protokoll gemacht.
Daher mal mein Wissen dazu.
- Bei KNX ist der Absender vollkommen unwichtig. Es zählt nur die Gruppen Adresse, nicht die Physikalische !!
- ALLE Datentypen (EIS-Typen) fallen auf ein paar Wenige Grundtypen zurück: 1 Bit, 4(6)-Bit, 1 Byte, 2 Byte, 3 Byte, 4 Byte, 14 Byte Text, 14 Byte Hex Text.
Mit diesen Datentypen konnten wir bisher ALLE Anforderungen erfüllen die im Professionellen Steuerungs Bereich notwendig waren.
- Die Eigentliche Umsetzung von z.B. EIS5 zu Fließkomma Werten, macht dann die Jeweilige Steuerung.
- Wozu man von einem Controller ein Gerät Programmieren muss, ist mir nicht klar. Die Anforderungen hatte ich in meinen 11 Jahren Steuerungstechnik noch nie.

Es wäre Sinnvoller, wenn man eine Filtertabelle einbauen könnte, die einem erlaubt :
a) Festzulegen, welche Adressen man überhaupt möchte
b) Die Gruppenadressen in einfache Integers übersetzt. Das spart Platz im uC und vereinfacht das Handling.

Ein Beispiel wie ich das bisher kenne (Etwas Prosa):
Erstellen Filtertabelle:
ADD=1:SWITCH:1/1/0
ADD=2:2BYTE:2/1/1

Ansteuern:
SET=1:1
SET=2:2045

Rückmeldung vom RS:
SET=1:0
SET=1:2044

Fehlermeldung:
ERROR=1:Busy
ERROR=2:NACK
Ein ACK wird nicht gemeldet, da normal

Ich denke es ist klar wie das Setup geht. Der Erste Parameter nach dem "=" ist die ID die statt der Gruppen Adresse genutzt wird.
Das Parsing der Rückmeldung ist dadurch sehr einfach und es wird auch Platz im uC Flash und RAM gespart.
Ab dem Einrichten der Filtertabelle werden auch nur die benutzten Adressen gemeldet. Das Verringert den seriellen Traffic und schon den uC
Und Wenn ich jetzt sage, das Protokoll hat sich 1000-Fach bewährt, ist das sicher nicht gelogen

Ich wüsste dann keinen Grund, warum man das Binärprotokoll braucht um die Rohdaten des EIB/KNX durch zuschieben.

Gruss
J.Sachs

Ich kann mir durchaus Anwendungen vorstellen, in denen der Absender wichtig sein kann. Wenn diese so unwichtig wären, dann wären sie auch nicht im KNX spezifiziert worden.

Zu den Datentypen: Ja, viele sind sich ähnlich. Daher will ich die Verarbeitung der Daten auch nicht in der Firmware haben. Soll doch das angeschlossene Gerät entscheiden, was es damit macht.


Da hast du mich nicht verstanden. Ich möchte das Gerät über die ETS oder eine andere Form über den Bus parameterisieren können. Das ein Controller ein anderes Gerät programmiert, ist allerdings auch denkbar und sollte nicht durch Abstraktion verwehrt werden.


Das beschriebene Protokoll ist ein ASCII Protokoll und verursacht allein dadurch schon 10% mehr Overhead als bei einem Binärprotokoll. (ASCII = 7-bit vgl. 8-bit Binär) Demnach ist ein Binärprotokoll nicht nur platzsparender sondern auch einfacher zu verarbeiten (Bitoperationen, Shifts, usw.). ASCII ist für Menschen gemacht, Binär für Maschinen. Das durchreichen der KNX Telegramme im Binärformat hätte zum Vorteil, dass zum einen die Firmware sehr schlank sein kann und zum anderen so generisch, dass Anwendungen in keinster Weise beschränkt werden. KNX Telegramme sind meiner Meinung nach einfach genug aufgebaut um damit auf einem Mikrokontroller zu arbeiten.

eJonny

Ich denke ein verarbeiten und rückmelder der GA in 2 Byte form sollte kein problem darstellen, ist ja eher einfacher.
Das fbs01... wurde gewählt um die Übertragung sicherer gegen versehendlichen Tipp Müll zu machen.
Das RS interface ist ja so eine Terminal EIB Schnittstelle.

Programmieren tut man dann aber doch mit der FT1.2 soft.

_________________
LG
Andreas

Hallo!

Ich hätte einen Erweiterungswunsch für die RS-Firmware:
Meine Wetterstation sendet Datum und Uhrzeit, welche die aktuelle Version der RS-Firmware nicht protokolliert.

Beides sind 3-Byte-Werte - siehe Bilder




Ich würde die Werte für die Weiterverarbeitung in einem angeschlossenem Controller(mbed) benötigen.

Danke und Schöne Grüße- Chary

wäre eine Änderung auf 4 byte, wenn schon. Dann halt nur noch 127 Telegramme speicherbar, oder wir setzen ein serielles eeprom rein.

_________________
LG
Andreas

Hallo!

Ja, die Anzahl der Bytes hat mich auch verwirrt. Im Feld Datenlänge steht 4 Byte aber im Feld Daten sind nur 3 Bytes angeführt. Wie auch immer.

Die Funktion zum abrufen der gespeicherten Telegramme benötige ich nicht, daher hätte ich damit kein Problem . Mir ist schon klar, dass das andere Anwender anders sehen können.

LG Charly