selfbus.org

Eure Erkenntnisse erklären auch endlich das merkwürdige Verhalten, was ich damals bei der Programmierung des strommessenden Schaltaktors im Zusammenhang mit ETS5.6 beobachtet hatte. Wenn ich die alten Logs nochmal angucke, finde ich auch darin, dass eine falsche Adresse 0x4CBE in die commsTabAddr eingetragen wird. An anderer Stelle wird die richtige Adresse 0x4400 übertragen, die schafft es jedoch nicht an die richtige Stelle.

Ja, und das liegt genau an der Stelle

in der properries.cpp :

Code: Alles auswählen

    case 2:  // Segment control record
        // addr is used for addr tab, assoc tab, app main()
        if (objectIdx == OT_ADDR_TABLE)
            userEeprom.addrTabAddr = addr;
        else if (objectIdx == OT_ASSOC_TABLE)
            userEeprom.assocTabAddr = addr;
        else if (objectIdx == OT_APPLICATION)
        {
#if BCU_TYPE == BIM112_TYPE
        userEeprom.commsTabAddr = addr;
#endif

wo fälschlicherweise die Zeile
ObjectIndex=3, PropertyId=5, Count=1, StartIndex=1, Data= 03 02 45 30 00 01 12 00 01 10
der ETS genutzt wird, um die commsTabAddr zuzuordnen. Oft passt es, dass nach der 03 02 die richtige commsTabAddr kommt, aber leider eben nicht immer !
Ob das so auch für die addrTabAddr und die .assocTabAddr zutrifft, müsste mal noch untersucht werden. Scheinbar gab es da bisher aber noch keine praktischen Probleme.

Liebe Grüße, und eine gute Nacht

Hallo,

luckychild hat geschrieben: ↑7. Mär 2021, 22:39 prima, mir scheint, wir sind uns in der Erkenntnis des Problems einig

Definitv. Du hast da einen Bug gefunden, der zu größeren Problemen geführt hat, bzw. langfristig führen wird.
In älteren Produktdatenbanken werden die Adressen per A_Memory_Write, in neueren per A_PropertyValue_Write geschrieben (u.a. bei deiner Helios, der vom out-cs-bim112 und wahrscheinlich auch hier).

Sowohl Florians als auch dein Ansatz sind aber eben nur Workarounds. Die sblib sollte eigentlich anhand der Telegramme die von der ETS kommen die Adressen richtig verarbeiten.

Bei deiner Helios Produktdatenbank wird z.B. die richtige Adresse per LoadEvent: AllocAbsDataSeg (segment type 0) (KNX Spec 3/5/2 Seite 114) übermittelt, die sblib ignoriert das aber komplett und es wird dann später durch LoadEvent: AllocAbsTaskSeg (segment type 2) (KNX Spec 3/5/2 Seite 115) überschrieben. Eine Einleitung zu dem Thema ist in der KNX Spec. 2.1 im Kapitel 2/3/1. Die Sache ist leider nicht ganz trivial, sollte aber langfristig trotzdem Einzug in die sblib finden meine ich. Falls das jemand übernehmen will, Freiwillige vor

. Ich wollte eigentlich erstmal für den out8-bcu1 abliefern.

luckychild hat geschrieben: ↑7. Mär 2021, 22:39 properties.cpp ...
userEeprom.commsTabAddr = bcu.commsTabAddr;

Genau die Stelle hatte ich bzgl. Kompatibilität zu bestehenden Apps als problematisch angesehen

.

luckychild hat geschrieben: ↑4. Mär 2021, 21:44 Wie funktioniert eigentlich der Commit Prozess für die ARM Lib in Github bzw. wo muss man da evtl. Änderungen beantragen

Wende dich dazu mal an Doumanix.

Viele Grüße
Denis

Hallo zusammen,

grad noch was gefunden. In der .knxprod (bzw. entpackten .xml) kann es den Abschnitt <LoadProcedures> geben. Da ist meiner Meinung nach beschrieben, wie die Applikation geladen werden soll.(hier als Beispiel die Helios PDB)

Code: Alles auswählen

<LoadProcedures>
  <LoadProcedure>
    <LdCtrlConnect />
    <LdCtrlUnload LsmIdx="1" />
    <LdCtrlUnload LsmIdx="2" />
    <LdCtrlUnload LsmIdx="3" />
    <LdCtrlLoad LsmIdx="1" />
    <LdCtrlAbsSegment LsmIdx="1" SegType="0" Address="16384" Size="511" Access="242" MemType="3" SegFlags="128" />
    <LdCtrlTaskSegment LsmIdx="1" Address="16384" />
    <LdCtrlLoadCompleted LsmIdx="1" />
    <LdCtrlLoad LsmIdx="2" />
    <LdCtrlAbsSegment LsmIdx="2" SegType="0" Address="16895" Size="511" Access="242" MemType="3" SegFlags="128" />
    <LdCtrlTaskSegment LsmIdx="2" Address="16895" />
    <LdCtrlLoadCompleted LsmIdx="2" />
    <LdCtrlLoad LsmIdx="3" />
    <LdCtrlAbsSegment LsmIdx="3" SegType="0" Address="1792" Size="248" Access="242" MemType="2" SegFlags="0" />
    <LdCtrlAbsSegment LsmIdx="3" SegType="0" Address="17406" Size="316" Access="242" MemType="3" SegFlags="128" />
    <LdCtrlAbsSegment LsmIdx="3" SegType="0" Address="17920" Size="21" Access="34" MemType="3" SegFlags="128" />
    <LdCtrlTaskSegment LsmIdx="3" Address="17712" />
    <LdCtrlTaskCtrl1 LsmIdx="3" Address="17665" Count="1" />
    <LdCtrlLoadCompleted LsmIdx="3" />
    <LdCtrlRestart />
    <LdCtrlDisconnect />
  </LoadProcedure>
</LoadProcedures>

Viele Grüße
Denis

Die sblib sollte eigentlich anhand der Telegramme die von der ETS kommen die Adressen richtig verarbeiten.

Ja, das wäre natürlich wünschenswert. Hab mich bisher leider noch nicht groß mit der KNX Spec (hab sie erst vor kurzem bekommen) befasst, dafür aber recht intensiv den Code der ARM Lib analysiert und auch die Kommunikation mit der ETS.
Dabei ist mir aufgefallen, dass dies- wie Denis schon erwähnt hat - leider nicht so trivial wird, zumal ja der Informationsaustausch zwischen ETS und ARM Lib - je nach App bzw. knxprod - recht verschieden laufen kann. Um sicher zu sein nicht wieder bei irgendeiner App in irgendeine "Falle" zu tappen, hätte ich das - vielleicht etwas unbequemere - Vorgehen mit der direkten Übergabe der Adressen derTabellen über bcu_base.begin() favorisiert.
Nachteil: Man muss die Adressen selbst aus der knxprod ermitteln - was man allerdings eh schon mit einigen anderen Daten machen muss.
Vorteil: Man ist sicher, dass alle Tabellen - unabhängig von den Eigenheiten der App (knxprod) - wirklich an den richtigen Adressen liegen.
Wenn jemand also eine gute Idee hat wie die Adressen wirklich Zielsicher und Nachhaltig aus den unterschiedlichen Telegrammen extrahiert werden können wäre das interessant. Allerdings würde ich den "Kunden" der ARM Lib trotzdem über eine überladene bcu_base.begin() zugestehen die Adressen im Zweifelsfall auch selbst per Hand zuordnen zu dürfen.
Die Diskussion um die beste Vorgehensweise ist hiermit also eröffnet.

Viel Spaß, und liebe Grüße

Hm, eigentlich dachte ich die Diskussion um den Besten Lösungsansatz nimmt jetzt erst Fahrt auf, aber anscheinend schläft die Sache gerade eher etwas ein. Ich würde ja auch gerne helfen das Problem zu fixen. Frage ist nur wer das dann "genehmigt" und mir Schreibzugriff aufs Github Repository geben kann.

Liebe Grüße

Also ideal wäre, wenn du die Änderung im persönlichen Clone der sblib machst und von dort einen Pullrequest Richtung selfbus/sblib machst.

Ich könnte dir auch den direkten Zugriff auf das Repo geben. Aber ein Vierauchenprinzip wäre schon gut (PR mit Genehmigung).

Hallo luckychild,

ganz im Gegenteil. Ich habe die letzten Tage damit verbracht. U.a. weiß ich jetzt, dass in den ca. 3900 Produktdatenbanken, die im ETS Katalog sind, ca. 800 den Part

Code: Alles auswählen

<LdCtrlTaskSegment LsmIdx="5" Address="xxx" />

verwenden und damit die Adresse der ComObjectTable gesetzt wird. Lediglich bei 28 PDB's stimmt das nicht. LsmIdx="5" steht für "KNX object association table object interface" und wird von der sblib z.Zt. ignoriert. Damit wäre zumindest das Problem welches bei Florian seinem out6-cs-bim112 aufgetreten ist behoben. Den von dir gefundenen Fehler behebt das allerdings nicht. Da sitze ich noch dran und versuche genauer zu verstehen, was da eigentlich die ETS mit der App machen will.

Dein Fix in der bcu_type.h würde alle bisherigen bim112 (MaskVersion 0x0701) zu bim112 (MaskVersion 0x0705) machen.
Ob man wirklich für die MaskVersion 0x0705 eine separate build-konfiguration machen muss, sollte auch noch gecheckt werden, insbesondere was die Unterschiede zwischen 0x0701x & 0x0705 sind.

Du kannst mich gerne im Slack anschreiben, da bin ich z.Zt. eigentlich täglich am Start.

Viele Grüße
Denis

Hi Denis,
prima, dass du da dran bist.

War mir nur nicht sicher, weil ja jetzt eine Weile "Funkstille" war. Klar, das mit der MaskVersion 0x0705 in der bcu_type.h muss man sich auch nochmal anschauen (=> Quick Fix

) Ich konnte bisher die Unterschiede zwischen 0x0701 und 0x0705 auch nicht hinreichend klären. Das Einzige was zumindest bei mir nötig war, war neben der Änderung der BIM112_TYPE auch der PROP_LOAD_OFFSET von 0. Frage ist ob wir anfangen wollen die MaskVersion 0x0705 zumindest vorläufig mal als EXPERIMENTAL zu unterstützen.
Um das Problem der falschen Zuordnung von Adressen an die Tabellen zu umgehen, würde ich - wie bereits erwähnt - gerne die bcu_base.begin() überladen, um neben der bereit bestehenden (etwas unsicheren) automatischen Erkennung der Adressen die Möglichkeit der manuellen Übergabe zu schaffen. Damit bleiben wir kompatibel zu den bestehenden Apps, schaffen aber im Zweifelsfall eine zusätzliche Möglichkeit.

Liebe Grüße

Bzgl. der Unterschiede der Maskenversion findet Ihr evtl. im KNX Standard 06_Profiles unter 4.2 (Seite 32), was Ihr sucht.

selfbus.org

Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?

Re: Bug in der ARM Lib ?