eibd(war bcusdk) Fork -> knxd

[Sven aus Hannover]

Hallo Zusammen,
ich lese als KNX-Neuling hier jetzt schon länger mit, mir fehlt jedoch der aktuelle Status zu diesem Thema. Könnt ihr mir bitte kurz sagen ob das Programmieren von KNX-Geräten inzwischen wieder von der ETS5 über den EIBD funktioniert? Als KNX-IP-Interface möchte ich den RPi mit busware Pigator und KNX-Module einsetzen.
Mit Wiregate soll es inzwischen schon wieder funktionieren und der nutzt doch sicherlich auch den eibd.
Vielen Dank schon einmal.

[Smurf]

Es gibt im github jetzt einen neuen Zweig namens "next".

Neue Features:

Die Option "-E" wählt einen Adressbereich aus, "-E 15.0.2:10" z.B. die Adressen 15.0.2 bis 15.0.11 inklusive, der an Klienten vergeben wird, die sich mit dem knxd verbinden. Die ausgewählte Adresse wird denen nicht mitgeteilt (dafür gibt es entweder keine Mechanismen oder ich habe sie nicht gefunden), sondern es wird lediglich der Absender 0.0.0 ersetzt. Unnötig zu sagen, dass dieser Adressbereich sonst nirgends am Bus verwendet werden sollte.

Multicast-Loopback ist wieder an. Das heißt, man kann jetzt einen zweiten knxd (oder irgendwas Anderes, das KNX redet) als Multicast-Client auf demselben Rechner laufen lassen wie ein knxd, der via "-DTRS" als Multicast-Server agiert.

Damit das einigermaßen sauber ins Programm passt, waren mehr Umbauarbeiten notwendig, als mir lieb ist. Insbesondere "groupswrite" und Konsorten machte Probleme, weil der seine Verbindung schließt, bevor knxd das Paket überhaupt verarbeiten kann. Deswegen werden die Layer2-Objekte jetzt über shared_ptr verwaltet, d.h. es wird ein aktueller C++-Compiler benötigt. Sorry – aber ich habe keine Lust, selber einen Referenzzähler zu implementieren und zu debuggen …

[Smurf]

Soweit ich weiß, gibt es libusb für Windows.

Es ist schon sinnvoll, auch die TCP-Verbindung zum knxd und/oder einen UDP-Tunnel zu unterstützen. Ich habe hier auch noch zwei WLAN-Router, die bei Multicast jedesmal Mist bauen, sobald irgendwelche nicht-trivialen Dinge passieren. :-/

[l0wside]

Hallo Nagilo,

bei mir sind neben dem IP-Gateway zwei weitere im Einsatz: zum einen das Erweiterungsboard für den Beaglebone von Robert (TPUART2 seriell), zum anderen ein USB-Stick von Wiregate (für die Entwicklungs-Linie). Beide laufen mit eibd.

• Ließe sich der Backend-Code, also die Treiber, von knxd/eibd bei dir denn integrieren?
• Ist die USB-Ansteuerung von Linux überhaupt sinnvoll nach Windows zu portieren?

Max

[Smurf]

Ich würde das Ganze etwas elaborierter machen. Schließlich brauchen wir in Zukunft backend-spezifische Optionen zB für das Filtern von Gruppenadressen. Die Idee, aus der .INI-Datei die Argumente zu generieren, halte ich da für wenig zielführend.

Also sowas wie

[global]
backends=foo,bar
# wenn fehlt: automatisch alle ansonsten nicht behandelten Sektionen, in denen driver= vorkommt
eibaddr=0.0.99
addrpool=0.0.100:30

[debug]
trace=namen,für,die,einzelnen,Layer
# oder
trace=0x1ff
log=error – oder warn,info,debug

[foo]
driver=tpuarts
device=/dev/ttyBLA
monitor=no

[bar]
driver=multicast
address=224.99.99.99
port=12345
route=yes
tunnel=yes
discover=yes

Ja, es soll vorkommen, dass jemand gar kein IP nutzt. Ich werde hier auch zwei Pi einsetzen, die einfach irgendwo auf dem Schrank liegen, irgendwas monitoren, und die gar kein IP haben. Nur KNX.
IP-über-KNX lassen wir lieber von vornherein bleiben …

[nagilo]

Hi,

wollte mich hier nur kurz einmischen, weil -l0wside korrekterweise erwähnt hat, dass meine libknx nur multicast unterstützt. Wenn das das problem ist bau ich das gerne ein. Die libknx hat die thread problematik über die boost::thread gelöst, die ab c++11 fast identisch im standard sind.

Ob es sich lohnt was anderes als ip einzusetzen , also usb oder rs232 würde mich aber interessieren. Nutzt jemand KEIN ip gateway ? Und falls das so ist , warum ?

Gruss

[l0wside]

Meinst du bzgl. Init den Code in knxd.cpp? So recht überzeugt bin ich von der Trennung in parse_opt() ja noch nicht. Beim Lesen der argp-Routinen ist mir wieder eingefallen, warum ich so was meistens händisch gemacht habe (keine Kritik an dir, ich finde argp nur einfach zum Fürchten).
Wenn ich den Code richtig verstehe, genügt es, im argp-Code die Ini-Datei zu ermitteln (da wäre mir Hilfestellung lieb) und dann das Ergebnis in arg zu schreiben. Klingt lösbar.
Schreibt jemand einen Vorschlag für eine ini-Datei? Als Abschnitte fielen mir am ehesten "Backend" und "Options" ein, aber ich habe bestimmt was übersehen.
XML oder JSON gingen auch noch, wären aber vermutlich übertrieben.

Max

[Smurf]

Äh … es gibt keinen bestehenden Parser. Die Befehlszeile wird mit einem langweiligen getopt linear abgearbeitet.

Die Befehlszeilenanalyse habe ich aber schon einigermaßen (un)sauber vom Zusammenbau der beteiligten Objekte getrennt, so dass ein .INI-Parser letzteren Code eigentlich nur aufrufen muss.

pthreads4w sieht ziemlich vollständig aus. Finde ich gut.

Was mir an der Stelle außerdem vorschwebt, ist eine saubere Trennung zwischen I/O-Code auf der einen und Ereignis/Queue-Behandlung auf der anderen Seite. Für I/O sind Threads praktisch. Aber den Rest kann man radikal zusammenstreichen -- der aktuelle Code hat für jeden L2 einen eigenen Thread, der auf mindestens eine Queue und ein Ereignis lauscht (nämlich das "das 'beende diesen Thread'-Semaphor wurde gesetzt"-Ereignis). In fast allen Fällen ist das ziemlich nutzlos, zumal das Datenpaket jedesmal kopiert wird.

[l0wside]

Da habe ich mit meiner Frage ja was losgetreten...

pthreads scheint es auch für Windows zu geben, http://sourceforge.net/projects/pthreads4w/. Ob das "large subset" ausreicht, kann ich nicht beurteilen. Allerdings dürften die Philosophieunterschiede Windows/Unix bei Threads geringer sein als bei Prozessen. Schließlich muss man hier kein fork() und exec() nachbilden.

Einen .ini-Parser würde ich ggf. noch beisteuern, das sollte mit überschaubarem Aufwand zu machen sein. Optimal fände ich, den bestehenden Parser so zu erweitern, dass er .ini und das bestehende Format automatisch erkennt und beides verarbeiten kann.

Max

[Zepp]

Soweit ich weiß existiert das git-repo erst ein paar Monate, du wirst da wahrscheinlich nicht viel sehen.
Da sind die umfangreichen release-notes bestimmt hilfreicher.

[Smurf]

Danke, aber den direkten Download kenne ich schon, sonst hätte ich nicht den "me"-Parameter anmeckern können …
nur: zum Verständnis von Code ist dieVersionsgeschichte für mich sehr hilfreich. Ich fühle mich gehandicapt wenn ich die nicht habe und nachsehen kann, wie und wieso Code entstanden ist, den ich nicht auf Anhieb verstehe.

[Zepp]

Der download hier funktioniert

http://state-machine.com/downloads/index.php

[Smurf]

Das Forum ist schon länger wieder da, aber das git-Repo noch nicht.

Letztlich wird die Auswahl derjenige treffen, der sich die Arbeit auf die Fahnen schreibt …

[Zepp]

Mein Fehler, im framework wird das natürlich so gemacht, zb qa_ctor.c

void QActive_ctor(QActive * const me, QStateHandler initial) {
    (...)
    QHsm_ctor(&me->super, initial);
}

Es ist sicher nicht sinnvoll irgendwelche Änderungen an QP durchzuführen. Samek wird seine Gründe haben, dass QP-C++ so aussieht wie es aussieht und im Forum auf sourceforge (ist wieder da übrigens) gibt er schnell sehr kompetent Antwort. Er wird sicher interressiert sein zu hören, dass QP als framework für den eibd in Betracht gezogen wird.

Ich habe mich nochmal umgeschaut und es gibt ja inzwischen einiges an Aktor-frameworks für C++ da sollte doch was dabei sein wenn QP nicht das richtige ist.

[Smurf]

Baseclass_foo((struct Baseclass *)&c, ...)

Auch diesen Code verstehe ich nicht wirklich, schließlich tut

Baseclass_foo(&c->super, ...)

genau dasselbe -- ist aber wenigstens an dieser Stelle typsicher. Mit C++ bekomme ich die umgekehrte Richtung mit einem <dynamic_cast> gebacken – aber wenn man den Code so schreibt, dann geht dieser Vorteil verloren.

Egal. Kann man alles beheben und/oder damit leben.

Es gibt halt zwei fundamental verschiedene Alternativen an dieser Stelle – entweder ein Framework wie QP-C, das auf C-Kompatibilität setzt, oder man verwendet gleich die nativen Features von C++11 (bzw. Boost:. Letzteres hätte den Vorteil, dass sich Leute, die C++ bereits können, nicht erst einarbeiten müssen.