KNX/EIB Stack für MSP430F2xx komplett in Software (Hardware ohne
TP-UART o.ä.).
Eigentlich wollte ich mit der Veröffentlichung warten bis alles komplett
funktioniert, aber auf Grund einer Anregung im Beitrag
Beitrag "KNX: Busankopplung selber bauen"
starte ich hier mal ein "Sammelbeitrag" für alle die Interesse an einem
freien KNX Stack für MSP430 oder anderen Controllern haben.
Im Anhang der bisherige (extrem BETA!) Code. Läuft zur Zeit auf einem
MSP430F2012. Da nur Timer A und ein Port-Pin Interrupt benutzt wird, ist
die Software grundsätzlich auf allen MSPs lauffähig, speziell der F2xx
Serie. Ich hab es geteilt in Low-Level (µC spezifisch), und High-Level
Funktionen.
Empfang funktioniert, Auswertung auch in groben Zügen, ACK Byte wurde
erfolgreich gesendet.
Zur Hardware schreib ich in den nächsten Tagen noch was.
Wie soll's weiter gehen?
Mein Ziel ist (erst mal) die Emulation eines Siemens KNX Tasters, dem
"5WG1 116-2AB21". Damit erspart man sich eine eigene Produktdatenbank
anzufertigen. Trotzdem gibt es noch etliche Fragen und Probleme zu
lösen...
Find ich schonmal Klasse!
Nicht falsch verstehen: um das ganze portierbar (und etwas allgemein
verständlich) zu halten wäre es nicht schlecht, wenn wir uns an die Spec
bzw. den Aufbau/Bezeichnungen darin halten. Wenn die Schnittstelle passt
sollte man ab dem Data Link Layer einen gemeinsamen HW unabhängigen
Stack verwenden können (...falls man auch den EEprom/Flash Zugriff HW
unabhängig hinbekommt).
Als Nahziel würde mir ein KNX-Stack mit Bootloader schon reichen. Dann
kann man sich immer noch überlegen ob man das reverse Engineering auf
sich nimmt und eine vorhandene Applikation nachstrickt, oder ob man auf
die Parametrierbarkeit via ETS verzichtet und dafür auch noch an einer
"privat" ETS bastelt. (Ultimativlösung: offenes KNX Manufacturer Tool,
mit dem man sich seine eigenen .vd's/.knxprod erstellen kann).
Wolfgang L. schrieb:> ..um das ganze portierbar (und etwas allgemein> verständlich) zu halten wäre es nicht schlecht, wenn wir uns an die Spec> bzw. den Aufbau/Bezeichnungen darin halten.
Du meinst die z.B. im Dokument "EIB Implementation on Twisted Pair" in
Abschnitt 1.4/2.4 beschrieben sind? Kann man machen, wobei das ja glaub
ich Klassen sind. Sowas würde ich dann schon gerne vermeiden (sofern das
mit den Compilern überhaupt möglich ist :) ).
> Als Nahziel würde mir ein KNX-Stack mit Bootloader schon reichen.
Bootloader wäre für mich jetzt erst mal nicht so wichtig. Aber ne schöne
Idee :)
> oder ob man auf die Parametrierbarkeit via ETS verzichtet und dafür auch> noch an einer "privat" ETS bastelt.
Da gab es ja auch schon einige Versuche. Halte ich persönlich für etwss
zu ambitioniert. Wobei es natürlich darauf ankommt wie weit man das
treiben will.
> (Ultimativlösung: offenes KNX Manufacturer Tool,> mit dem man sich seine eigenen .vd's/.knxprod erstellen kann).
Soweit ich gehört habe ist das für die alte ETS (vor Ver.4) kein Problem
(macht Freenet wohl schon so), bei ETS4 sind unbekannte Hersteller wohl
von Hause aus ausgeschlossen.
Jörg S. schrieb:>> (Ultimativlösung: offenes KNX Manufacturer Tool,>> mit dem man sich seine eigenen .vd's/.knxprod erstellen kann).
Der Inhalt der .vd´s (passwort geschützte zip dateien) lässt sich
einfach mit einem Editor bearbeiten, wenn man das Passwort kennt ;)
Das Manufacturer Tool ist nicht wirklich notwendig.
In der ETS4 gibt es eine Herstellerliste.
d.h. jedes Gerät hat an einer bestimmten Stelle eine Herstellerkennung,
damit das Gerät einem Hersteller zugeordnet werden kann.
Wenn ich es noch richtig im Kopf habe ist es nur eni Byte.
An dieser Stelle könnte für eine eigene Entwicklung (zumindest für
Privatverwendung) jeder beliebiege Wert eingetragen werden.
Das Problem ist eher, dass eine .knxprod nur erstellt werden kann, wenn
der Datenbankeintrag von der KNX getestet wurde.
Es gibt aber einen Umweg, dabei wird nicht die .knxprod sonder eine
.knxproj impotiert.
In einer .knxproj können auch nicht zertifizierte Geräte enthalten sein
und aus diesem Projekt kann das Gerät dann in ein anderes Projekt
kopiert werden.
Das macht z.B. Tapko mit dem generischen Eintrag für das SIM-KNX so.
Hallo Jörg,
wie ist denn der Status bei deinem Projekt, würde mich brennend
interessieren da ich auch vorhabe auf einem avr was knx mäßiges zu
machen?
Könntest du evtl. deine Hardware näher beschreiben?
Danke!
Status ist "in Arbeit" :) War jetzt erst mal mit Analyse der KNX
Kommunikation der ETS beschäftigt. An der Software ist daher nicht
wirklich was passiert.
Schaltplan meiner Lochraster Platine im Anhang. Empfangsstufe ist eine
eigene Idee, Sendestufe ist nur "quick and dirty" Lösung. Da muss dann
für den späteren Betrieb noch was gescheites her. Hab auch schon ein
paar Ideen dazu im Kopf. Aber man könnte natürlich auch einfach die
FreeBus Schaltung nehmen.
Bei der Analyse der ETS Kommunikation ist auch ein Monitor-Programm
abgefallen. Das stell ich in den nächsten Tagen (wenn die Beschreibung
fertig ist) noch in's Netz. Ist denke ich mal ein schönes kleines Tool
geworden :)
danke für die Info :) ....das Monitor-Programm schaut ja richtig
professionell aus und die Sendestufe dazu sehr innovativ ;)
hoffe das ich mich jetzt über die Feiertage mal damit beschäftigen kann
und starte mit deinem bisherigen code, hardware muss ich schaun was ich
so rumliegen hab :)
Aktueller Stand: Es ist seit damals NICHTS passiert :(
Ich hätte nicht gedacht das ich mich auch mal in die Reihe von KNX
Projekten einreihe die gestartet wurden aber im Sande verlaufen, aber
leider hab ich Familien- und Eigenheim-bedingt keine Zeit mehr für
solche Projekte.
Na ja, wenn die Kinder etwas größer und die gröbsten Sachen am Haus
durch sind, bleibt vielleicht noch mal Zeit übrig... hoffentlich...
Daneben muss ich mir auch wieder einen vernünftigen Entwicklungs-Platz
aufbauen.
Nur mal zum Verständnis, ist es korrekt, dass der OP alles soweit in
Software umgesetzt hat, dass kein spezieller "KNX-Busankoppler-Chip"
mehr benötigt wird?
Und gilt das auch für das verlinkte Github-Projekt (dort habe ich nichts
zur verwendeten Elektronik gefunden)
KoNetX.JPG
(94 KB)
