Konfiguration von DIY-Geräten

[JuMi2006]

Um auf alles bisher gesagte zu reagieren ist es zu spät .

Ich bin jetzt mit meinem Skeleton soweit dass die Programmierung der PA per ETS funktioniert. Danach geht die Programmier-LED auch brav aus und der Arduino startet neu. Ebenso funktinert das Auslesen der MaskVersion. Die writeaddress-Geschichte muss ich mir noch ansehen.
Das ist im Vergleich zu Max und Robert zwar noch nciht viel aber ich wäre bereit die Properties und Objects in die Arduino Library einzuarbeiten. Ich hinke also ein wenig hinterher, zeitlich geht momentan aber nix weiter.

Vielleicht kann da jemand von euch mit Code unterstützen damit es in die Library kommt?

[l0wside]

Ich schaue mal, ob ich am Wochenende meinen C-Code entsprechend erweitern und generalisieren kann. Dann stelle ich ihn gerne zur Verfügung.

Max

[JuMi2006]

So vielleicht doch noch ein paar Worte.

EEPROM:
Der Arduino kommt mit mindestens 512 Byte daher.

Arduino-Fraktion:
Ich denke eigentlich ist es selbstredend, aber zur Sicherheit nochmal - Ich würde mich dieser Problematik annehmen.

BCU2 Kompatibilität:
Ich denke man sollte es versuchen da im "Standard" zu bleiben.

Für mich bleiben dann noch zwei Fragen:
Wollen wir uns auf eine bestimmte Verwendung der EEPROM-Bytes einigen oder soll/darf jeder sein eigenes Süppchen kochen.
Gerade der Umzug von Arduinos auf PCBs würde leichter fallen wenn man Teilfragemente des Codes übernehmen könnte. Das Debuggen eines Arduinos ist ja noch recht einfach, bei einem echten µC wird das schon wieder schwieriger.
Ich verstehe immer noch nicht die Rechnung eures Speicherbedarfs. Eine GA hat doch 2Byte? Bei mir wären dann 3 KO zu je 8 GAs: 3x8x2 = 96Byte.
Aber ich gebe zu dass mit das mit den Bits und Bytes nicht 100% liegt.

[l0wside]

BCU2 Kompatibilität:
Ich denke man sollte es versuchen da im "Standard" zu bleiben.

OK. Ich kümmere mich um den Code. Wie genau das alles dann im EEPROM liegt, halte ich für sekundär; Zugriff sollte ohnehin über entsprechende Funktionen erfolgen.

Ich verstehe immer noch nicht die Rechnung eures Speicherbedarfs. Eine GA hat doch 2Byte? Bei mir wären dann 3 KO zu je 8 GAs: 3x8x2 = 96Byte.

3x8=24
24x2=48
Warum 96?

Bei einer 1:1-Umsetzung der BCU2 ist das aber ziemlich egal, weil dann ohnehin mit zwei getrennten Tabellen (Objekte 1 und 2) gearbeitet werden muss.

Max

[JuMi2006]

Peinlich, klar ... war wohl ne morgendliche Mathe-Schwäche!

[JaKop]

Das XML Format sieht interessant aus. Aber ich würde mir hier was noch einfacheres wünschen.

auch wenn ich hier nicht so aktiv bin, bin ich inzwischen eher ein Fan von JSON statt von XML, weil es einfach kompakter ist.
Diese Beschreibung würde dann in etwa so aussehen:

{  "device-id":{
        "device-manufacturer":"Kalassi",
        "device-name":"Multisensor",
        "device-manufacturer-id":004C,
        "application-versions: [
            {"version":001234560801},
           {"version":001234560802}
        ]
    }
},
{    "objects":[
    {   "id":"10",
        "name":Temperature",
        "parameters": [
        {   "id"="1"
            "description":"Temperature Transmit Interval in seconds",
            "type":uint16,
            "min": 5,
            "max": 3600,
            "unit": "sec"
         },
        {   "id="2",
            "description":"Temperature offset, 
            "type":int16,
            "min": -5,
            "max": 5,
            "factor":100				<!-- Umrechnung von eingegebenem zu übertragenem Wert -->
        }
        ]
    },
    {   "id:"20",
        "name"="Humidity",
        "parameters": [
        {   "id":"1",
            "description":"Humidity Transmit Interval in seconds",
            "type":uint16,
            "min": 5,
            "max": 3600
        }
        ] 
    }
    ]
}

just my 2ct.

Gruss
Jan

[l0wside]

Mir persönlich ist´s ziemlich egal. Soll ich eine Abstimmung JSON/XML ansetzen?

Max

[JaKop]

Ich denke dass hier die Macht des Machers gegeben ist.
Wenn XML umgesetzt ist, würde ich es nicht ändern. Wenn jemand (ich hab leider keine Zeit) es umsetzt, soll er entscheiden welcher "Dialekt" ihm lieber ist.

Gruss
Jan

[l0wside]

Ich habe mich mal darangemacht, meine Konfiguration auf BCU2 umzubauen. Gefühlt ist das der Transfer von KISS nach Bloat, aber sei´s drum. Wenn der Code fertig ist, stelle ich ihn (u.a. für die Arduino-Fraktion) zur Verfügung.

Ich habe noch nicht so recht verstanden, wo die Flags im Application Object genau gesetzt werden. Der Communication Object Table sieht so aus:

• 1 Byte Object Count
• 1 Byte RAM Flag Table Pointer. Wohin zeigt der? Mit 1 Byte kann man bestenfalls einen Offset angeben, aber nicht arbiträr in den Speicher zeigen
• Data pointer/Config byte/Type byte.
  • Wohin zeigt dieser Data Pointer? Identisch mit dem RAM Flag Table Pointer ist er nicht. Oder ergibt sich aus der Kombination beider dann die eigentliche Adresse?
  • Zeigt das Config Byte die gesetzten Bits für das entsprechende KO, oder sind das die Bits, die überhaupt gesetzt werden können?
  
  

Kann mich bitte jemand aufklären?


Außerdem noch ein Punkt: Mein µC hat Flash, kein EEPROM. Hat jemand einen Vorschlag für eine sinnvolle Speicherstrategie? Ich kann natürlich bei jedem Schreibzyklus einen Erase/Write-Zyklus machen, aber das ist unschön. Lieber sammle ich im RAM und schreibe die Daten dann auf einen Rutsch weg.


Dazu braucht es aber einen passenden Trigger. Hat jemand eine bessere Idee als einen Timeout?


Max

[Robert]

Die BCU2 hat mit ihrem MC68HC05 nur zwei kleine Speicherbereiche - kleiner Speicher - Eindeutigkeit gegeben.

Dies ist natürlich einer der Gründe warum es mittlerweile ganz andere Gerätemodelle gibt - daher nicht zu eng nachimplmentieren - ich hatte meine Sicht dazu ja schon beschrieben.

EEPROM: Stichwort EEPROM-Emulation im Flash: Seite komplett löschen, neue Einträge werden jetzt sequentiell mit <emulierte ROM-Addresse><Wert> geschrieben. ROM-Adresse 0 ist nicht gültig und markiert das Ende der Liste. Immer das letzte Tuple einer Adresse ist das aktuelle:
<3,56>,<2,4711>,<3,64> -> EEPROM-Adresse 3=64, Adresse 2=4711
Wenn Page voll werden die jeweils letzen Werte in neue Page geschrieben und die alte Page komplett gelöscht. Das Verfahren ist ziemlich Standard.

Ansonsten: Schreiben bei "Restart" (mrestart).

Hoffe das hilft dir ein wenig.

Grüße
Robert

[l0wside]

Daher nicht zu eng nachimplmentieren - ich hatte meine Sicht dazu ja schon beschrieben.

Ich wurstle schon seit ein paar Tagen eher unmotiviert an der Umstellung auf BCU2-Kompatibilität herum und habe mir nun endlich mal die BCU2-Applikation in die ETS geladen. Da ist ja quasi gar nichts zu konfigurieren - welchen Vorteil hat die Kompatibilität nun genau? Meine alte Lösung war mir sympathischer.

Die EEPROM Emulation habe ich nun ganz einfach gelöst: ich halte die Daten im RAM und schreibe sie erst ins Flash, wenn das SAVE-Signal kommt (setzt der TPUART2 bei Zusammenbrechen der externen Versorgung). Da sind rund 80ms Zeit zum Schreiben, das sollte für ca. 1 kB locker reichen.

Max

[Steph]

Hallo zusammen,
ich würde mich hier auch gerne ein wenig einbringen (Baustelle ist in der Endphase). Erfahrung mit Softwareentwicklung, Mikrocontroller und Linux ist vorhanden. In die KNX-Sachen muss ich mich erst einlesen.

3. Umsetzungsvorschlag (zur Diskussion)
Gegenüber dem BCU2-Ansatz würde ich einige Dinge ändern:

• In der BCU2 von Martin Kögler ist die Trennung Busankoppler/Gerät klar erkennbar, wo ein Teil der Software im Busankoppler läuft und dann über das PEI-Interface das eigentliche Gerät anspricht. Bei allen Projekten, die ich hier im Forum gesehen habe, wird ein integrierter Busankoppler verwendet, auch mein Stack unterstützt nur die integrierte Variante.
• Speicherzugriffe sind aus meiner Sicht nicht gut und auch nicht notwendig. Alles Notwendige lässt sich über Properties regeln.
• Das doppelte Mapping KO->Index->GA ist ein Schritt zu viel. Ein direktes Mapping KO->GA ist effizienter.
• Manche Properties der BCU2 können auch schlicht entfallen.

Für ein Update der Firmware im eingebauten Zustand sollten wir auch die Speicherzugriffe berücksichtigen, oder seht Ihr da noch andere Möglichkeiten?

[l0wside]

Hallo zusammen,
ich würde mich hier auch gerne ein wenig einbringen (Baustelle ist in der Endphase). Erfahrung mit Softwareentwicklung, Mikrocontroller und Linux ist vorhanden. In die KNX-Sachen muss ich mich erst einlesen.



Für ein Update der Firmware im eingebauten Zustand sollten wir auch die Speicherzugriffe berücksichtigen, oder seht Ihr da noch andere Möglichkeiten?

Hallo Steph,

prima! Ich habe die BCU2-kompatible Konfiguration zu einem größeren Teil implementiert, kämpfe aber gerade mit der Inbetriebnahme. Die üblichen Detailprobleme eben.

Ich habe mich schon mal mit Neuprogrammierung über den Bus beschäftigt, habe es aber nie richtig ans Laufen bekommen. Vielleicht bin ich aber auch nur zu ehrgeizig gewesen (Plan war Austausch des gesamten Codes, d.h. KNX-Stack und Applikation). Wenn ich endlich schaffe, den CCS-Linker dazu zu überreden, beide sauber zu trennen, mache ich ggf. nochmal einen Anlauf dazu - dann bleibt der Stack aber unveränderlich.

Wenn die aktuelle Implementierung so weit läuft, kann ich gerne ein Muster zur Verfügung stellen, um an einem Java-Konfigurationsprogramm zu arbeiten (andere Plattform geht natürlich auch).
Ansonsten: mit welchen µCs hast du denn Erfahrung?

Max

[Steph]

Eine Neuprogrammierung der Applikation würde sicher ausreichen. Erfahrung habe ich mit den AVRs von Atmel und dem NIOS II als SoPC von Altera.

Ich beschäftige mich gerade mit dem Falcon-SDK. Bzgl. Konfigurationsprogramm würde ich auf C# setzen. Habe nur wenig Erfahrung mit Java, aber das lässt sich ja ändern, wenn es Java sein muss.

Beispiel (Temperatur-/Feuchtesensor):
KO 10: Temperatur, KO 20: Feuchte. Temperatur soll alle 60 Sekunden gemessen werden, Feuchte alle 120 Sekunden. Temperatur geht auf GA 1/1/1, Flags KLÜ, Feuchte geht auf GA 1/3/5 und 1/3/6 und wird nur gesendet (Flags KÜ).

• Object 1, Property 2: Index 1=10, Index 2=20 (Liste der verfügbaren KO)
• Object 10, Property 0, Index 0: 0x0B (=KLÜ, siehe hier)
• Object 10, Property 0, Index 1: 0x0901 (1/1/1, zur Umrechnung z.B. hier)
• Object 10, Property 0, Index 2...7: 0x00 (= nicht belegt, GA 0/0/0 ist nicht zulässig, da Broadcast)
• Object 10, Property 1, Index 1: 60 (=60 Sekunden Intervall)
• Object 20, Property 0, Index 0: 0x0A (=KÜ)
• Object 20, Property 0, Index 1: 0x0B05 (GA 1/3/5)
• Object 20, Property 0, Index 2: 0x0B06 (GA 1/3/6)
• Object 20, Property 0, Index 3...7: 0x00 (= nicht belegt)
• Object 20, Property 1, Index 1: 120 (=120 Sekunden Intervall)

Vielleicht kann mir jemand auf die Sprünge helfen. Warum wird hier denn jeweils bei Property 1 der Index 0 ausgelassen?

[l0wside]

Eine Neuprogrammierung der Applikation würde sicher ausreichen. Erfahrung habe ich mit den AVRs von Atmel und dem NIOS II als SoPC von Altera.

Mit dem MSP430 bin ich wohl etwas exotisch...egal, für die Konfiguration von außen ist das egal.

Ich beschäftige mich gerade mit dem Falcon-SDK. Bzgl. Konfigurationsprogramm würde ich auf C# setzen. Habe nur wenig Erfahrung mit Java, aber das lässt sich ja ändern, wenn es Java sein muss.

Nein, es muss nicht Java sein (hätte allerdings den Vorteil, portabel zu sein, und den Nachteil, dass man Calimero noch ziemlich aufbohren müsste). Ich habe nur nach einem Abend mit der Falcon-Doku diesen Rant abgelassen. Von Windows-Programmierung lasse ich die Finger.

Vielleicht kann mir jemand auf die Sprünge helfen. Warum wird hier denn jeweils bei Property 1 der Index 0 ausgelassen?

Update kommt. Ich kümmere mich gerade um die weitgehende BCU2-Kompatibilität.

Max