ARDUINO am KNX

[JuMi2006]

Meinen Code werde ich sicherlich, bzw. das ganze Projekt ein wenig dokumentiert, einstellen.
Dazu will ich aber erstmal die Libs ein wenig "aufräumen". Das ganze läuft momentan auf einem meiner ersten TPUART-Shields mit einem Pro Micro.

Mit den Arduino-IDEs stehe ich momentan auch auf Kriegsfuß. Lade ich einen Sketch mit 1.6.4 in den Arduino so hängt der sich auf, der gleiche Sketch mit 1.5.0 auf den Arduino geschoben funktioniert problemlos.

Ein Vorteil der tuxedo-lib sehe ich in der Möglichkeit evtl. die Properties möglich zu machen und die Arduinos so über ein separates Tool mit GA/Parametern zu füttern. Wenn ich jetzt schon sehe wie merkwürdig sich die IDEs verhalten kann ich davon ausgehen dass ich in 3 Jahren den Sketch nicht mehr aufs Board bekomme .

Ich lade gern dazu ein an der Version in meinem Git-Repo mitzuarbeiten. Ich kann das ganze neben Arbeit, Familie, Garten und anderen Bastelprojekten eh nur nebenbei verfolgen. Im Grunde will ich aber einen Sketch-Skeleton erarbeiten der mit meinen Shields arbeiten kann. Dazu zählt dann auch das ablegen der PA im EEPROM, die Ansteuerung von Programmier-LED, Taster usw..

[tuxedo]

Ein Vorteil der tuxedo-lib sehe ich in der Möglichkeit evtl. die Properties möglich zu machen

Das würde auch ohne weiteres mit der Ursprünglichen-Lib funktionieren. Aber hier hab ich eben schon mal vorgearbeitet.
Auch auf PC-Seite hab ich einiges vorbereitet: Schreiben von PA und Properties via Java-Tool ist in den Grundzügen schon in Form eines einfachen Prototyps erarbeitet.
Was mir eigentlich noch fehlt ist das für Arduino möglichst Platz- und RAM-sparende Mapping zwischen Daten im RAM und Programmcode. Für einfaches ist das mit Properties kein großes Thema. Für "mehr" aber wie gesagt nicht ganz so easy.

[JuMi2006]

Vielleicht ein einfacher Denkfehler von mir:

Ich definiere erstmal ein leeres Array fürs mapping von RAM <-> EEPROM.
Solange ich keine Funktion von xpropread/xpropwrite aufrufe bleibt das ganze auch leer. Erst wenn ich eines der beiden mache wird das Array gefüllt und mir geht Speicherplatz im RAM flöten. Nach einem xpropwrite werde ich das Gerät sicherlich neu starten und der RAM steht wieder zur Verfügung. Die Variablen lese ich aus dem EEPROM.
Ansonsten sollten die Variablen ausserhalb der Funktion eh gelöscht sein - sofern ich das richtig verstanden habe. Also sobald ich void xpropread(){} verlasse kann ich das Array wieder leeren.
Das Mapping kann man dann dynamisch und/oder mit festen Regeln machen.

Das hier ist aber nur eine Laienmeinung . Ich muss mir das irgendwann mal genau anschauen. Bis dahin versuche den Debug-Output der Lib ein wenig zu komprimieren ohne dabei Informationen zu verlieren. Erstmal muss ich da noch ein paar Basics erarbeiten.

[tuxedo]

In Sachen uC-Programmierung bin ich auch noch Anfänger. Ich habe lange gebraucht bis ich heraus gefunden hatte warum sich mein Sketch so seltsam verhält. Dachte auch noch an einen Hardware-Defekt. Fazit war aber: RAM war voll... Hat mich 2 Tage gekostet. Aber ich habe dazu gelernt.

Dein Ansatz klingt logisch. Aber es fehlt sicherlich noch im Detail.

Die Probleme die ich mit den Properties hatte lag am doppelten Mapping:

Property/Objekt vs. KO-Nummer vs. Eeprom-Index

Wenn du da mehr wie 10 KOs hast, dann brauchst du schnell ein Konstrukt das skaliert. Und dann reicht dir ein einfaches Array nicht mehr.

Ein Beispiel:

Mein LED Controller hat 6 Kanäle. Pro Kanal habe ich eine Instanz von "PwmChannel". Jeder Kanal hat 27 Parameter deren Parametrisierung im EEPROM zu finden sein sollten.

Macht schon 162 Parameter...
Dazu kommen noch 8 KOs pro Kanal. Macht 48 KOs bzw. 48 Gruppenadressen.

Auf der PC-seitigen Konfiguration (XML-Format) habe ich alle Parameter und KOs gelistet, jeweils mit ID.

Diese ID wird in der XML auf Objekt/Property gemapped.

Soweit kein Problem. Auf Arduino-Seite kommen dann Schreib-Vorgänge an die Object+Property mit sich tragen.
Also musst du nun wissen, welches Objekt mit welcher Property an welchem EEPROM-Index liegt.

Damit kannst du die Daten schon mal in den Eeprom schreiben. Aber deine Kanäle müssen auch noch wissen wo sie die Daten im Eeprom finden. Hier hatte ich nochmal eine Mapping-Tabelle von Parameter- bzw. KO-ID auf den Eeprom-Index.

Das wird im Code schnell hässlich und unübersichtlich. Etwas leserlicher wäre es geworden, wenn ich statt Parameter-ID und KO-ID auf Arduino-Seite einfach wieder Object/Property-ID gepflegt hätte. Dann wäre es eine Tabelle weniger geworden. Aber so richtig "toll" war auch das nicht.

Dieser Ansatz hat unbewusst eher das Schema verfolgt: Saubere Konfiguration auf PC Seite, der Rest (Arduino) richtet sich dann danach.

Besser wäre aber der Ansatz:

Sauberes Mapping der Kanäle in den RAM und die Konfiguration auf PC Seite richtet sich dann danach.

Ich habs noch nicht faktisch ausprobiert und zu 100% zuende gedacht, aber ich erhoffe mir durch den Ansatz dass ich auf der Arduino-Seite einfach mit einer Start-Adresse im EEPROM beginnen kann. Da folgt dann alles zu Kanal A, gefolgt von Kanal B, ... bis zum letzten Kanal. Sprich: Ich kann komplett mit einfachen Offsets arbeiten. Daten aus dem Eeprom lesen wäre super einfach und ich bräuchte keinerlei Mapping-Tabelle. Nur jeweils einen Offset für den Index im Eeprom.

Dafür wird es auf der Konfigurationsseite komplexer: Ich muss dort in der XML festlegen, welche Daten wie in welcher Reihenfolge ab welcher Addresse geschrieben werden.
Statt propwrite gibt's dann einfach ein memwrite.

Hab memwrite noch nicht im Arduino implementiert. Aber das dürfte nicht schwerer sein als das mit den Properties.

Fazit wird hier aber sein:

Das händische basteln einer XML-Konfiguration wird mit dem memwrite Ansatz für den durchschnittlichen Arduino-Bastler schwerer.

Gruß
Alex

[tuxedo]

Hab mir gestern Abend nochmal ein wenig den Kopf drüber zerbrochen wie man das seitens der Konfiguration am besten löst...

Am einfachsten ist es wohl wenn man sich Segmente im Speicher definieren kann, und dann die Gruppenaddressen und Parameter in diesen Segmenten mit einem Offset platzieren kann. Hier mal exemplarisch der entsprechende Abschnitt:

        <resources>
            <memory>
                <!-- GA -->
                <segment id="0" address="0x0000" />
                <!-- Channel A ... F -->
                <segment id="1" address="0x0010" />
                <segment id="2" address="0x0020" />
                <segment id="3" address="0x0030" />
                <segment id="4" address="0x0040" />
                <segment id="5" address="0x0050" />
                <segment id="6" address="0x0060" />
            </memory>
            <resource name="GroupAddressMemoryMapping">
                <mapping commobject-id="1" memorysegment-id="0" offset="0"/>
                <mapping commobject-id="2" memorysegment-id="0" offset="2"/>
                <mapping commobject-id="3" memorysegment-id="0" offset="4"/>
            </resource>
            <resource name="ParameterMemoryMapping">
                <!-- Channel A -->
                <mapping parameter-id="1" memorysegment-id="1" offset="0"/>
                <mapping parameter-id="2" memorysegment-id="1" offset="4"/>
                <mapping parameter-id="3" memorysegment-id="1" offset="9"/>                    
                <!-- Channel B -->
                <mapping parameter-id="10" memorysegment-id="2" offset="0"/>
                <mapping parameter-id="11" memorysegment-id="2" offset="4"/>
                <mapping parameter-id="12" memorysegment-id="2" offset="9"/>                
            </resource>
        </resources>

Damit dürfte das ganze ähnlich einfach in der Konfiguration sein wie vormals der Property-Ansatz.

Damit lässt sich recht easy die Ordnung im Speicher definieren, womit man 1) völlig frei in der Speicherbelegung ist und 2) das so steuern kann, dass man auf Arduino-Seite Kanal für Kanal quasi am Stück aus dem Speicher lesen kann. Ohne weitere Mappingtabellen.


Werde das mal weiter verfolgen und schauen dass ich in den nächsten Wochen da was lauffähiges hinbekomme.

[tuxedo]

Im Anhang mal eine exemplarische Konfigurations-XML eines fiktiven VOC-Sensors auf Arduino-Basis. Da sieht man dann die "zusammenhänge" besser.

Werde mich als nächstes an memwrite für Arduino machen.

[update]
Kann keine XML/TXT-Files anhängen? Dann hier der Link zur Beispieldatei:

http://denbh000.dyn.root1.de/public/voc.karduino.xml

[mode]

Gefällt mir sehr gut, da leicht verständlich und Abstaktionsebenen vom Atmel auf den PC überführt. Dazu noch der Verzicht auf Strings und wir bekommen eine wunderbare leichtgewichtige Lib, die auch noch Platz für umfangreiche Applikationen lässt.

[Ing-Dom]

Gefällt mir auch, dass es hier weitergeht!
Die Lib hat definitv Potential, Arduino hat hier eine kritische Maße erreicht dass es echt viele Lösungen schon gibt und die HW ist auch spottbillig.

Ich würde und werde hier auch gerne mitarbeiten, ich denke aber dass wir hier nicht weiterkommen ohne ein bischen Organisation und Disziplin.
Mit 4-5 Entwicklern hätten wir doch ein Basis wenn wir uns wirklich zusammentun und nicht jeder seine eigenen Brötchen bäckt.

Wie wäre es denn mit einem eigenen Projekt auf github, sourceforge etc.. mit Repo, Forum, Wiki usw? Ein bischen Doku hat ja auch noch nicht geschadet.
Ein eindeutiger Name, eindeutige Versionen usw wären ja auch nicht verkehrt.

[tuxedo]

Gefällt mir auch, dass es hier weitergeht!
Die Lib hat definitv Potential, Arduino hat hier eine kritische Maße erreicht dass es echt viele Lösungen schon gibt und die HW ist auch spottbillig

Am tollsten würde mir es gefallen, wenn wir ein Arduino-Board (mit Power eines Leonardo oder so) fertig angeschlossenem KnxTpUart hinbekommen.

Mein "Traum" wäre es, eine zwei Basisplatinen zu haben:

1) Sowas in der Größe wie den Berker-Sensor-Einsatz: Board mit Arduino + KNX-TpUart und diverse IO-Pins steckbar für eine individuelle Huckepack-Platine
2) Eine Basis-Platine, mit selber austattung, aber für ein Reg-Leergehäuse ...

Eigentlich unterscheiden sich die Platinen nur im Form-Faktor. Wenn das aber noch zu einem Preis von <50EUR/Stück möglich wäre (ggf. mit teil-selbstbestückung), wäre das absolut bombe... Damit würden sich Schaltaktoren und Co. mit wenig Aufwand selbst basteln lassen. Und wenn die Software dazu noch was taugt... *hammer*



Aber das ist wohl schon sehr "advanced". Back to the roots ...

Repo ... Hat JuMi schon bei Github ins leben gerufen
Forum ... sowas in der Art bietet Github doch auch?
Wiki ... ebenfalls über Github verfügbar

Name ... Ja, da hab ich auch schon drüber nachgedacht. Hatte mir viele Kombinationen überlegt. Das meiste war nicht aussprechbar oder hat nicht gut geklungen oder hätte ggf. Namenskonflikte mit KNX gegeben. Bin letzendlich bei "Karduino" gelandet. Kurzform für "KNX on Arduino".

[update]
Auf die Gefahr hin dass ich voreilig bin: Ich hab mal Nägel mit Köpfen gemacht und auf Github eine "Organisation" eingerichtet und die mir bekannten dazu eingeladen.
---> https://github.com/KNX-on-Arduino

[Ing-Dom]

Lad mich bitte dazu ein, habe mich eben bei Guthub angemeldet.
Wollen wir das nicht evtl. öffentlich machen?

[tuxedo]

Lad mich bitte dazu ein, habe mich eben bei Guthub angemeldet.

Hab ich soeben getan.

Wollen wir das nicht evtl. öffentlich machen?

Wie definierst du öffentlich: Das Projekt IST öffentlich. Man müsste nur das Repository erstellen, oder von einem der Forks, bzw. JuMi "Origin" zur Organisation transferieren.
Bis dahin ist die Organisation noch "leer".

Das Haupt-Repo von JuMi liegt hier: https://github.com/JuMi2006/KnxTpUart

[tuxedo]

Da wir noch kein Wiki haben, dokumentier ich mal hier:

Ich hab nachgeschaut wie das mit dem MemWrite funktioniert. Als Basis dient die Calimero-KNX-Lib für Java (Klasse ManagementProcedursImpl, ab Zeile 428).

Ein MemWrite macht folgendes:

Wenn "verifyByServer"-Flag gesetzt ist:

* readPropertyDesc ---> Das Enum hierfür gibt's schon im Arduino: KNX_EXT_COMMAND_PROP_DESC_READ
Object=0 // DEVICE_OBJECT_INDEX
Property=0 //DEVICE_CONTROL
Index=0
Sieht man im ETS Busmonitor: DeviceDescriptorRead
---> Muss entsprechend beantwortet werden. Was da drin stehen muss ist noch unklar. Calimero verwirft das aber so oder so.

* readProperty ----> Gibts im Arduino auch schon: KNX_EXT_COMMAND_PROP_READ
Object=0 // DEVICE_OBJECT_INDEX
Property=0 //DEVICE_CONTROL
Start=1
Elements=1
Das Ergebnis wird mit 0x04 "verODERt". KOmmentar dazu aus dem Calimero-Source:

// bit 2 is set for automatic management server verification (responds on
// memory write with a response containing the written data)

Das veroderte Ergebnis wird dann an die gleiche Stelle als Property zurückgeschrieben. Wenn ich den Kommentar richtig verstehe, dann dient das dazu dem KNX Gerät zu sagen: "Schick mir alles als bestätigung zurück was ich dir ein deinen Speicher schreiben will"

Für unseren Fall evtl. irrelevant?? Aber es wäre wohl kein großer Aufwand das so zu tun.

Danach wird das byte[] zusammengezimmert das dann gesendet wird. Und das ist der eigentlich interessante Abschnitt, weil der bestimmt wie man auf Arduino-Seite die Daten aus dem Telegram zu lesen hat.
Hier wird es etwas aufwendiger:

Zum einen wird ein byte[] aufgebaut das später gesendet wird. Zum anderen wird aber vorher das Gerät noch gefragt, wie groß die Häppchen (ASDU-Länge) sein dürfen die wir ihm schicken. Dazu wird wieder eine Property gelesen:

Object = 0
Property = 56 // MAX_APDU_LENGTH
Start = 1
Elements = 1

Das Ergebnis ist 1 byte, unsigned. Wohl gemerkt: APDU. Wir suchen aber ASDU ... Und das ist per Definition (???) 3 bytes kürzer.
Es gibt auch eine Default-APDU Länge von 15, für den Fehlerfall beim Abfragen der Property.
Falls unser Arduino diese Property also nicht kennt, würde der Default greifen. Besser wäre es aber, er wüsste es.

Dann kommt das byte[] mit den Daten dran:

         | 0    | 1     | 2 3 4 5            | 6 7 8 9      |10 11 12 13 |14..31|
         | code | flags | dataBlockStartAddr | startAddress | endAddress | data |
         | 0x20 | ...   | ...                | ...          | ...        | ...  |

code ist fest auf 0x20 eingestellt.
Flags wird mit dem berechnet (verifyWrite ist ein boolean den man beim Start der Methode angeben muss, siehe oben):

        int flags = 0x01;
        flags |= verifyWrite ? 0x02 : 0;

dataBlockStartAddr ist fest auf 0x0000
startaddress ist die die wir selbst angeben. Also die Adresse im EEPROM ab der geschrieben werden soll.
endAddress ergibt sich aus der Länge der zu schreibenen Daten und der Startadresse
data sind dann die Daten selbst. Calimero scheint hier keine Längenbegrenzung vorzuschreiben?!

Einmal das Array zusammengesetzt, wird das Array blockweise geschrieben. Die Blöcke sind so groß wie zuvor ASDU abgefragt bzw. ausgerechnet wurde.

Nach jedem Block kann (wenn verifyWrite gesetzt wurde) der Block zurückgelesen und vergleichen werden ob auch alles sauber angekommen ist.

Das war's dann auch schon.

Sprich: Die ersten 14 byte die wir auf der Seite des Arduino erhalten, definieren Startaddresse und Endaddresse, und somit wissen wir, wieviel wir geschickt bekommen und wieviel wir zu schreiben haben.

Ich seh schon. Das wird spassig das in Arduino-Code zu gießen...

[Ing-Dom]

Mit dem öffentlich meinte ich die Member. Diese werden nicht angezeigt, wenn man nicht Teil der Gruppe ist. Wie kann man denn da als Neuling beitreten wenn man nicht anderweitig Kontakt hat wie wir über das Forum?

Am tollsten würde mir es gefallen, wenn wir ein Arduino-Board (mit Power eines Leonardo oder so) fertig angeschlossenem KnxTpUart hinbekommen.

Mein "Traum" wäre es, eine zwei Basisplatinen zu haben:

1) Sowas in der Größe wie den Berker-Sensor-Einsatz: Board mit Arduino + KNX-TpUart und diverse IO-Pins steckbar für eine individuelle Huckepack-Platine
2) Eine Basis-Platine, mit selber austattung, aber für ein Reg-Leergehäuse ...

Eigentlich unterscheiden sich die Platinen nur im Form-Faktor. Wenn das aber noch zu einem Preis von <50EUR/Stück möglich wäre (ggf. mit teil-selbstbestückung), wäre das absolut bombe... Damit würden sich Schaltaktoren und Co. mit wenig Aufwand selbst basteln lassen. Und wenn die Software dazu noch was taugt... *hammer*

Ja, das wäre schon ne gute Sache. 50€ wäre aber für meinen Geschmack zu teuer. Gefertigte Platinen in der Größe sollten für unter 10€ selbst bei kleinen Stückzahlen machbar sein. Mit etwas Masse dahinter auch Richtung 2-3€. Und die Bauteile kosten ja nix bis auf den TPUart. Die Bestückung wird eher das Problem.

Ich finde aber mit einem Pro Mini + zerlegtem Siemens BTM und einer Adapterplatine kann man auch fast alles realisieren. Da ich einen 3.3V Arduino einsetzen möchte (die meiste Peripherie ist 3.3V, man vermeidet viele Probleme) werde ich auf der Adapterplatine noch einen Levelshifter integrieren. Ich bau da mal einen Prototypen auf Lochraster und stelle das hier ein. Es wird auf jeden Fall so kompakt, dass es in eine tiefe UP-Dose passt!

[tuxedo]

Mit dem öffentlich meinte ich die Member. Diese werden nicht angezeigt, wenn man nicht Teil der Gruppe ist. Wie kann man denn da als Neuling beitreten wenn man nicht anderweitig Kontakt hat wie wir über das Forum?

Hmm, gute Frage. Müsste ich mal schauen. Kannst mit deinem Account ja mal eine Test-Organisation anlegen. Dann kann ich schauen wie ich da rein komme.

Ja, das wäre schon ne gute Sache. 50€ wäre aber für meinen Geschmack zu teuer. Gefertigte Platinen in der Größe sollten für unter 10€ selbst bei kleinen Stückzahlen machbar sein. Mit etwas Masse dahinter auch Richtung 2-3€. Und die Bauteile kosten ja nix bis auf den TPUart. Die Bestückung wird eher das Problem.

TPUART + ATmega32u4 selber löten... Wohl eher nicht. Deshalb wird es schon ein wenig teurer als 10EUR. Wenn man mal so rechnet:

Arduino Leonardo/Micro bei Ebay: so um die 7EUR aus China
Siemens BCU: Knapp 30EUR (inkl. Versand)

Bist du schon bei fast 40EUR für ein Einzelstück

Wenn man das für nur 10EUR mehr so klein hin bekommt, dass es auf eine weniegr als 5x5cm große Platine passt und alles wichtige auf eine Stiftleiste herausgeführt ist: Das wäre top.

Sammelbestellungen sind okay (um den Preis zu drücken). Aber wenn man erstmal 1/4 Jahr warten muss bis sich genug Leute gefunden haben?!

Ich finde aber mit einem Pro Mini + zerlegtem Siemens BTM und einer Adapterplatine kann man auch fast alles realisieren. Da ich einen 3.3V Arduino einsetzen möchte (die meiste Peripherie ist 3.3V, man vermeidet viele Probleme) werde ich auf der Adapterplatine noch einen Levelshifter integrieren. Ich bau da mal einen Prototypen auf Lochraster und stelle das hier ein. Es wird auf jeden Fall so kompakt, dass es in eine tiefe UP-Dose passt

Für UP-Dose und wirklich einfache Dinge ist das ideal, ja. Allerdings hab ich gerne ne USB-Buchse. Deshalb sind gerade 5 Nanos zu mir unterwegs.

[tuxedo]

Bzgl. Github und der Organisation:

Als "Neuling" bzw. Nicht-Member sieht man nur die Repositories die angelegt wurden (hab jetzt mal ein "documentation"-Repo angelegt, damit überhaupt mal was sichtbar ist), sowie die Team-Member die ihre sichtbarkjeit selbst auf "public" gestellt haben.
Wie das geht steht hier: https://help.github.com/articles/pub...on-membership/