ARDUINO am KNX

[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

[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]

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

[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]

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]

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]

Nein, mein Code ist von meiner Seite noch nirgendwo in einem VCS gepflegt. Bitbucket war mir bisher "zu weit abseits vom Mainstream" und zu dem Zeitpunkt war ich noch nicht firm mit Github. Und für ein SVN Repo war ich noch zu faul.

Afaik hat JuMi es aber nach Github geschoben?

Bzgl. "String vs. Byte" (also den Unterschied zwischen den beiden Libs):

Geschmackssache. Ich denke die wenigsten werden mit ihrem Bastelprojekt das Speicherlimit oder den RAM ausreizen. Aber dem "optischen" und vor allem für Einsteiger tatsächlichen Vorteil durch die Strings kann man zumindest mit den Macros in meiner Variante ein wenig - ich würde sogar sagen weitgehend - reduzieren.

[ThorstenGehrig]

Hi
@JuMi: gibt's deinen Code als Beispielprojekt - wenn möglich mit der verwendeten Library? Ich denke meine Library wird dafür ja nicht verwendet?
deine Library basiert auf Tuxedos Anpassungen - plus bugfixes? Ich finde es hier eh schon unübersichtlich ... Weitere libraries die auf codebasis von "dritten" basieren verschlimmern das noch und laufen Gefahr auf Dauer nicht gepflegt zu werden :-(
@tuxedo: pflegst du deine version irgendwo im GIT ö.ä.?

@all: läuft eigentlich meine letzte Version mit dem letzten Arduino IDE? (Kann gerade nicht testen - bin in Italien im Urlaub). Wenn nicht... @mode: würdest du helfen deinen fix auch in der ursprünglichen lib zu fixen?

@JuMi: warum verwendest du die lib von tuxedo? Wolltest du auch "Platz sparen" oder fandest den Ansatz besser? Ich frage aus reiner Neugier... Damit ich entscheiden kann ob ich meinen Code irgendwann umstelle (hab ich bisher nicht geplant... So wie er ist finde ich hin einfach leichter für Einsteiger zu verwenden)

Grüße
Thorsten

[tuxedo]

Das mit den Properties hab ich mir auch schon angeschaut. Ist nicht schwer umzusetzen. Habs bereits in meiner Version der TpUart-Lib für den Arduino mit drin, aber nie ausprobiert... Bin allerdings dabei davon wieder abzukommen... Grund:

Mein 6-Kanal-Dimmer hat sehr viele KOs. Ich müsste dann im Arduino-Code hinterlegen: "Property XYZ muss im EEPROM an Adresse ABC gesichert werden".

Das ergibt recht schnell bei vielen KOs eine recht große und komplizierte Mappingtabelle, die auch noch Speicherplatz "verschwendet".

Für kleinere Dinge (eine Hand voll KOs) sind die Properties eine einfache Sache. Für viele KOs (hab glaub >50) ist es aber ggf. einfacher für den Arduino-Teil direkt in den EEPROM zu schreiben (memwrite/memread). Allerdings wird das dann auf Seite des "schreibenden" aufwendiger. Ein Konsolen-Script für eibd wäre möglich, aber eben entsprechend aufwendiger.

Zur Zeit liegt die Entwicklung etwas "brach", aber ich bin dran das über ein nettes Progrämmchen und einer XML Konfiguration zu erschlagen.

[JuMi2006]

Also bei mir läufts.

Seit gestern Abend werkelt nun der Arduino mit meinen iButtons. Der sendet für jeden Button nach Änderung/Zyklisch eine 1 oder 0 auf die entsprechende GA. Auslesen der GAs ist auch möglich. Dann gibt es noch 2 globale GAs. Die erste macht eine ODER-Logik und meldet 1 für mind. ein Button hängt und 0 für kein Button hängt.
Die zweite ist meine Praesenz-GA, die schaltet erst 5 Minuten nach dem entfernen des letzten iButtons eine 0 und sofort wenn wieder einer hängt eine 1. Die beiden globalen GAs senden auch noch zyklisch.

Als nächstes schau ich mir das mit den Propertys noch an. Vielleicht kann man das wirklich noch auf den Arduino-Stack bringen. Meine fest programmierten GAs gefallen mir nicht wirklich. Die Erkennung der Buttons ist jedenfalls deutlich stabiler als über den DS9490R USB-Busmaster am owfs.

[mode]

Ist nun in JuMis Repository. Bitte testen!

[mode]

Hab nen Fix, bekomme ich Zugriff, dass ich es in deinen Dev Branch pushen kann?

[JuMi2006]

Nächstes Problem nach einem Update auf die neueste Arduino IDE:

Build-Optionen wurden verändert, alles wird neu gebaut
GroupWrite:4: error: taking address of temporary array
GroupWrite.ino: In function 'void loop()':
GroupWrite:52: error: taking address of temporary array

Heißt also er erwartet einen festen Wert.
Um in meinem Sketch weiter zu kommen hab ich also erstmal folgendes gemacht:

byte pa_byte[2] = {0B11111111, 0B00000000};
KnxTpUart knx(&Serial1, pa_byte);

Dabei wirft er dann aber Fehler in Zeile 195, 305, 311 und 320 der KnxTpUart.cpp in der jeweils mit PA_INTEGER gearbeitet wird.

/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp: In member function 'bool KnxTpUart::readKNXTelegram()':
/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp:195:135: error: taking address of temporary array
             sendNCDPosConfirm(_tg->getSequenceNumber(), PA_INTEGER(_tg->getSourceArea(), _tg->getSourceLine(), _tg->getSourceMember()));
                                                                                                                                       ^
/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp: In member function 'bool KnxTpUart::individualAnswerAddress()':
/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp:305:88: error: taking address of temporary array
     createKNXMessageFrame(2, KNX_COMMAND_INDIVIDUAL_ADDR_RESPONSE, PA_INTEGER(0,0,0), 0);
                                                                                        ^
/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp: In member function 'bool KnxTpUart::individualAnswerMaskVersion(int, int, int)':
/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp:311:108: error: taking address of temporary array
     createKNXMessageFrameIndividual(4, KNX_COMMAND_MASK_VERSION_RESPONSE, PA_INTEGER(area, line, member), 0);
                                                                                                            ^
/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp: In member function 'bool KnxTpUart::individualAnswerAuth(int, int, int, int, int)':
/Users/mh/Dropbox/Arduino/libraries/KnxTpUart/KnxTpUart.cpp:320:121: error: taking address of temporary array
     createKNXMessageFrameIndividual(3, KNX_COMMAND_ESCAPE, PA_INTEGER(area, line, member), KNX_EXT_COMMAND_AUTH_RESPONSE);

Any ideas ? Also muss da grundsätzlich was geändert werden.

[tuxedo]

Habs in dem Example gefixed und ins git geschoben. Rest der Examples folgt ...

https://github.com/JuMi2006/KnxTpUart/tree/develop

Jepp, hatte die Examples nicht angepasst, da ich nur an meinem eigenen Sketch gearbeitet hatte.

[JuMi2006]

Habs in dem Example gefixed und ins git geschoben. Rest der Examples folgt ...

https://github.com/JuMi2006/KnxTpUart/tree/develop