eibd(war bcusdk) Fork -> knxd

[makki]

Wäre es nicht ganz sinnvoll unter den Support Foren ein KNX toppic auf zu machen?
Da könnte man alles nachlesen und auch mal fragen stellen?

Das Angebot steht ja, momentan sind wir aber gerade mal seit 24h soweit, das "Makefile-Versteher" das kompiliert bekommen.
Die Sache steht eher in dem Stadium Antworten zu brauchen, Fragen gibts schon genug

Makki

Edit/PS: Kommt Zeit, kommt Rat, ETA Ende 2014..

[TiberiusTribun]

Ich habe dazu keine gefestigte Meinung, benutze selbst nur die Perl und C-API.

Versuche mal die Vor- und Nachteile zu skizzieren:
- "auto-API": fällt halt so raus, ohne das man die Sprache kennen muss - oder jemand das extra befummeln muss.
Dafür lohnt sich IMHO auch ein bisschen Aufwand "vornedran"
- "custom-API" muss jeder für "seine" Sprache jedesmal aufwändig anfassen.

Also meine Erfahrung ist halt dass ich als Python-Programmierer eine API erwarte, die im weitesten Sinne "pythonic" ist, also dem Muster entspricht wie die meisten anderen APIs auch funktionieren. Das ist sicher bei den anderen Sprachen nicht anders. Mit einer nach Sprache X umgewurschtelten C-API hantieren zu müssen führt dann nur zu Frust. Ging mir jedenfalls so.

Aber klar, man kann natürlich die Auto-APIs erstmal drinlassen und parallel sowas wie einen "native" client entwickeln. Ich persönlich würde halt keine Energie darauf verschwenden ohne Feedback, dass die Auto-APIs auch tatsächlich genutzt werden.

[christianwicke]

Zu ptsem-Problematik

Hallo Michael,
super, dass Du Bewegung reinbringst in die Entwicklung.
Ich habe mir auch schon einige Gedanken gemacht, wie wir mit der ptsem umgehen können: Es muss einen Grund geben warum kaum jemand pthsem und pth verwendet und weiterpflegt. Der Mainstream geht jedenfalls woanders hin.
Ich denke, am besten sollten wir versuchen, ganz auf Threads zu verzichten. Der Vorteil ohne Threads ist, dass der Code einfacher zu debuggen und zu verstehen ist. Außerdem verwendet pth intern soweit ich weiß sowieso keine echten Linux-Threads sondern bildet alles auf einen Linux-Thread ab.

Statt Threads sollte es eine globale poll-Schleife geben, die auf KNX und allen außeren Connections (TCP, Socket) lauscht. Als ich damals mich in libusb eingearbeitet hatte, um die verlorenen Telegramme zu finden, habe ich genau so eine Programmstruktur in in der Doku von libusb gefunden.
Damit der Rest vom Code vorerst weiterverwendet werden kann könnte man die 10 Layers von eib alle nacheinander solange aufrufen, bis jeder fertig ist. Die Datenübertragung zwischen den Layers müsste man allerdings dafür ändern.
Ich würde hier auch unterstützen, vermutlich aber erst im neuen Jahr. Ich würde mit libusb anfangen. Die andere Hardware kann ich nicht testen.

Michael, lohnt es sich für pthsem-Ablösung eine Unterkategorie zu machen?

Noch was: Solange wir noch pthsem haben: Kannst Du meinen Patch von damals für die verlorenen gegangenen usb-Telegramme einspielen: BCU SDK with eibd / Mailing Lists

Danke und Gruß
Christian

[Chris M.]

Statt Threads sollte es eine globale poll-Schleife geben,

Sollte man statt dem poll nicht lieber ein select nehmen?

Und: C oder C++? Native oder mit Bibliothek?

[christianwicke]

Sollte man statt dem poll nicht lieber ein select nehmen?

Und: C oder C++? Native oder mit Bibliothek?

Hallo Chris,
Du hast vermutlich recht, dass select besser ist. Ich bin selber Java-Entwickler und bin nicht so ganz sattelfest mit C. Ich musste eben erst einmal nachgeschauen, was eigentlich die Unterschiede genau sind zwischen poll und select.
Zur Programmiersprache: Will ich nicht entscheiden, ich hätte normales C genommen. Mein Eindruck ist, dass C++ sich nie richtig gegenüber C durchgesetzt hat und die zusätzliche Komplexität die Vorteile auffrisst.
Mit Native oder Bibliothek weiß ich nichts recht anzufangen. Gibt es Bibliotheken, die man statt des normalen select() nehmen kann?
Gruß
Christian

[timowi]

Es muss einen Grund geben warum kaum jemand pthsem und pth verwendet und weiterpflegt. Der Mainstream geht jedenfalls woanders hin.

Es gibt hunderte threading Bibliotheken. Fast alle werden nicht mehr verwendet. Allgemein hat sich nie eine richtig durchgesetzt. (Es gibt mittlerweile std::threads im neusten C++ standard c++11

Ich denke, am besten sollten wir versuchen, ganz auf Threads zu verzichten. Der Vorteil ohne Threads ist, dass der Code einfacher zu debuggen und zu verstehen ist.

Ja, threads bringen eine gewisse komplexität mit sich. Allerdings wird die Programmierung dadurch auch einfacher.

Statt Threads sollte es eine globale poll-Schleife geben, die auf KNX und allen außeren Connections (TCP, Socket) lauscht.

Das halte ich nicht für sinvoll. Es bedeutet das jede Aktion für sich komplett abgearbeitet werden können muss, bevor in die Hauptscheife zurückgesprungen werden kann. Die dafür notwendigen Zustände und Warteschlangen werden wahrscheinlich genauso komplex wie Threads...

Außerdem würde dies die Struktur des eibd komplett über den Haufen werden. Da wäre es wahrscheinlich einfacher, komplett neu anzufangen.

[timowi]

Noch was: Solange wir noch pthsem haben: Kannst Du meinen Patch von damals für die verlorenen gegangenen usb-Telegramme einspielen: BCU SDK with eibd / Mailing Lists

Könnte da mal bitte jemand testen, wie es mit der aktuellen knxd Version und einen aktuellen libusb aussieht? Die 30s hören sich verdächtig nach einen Bug in libusb an, der vor längerem gefixt wurde. Bisher verwendete eibd eine eigene (sehr alte) Version von libusb. Knxd verwendet jetzt die installierte Version.

[makki]

Also meine Erfahrung ist halt dass ich als Python-Programmierer eine API erwarte, die im weitesten Sinne "pythonic" ist, also dem Muster entspricht wie die meisten anderen APIs auch funktionieren. Das ist sicher bei den anderen Sprachen nicht anders. Mit einer nach Sprache X umgewurschtelten C-API hantieren zu müssen führt dann nur zu Frust. Ging mir jedenfalls so.

Aber klar, man kann natürlich die Auto-APIs erstmal drinlassen und parallel sowas wie einen "native" client entwickeln. Ich persönlich würde halt keine Energie darauf verschwenden ohne Feedback, dass die Auto-APIs auch tatsächlich genutzt werden.

Nun, ich drücke es jetzt mal bewusst überspitzt sarkastisch aus: Als Perl-Entwickler erwarte ich eine total ineffiziente, idiotische, mit Speicherlecks geradezu bestückte API

Wie gesagt: es dürfte wegen mir auch beides geben, die bessere gewinnt mittelfristig, fertig.
Das soll der Markt/die Community entscheiden.

Hallo Michael,
super, dass Du Bewegung reinbringst in die Entwicklung.
Ich habe mir auch schon einige Gedanken gemacht, wie wir mit der ptsem umgehen können: Es muss einen Grund geben warum kaum jemand pthsem und pth verwendet und weiterpflegt. Der Mainstream geht jedenfalls woanders hin.

Hmm, da bin ich echt komplett anderer Meinung.. Der Grund ist IMHO eher, weil SW-Entwickler von mindestens vier Cores und zwei GB RAM ausgehen dürfen.
Das war, wird und ist nicht mein Ziel. Der knxd soll&wird (so wie der eibd) problemlos auf einem Single-Core mit 32MB RAM und 0.5-1W laufen.

Ich denke, am besten sollten wir versuchen, ganz auf Threads zu verzichten. Der Vorteil ohne Threads ist, dass der Code einfacher zu debuggen und zu verstehen ist. Außerdem verwendet pth intern soweit ich weiß sowieso keine echten Linux-Threads sondern bildet alles auf einen Linux-Thread ab.

Ehrlich, da kommt mir nur die Galle hoch.
Das ist die Denke von "Strom kommt aus der Steckdose", "Ist es zu langsam braucht man halt nen Core-i7", "4GB mehr", ..

Statt Threads sollte es eine globale poll-Schleife geben, die auf KNX und allen außeren Connections (TCP, Socket) lauscht.

Schonmal was von "select" gehört ?

]Als ich damals mich in libusb eingearbeitet hatte, um die verlorenen Telegramme zu finden, habe ich genau so eine Programmstruktur in in der Doku von libusb gefunden.

Mit einer USB-Schnittstelle (HID) ist "realtime" (25+ Telegramme) nicht machbar.

Ich würde hier auch unterstützen, vermutlich aber erst im neuen Jahr. Ich würde mit libusb anfangen. Die andere Hardware kann ich nicht testen.

Gerne, jede Hilfe ist willkommen!
Meine persönliche Meinung: die USB-SS (nicht TP-UART) sind alle unbrauchbar.
(Das hat nichts mit USB zu tun, sondern simplen Dingen, wie 64k Frames, einem falschen Design [HID], das kann nicht gehen..)
Ich drehe den Spiess mal um: beweise mir das Gegenteil bei 25-30 tps

Noch was: Solange wir noch pthsem haben: Kannst Du meinen Patch von damals für die verlorenen gegangenen usb-Telegramme einspielen: BCU SDK with eibd / Mailing Lists

Danke und Gruß

Christian

Teste ich noch diese Woche (hab mir heute zwei USB-SS "reserviert" - auch wenn ich nicht daran glaube..)

Makki

Edit: @Timo: teste ich natürlich - wenn ich schon dabei bin- auch mit der nativen, aktuellen libusb. Aber ohne präjustiz: das Ergebniss kenne ich in beiden Fällen schon.. Die USB-SS ist leider nicht "vollgasfest" (das ist mit der ETS übrigens nicht andes..)

[Jockel]

Meine persönliche Meinung: die USB-SS (nicht TP-UART) sind alle unbrauchbar.(Das hat nichts mit USB zu tun, sondern simplen Dingen, wie 64k Frames, einem falschen Design [HID], das kann nicht gehen..) Ich drehe den Spiess mal um: beweise mir das Gegenteil bei 25-30 tps

Nach einigen Jahren Erfahrung mit USB in anderen Bereichen kann ich das nur so unterschreiben!

[Jockel]

Ich hab es eben mal auf die Schnelle unte OSX probiert die Quellen zu übersetzen. Das funktioniert soweit mit folgenden Ergänzungen zur Anleitung auf GitHUB:

1. libtoolize muss separat installiert werden, ich habe es aus den macports genommen. Dann muss in der bootstrap.sh libtoolize durch glibtoolize ersetzt werden (und /opt/local/bin muss im Suchpfad enthalten sein)

2. Zusätzlich braucht es die Bibliotheken argp-standalone und pthsem aus den macports. Ev. auch noch weitere Abhängigkeiten, die ich schon installiert hatte.

1. Der configure aufruf dann als ./configure --without-pth-test CPPFLAGS='-I/opt/local/include' LDFLAGS="-L/opt/local/lib"

Warum der pthsem test fehlschlägt ist mir noch nicht klar, am $LD_LIBRARY_PATH wie vom configure script vorgeschlagen liegt es jedenfalls nicht..

Damit kann ich die Binaries erzeugen, ob die noch mehr tun als den Hilfetext auszugeben habe ich aber noch nicht getestet. Es gibt auch einige warnings vom Compiler, das scheint auf den ersten Blick aber nichts OSX spezifisches zu sein.

[timowi]

1. libtoolize muss separat installiert werden, ich habe es aus den macports genommen. Dann muss in der bootstrap.sh libtoolize durch glibtoolize ersetzt werden (und /opt/local/bin muss im Suchpfad enthalten sein)

Ok, das ist auch eine Besonderheit der Verwendung der git Quellen. In einem release Quellpacket wird schon die configure und die ganzen Makefile.in enthalten sein

Warum der pthsem test fehlschlägt ist mir noch nicht klar, am $LD_LIBRARY_PATH wie vom configure script vorgeschlagen liegt es jedenfalls nicht..

Nach dem fehlgeschlagenen configure die config.log ansehen. Da steht es drin. Oder irgendwo hochladen. (z.B. Pastebin.com - #1 paste tool since 2002!)

Schreibe doch eine etwas ausführlichere BUILDING.mac-os Die kann dann ins doc/ Verzeichnis

[timowi]

Falls es Jemandem hilft: Ich hab mal Ubuntu Packete des aktuellen knxd erstellt:

https://launchpad.net/~timo-wingende...tu/knxd-daily/

[christianwicke]

Meine persönliche Meinung: die USB-SS (nicht TP-UART) sind alle unbrauchbar.
(Das hat nichts mit USB zu tun, sondern simplen Dingen, wie 64k Frames, einem falschen Design [HID], das kann nicht gehen..)
Ich drehe den Spiess mal um: beweise mir das Gegenteil bei 25-30 tps

Mag alles sein, dass USB-Interfaces nicht mehr als 25 tps können. Für ein Einfamilienhaus reicht das aber vielleicht. Wenn es mit den max. 25 tps stabil laufen würde, dann wäre ich schon zufrieden.

Christian

[Tru]

Ich habe soeben knxd erfolgreich produktiv in Betrieb genommen.

Läuft auf Ubuntu 14.04.1 LTS i386 zusammen mit einem IP Gateway im Tunnelmodus.

Gruss, Othmar

[Chris M.]

Zur Programmiersprache: Will ich nicht entscheiden, ich hätte normales C genommen. Mein Eindruck ist, dass C++ sich nie richtig gegenüber C durchgesetzt hat und die zusätzliche Komplexität die Vorteile auffrisst.

Bei dem Eindruck empfehle ich den Tellerrand mal wieder zu besuchen und Ausguck zu halten...

C dürfte die Sprache der Wahl sein, wenn der bestehende Code maßvoll weiterentwickelt werden soll (ich vermute das wird unsere Zielrichtung sein).
C++ dagegen bei einer Neuentwicklung - dank STL und BOOST, gepaart mit C++11, lässt sich dort ein sehr sauberer (= wartbarer!) Code schreiben der dennoch sehr performant ist und klein compiliert. (Man muss - wie immer - schon wissen was man tut, wer beliebig wütet und meint eine gigantische Klassenhierachie bauen zu müssen, möglichst noch mit virtueller und mehrfacher Vererbung, kann natürlich auch die Vorurteile bedienen)

Mit Native oder Bibliothek weiß ich nichts recht anzufangen. Gibt es Bibliotheken, die man statt des normalen select() nehmen kann?

Klar, z.B. könnte man QT als Bibliothek nehmen (das gibt's auch Headless).
QT ist schönes klassisches C++ mit hoher Portabilität auf den üblichen Systemen. D.h. für so ein Projekt erst mal eine gute Basis.
Aber da unser Ziel "klein und minimaler Ressourcen-Verbrauch" ist, evtl. gar Embedded-Systeme (=> möglichst gar kein dynamisches Speichermanagement!), könnte es durchaus Sinn machen sich nur auf POSIX zu limitieren - auch wenn's deutlich anstrengender ist.