ESP8266 KNX mit ETS

[mumpf]

Hi,

weiß jemand, wo im Stack die initiale Größe für das address_table_object und das association_table_object gesetzt wird? Ich hab mir gestern den Wolf gesucht, aber nichts gefunden!

Aus den Antworten an die ETS (PID_TABLE_REFERENCE) mit 0x0117 und 0x0217 sehe ich, dass die 0x100, also 256 Byte groß sind, aber ich will die auf 2048, also 0x800 setzen. Über einen Tipp würde ich mich freuen.

Gruß, Waldemar

[OutOfSync]

Hi,

weiß jemand, wo im Stack die initiale Größe für das address_table_object und das association_table_object gesetzt wird? Ich hab mir gestern den Wolf gesucht, aber nichts gefunden!

Aus den Antworten an die ETS (PID_TABLE_REFERENCE) mit 0x0117 und 0x0217 sehe ich, dass die 0x100, also 256 Byte groß sind, aber ich will die auf 2048, also 0x800 setzen. Über einen Tipp würde ich mich freuen.

Gruß, Waldemar

Hi Waldemar,

wird die nicht im knxprod im "applicationprogramm.xml" definiert und dann beim Hochladen genutzt? In meinen Projekten steht da z.B.

<AddressTable MaxEntries="255" />
<AssociationTable MaxEntries="255" />

Gruß, Julius

[mumpf]

Hi Julius,

danke, aber die Info in der knxprod ist für die ETS. Aber irgendwo muss auch in der Firmware, also in dem knx-Stack, auch hinterlegt sein, wie groß die beiden Tabellen sind. Ich habe z.B. rund 450 KO, brauche also 2 Byte um diese zu adressieren. Und wenn ich mehr als 255 GA haben will, muss diese auch mit 2 Byte adressiert werden. Wenn meine Tabellen aber nur 256 Byte auseinander liegen, dann passen da nur 128 Objekte rein, das ist schlecht. Deswegen suche ich die Stelle im Coding, wo ich das neu setzen kann, ich finde die nur nicht.

Es geht also um den Stack, nicht um die knxprod.

Gruß, Waldemar

[OutOfSync]

Hi Waldemar,

ok, ich verstehe was Du meinst. Ich dachte das wird dynamisch nach dem Programmieren mit der ETS alloziert je nach benötigter Größe (letztendlich TableObject::allocTable) und mit TableObject::initializeProperties initialisiert. Ich hatte die MaxEntries beider Tabellen in der knxprod von 256 auf 512 hochgesetzt und konnte dann einfach ohne irgendeine Änderung am Stack (nach ETS Neuprogrammierung) damit arbeiten. Die Länge der Tabelle wird im Index 0 abgelegt (AddressTableObject::entryCount). Ich erinnere mich nicht dass da ein Wert im Stack hartkodiert wäre. Die Lage der Tabellen im EEPROM wird von der Speicherverwaltung verwaltet, daher ist nach Änderung der Tabellengröße auch eine Neuprogrammierung der physikalischen Adresse/Applikationprogramm nötig damit die Blöcke an der richtigen Position gefunden werden. Die Größe wird in den Metadaten bei TableObject::saveSize() berechnet. Das ist aber alles aus dem Kopf raus geschrieben. Vielleicht reden wir aber auch aneinander vorbei...

Gruß, Julius

[mumpf]

Hi,

Vielleicht reden wir aber auch aneinander vorbei...

ich glaub schon, dass das die richtige Ecke ist. Dynamisch von der ETS vergeben... das kann natürlich sein. Ich muss nochmal die Kommunikation verifizieren, ich hab nie eine Längenangabe gesehen, aber auch nicht speziell drauf geachtet.

Ich wollte eigentlich feste Speicherbereiche, damit partiell programmieren immer klappt (und weil ich mit festem Speicherbereich auch besser testen kann). Ich werde mich über Ostern mal durch die Programmierung durchdebuggen und hoffentlich neue Erkenntnisse gewinnen.

Die von Dir erwähnten Stellen schaue ich mir nochmal an, aber ich glaube, da war ich schon überall mal.... Bin aber immer davon ausgegangen, dass die Größe (oder zumindest eine Initiale Größe) irgendwo angegeben sein muss.

Gruß, Waldemar

[mumpf]

Hi,

wie hast du denn SERIAL_BUFFER_SIZE auf 256 erhöht? Welche Änderung genau in welchem File ?

ich wollte hier nochmal nachfragen, ob Du noch eine andere Idee hast? Ich habe inzwischen verifiziert, dass im RingBuffer.h der Wert aus meiner Compiler-Option genommen wird. Deswegen gehe ich auch davon aus, dass es im Uart.h genommen wird. Gibt es bei der Arduino-Plattform noch andere Files? Ich frage nur, weil Tante Google auch keine neuen Erkenntnisse gebracht hat.

Wobei es mit den aktuellen 53 Byte Nutzdaten auch schon toll läuft (Faktor 2.5). Und meine Schnittstelle scheinbar auch nur 63 Byte Nutzdaten kann. Aber ich würde gerne den Stack auf das Maximum setzen, falls andere Leute Schnittstellen haben, die mehr können.

Gruß, Waldemar

[Ing-Dom]

ich wollte hier nochmal nachfragen, ob Du noch eine andere Idee hast?

nein, ich denke das passt. Ich hätte auch noch eine Überprüfung empfohlen, direkt an der Stelle worauf aus ankommt, bzgl. Präprozessor kann man da nicht vorsichtig genug sein

[OutOfSync]

Hi,

ich habe mich mit der Seriennummer der Geräte etwas auseinandergesetzt. Bisher war die ja fix programmiert auf 0x01020304 was Probleme macht wenn mehrere Geräte in der Installation sind (https://github.com/thelsing/knx/issues/90).

Die Lösung ist eine unique ID zu nutzen. Das habe ich testweise eingebaut (https://github.com/OutOfSync1/knx/commit/4018d98d0e5e65d536bc14ef5239fb3827058862). Ich hoffe dass ich das in KnxFacade() an der richtigen Stelle setze, direkt nach dem Überschreiben der Manufacturer Id.

Ausprobiert habe ich das nur auf dem ESP32, ESP8226 und STM32/SAMD sind "ins Blaue" rein programmiert. CC1310 und Linux fehlen ganz, da ist der Fallback auf 0x01020304. Vielleicht finden sich noch ein paarTester

Gruß, Julius

[mumpf]

Hi Julius,

cool, das werde ich auch noch in meinen Stack übernehmen. Dann kann ich die Geräte auch noch über die Seriennummer programmieren, falls ich mal den Prog-Knopf bräuchte und zu faul bin, die auszubauen...

Gruß, Waldemar

[thewhobox]

OutOfSync wow sehr geil!

Arbeite bei der Kaenx auch viel mit der Seriennummer (zum finden neuer Geräte oder Adresse überschreiben).
Läuft der Stack eig auch auf einem Atmega?
Hab davon daheim noch einige rumliegen.

Gruß Mike

[mumpf]

Hi Mike,

Läuft der Stack eig auch auf einem Atmega?

das würde ich bezweifeln. Ich kenne mich aber nicht so in der Arduino-Welt aus... Aber wenn es nur ums das Ausprobieren vom Stack geht, solltest Du das auf einem Raspi machen, mit der Linux-Variante. Dann kannst Du auch über einen Router programmieren und brauchst keinen TP-Anschluss.

Gruß, Waldemar

[thewhobox]

Das mit dem TP Anschluss wäre kein Problem. Hab die MicroBCU.
Wollte sowas auch bei nem Kumpel einbauen.
Hab auch nur ne IP-Schnittstelle.

Vll kann ich ja mal nen Port machen für atmel, wenn ich wieder mehr Zeit habe.

Gruß Mike

[mumpf]

Nee, vergiss es. Wenn ich das eben richtig gesehen habe, sind das 8-Bit, 32k Flash und 2,5k Ram.

Wenn ich nur den Stack compiliere, braucht der schon um die 50k Flash und 5k Ram. Und dann ist da noch keine Firmware drauf und kein Parameter der Applikation.

Für so was ist der nicht gemacht. Nimm irgenein SAMD21 Board, damit geht das super! Da die MicroBCU dran und es läuft 1A.

Gruß, Waldemar

[Ing-Dom]

man, vergesst die atmegas... die sind aus dem letzten Jahrtausend ...

[mumpf]

Hi Thomas et al,

ich wollte euch mal Feedback über 2 Anpassungen im Stack berichten, die meiner Meinung nach große Auswirkungen haben und den Stack weiterbringen würden. Das eine adressiert den eigentlich schon lange vorhandenen "Longframe-Support", und zwar in device_object.cpp:

        case PID_MAX_APDU_LENGTH:
            pushWord(56, data);
            break;

Da steht im Original 254 bzw, 0xFE und ist zwar die maximale Telegrammlänge, die der Stack kann, aber zumindest auf der SAMD-Plattform habe ich es nicht hin bekommen, die serielle Schnittstelle zu mehr als 64 Bytes zu überreden. Und dann sind da wohl noch 10 Byte "Verwaltungsdaten", so dass 56 für die APDU übrig bleiben.. Was also unter dem SAMD beim programmieren passiert, ist folgendes (eine Schnittstelle vorausgesetzt, die APDU-Längen > 15 unterstützt):

• ETS fragt PID_MAX_APDU_LENGTH ab, bekommt 254
• Sie bildet das Maximum aus APDU der Schnittstelle und APDU des Stacks, das ist bei meiner Schnittstelle 66.
• Dann wird mit der Länge versucht zu programmieren, das geht schief.
• Die ETS versucht es noch ein 2. mal, geht natürlich auch schief.
• Dann macht sie mit APDU 15 weiter

Faktisch gewinnt man nichts mit dem Setting, es dauert sogar länger, da die beiden Versuche der ETS das Programmieren um ca. 10 Sekunden verzögern. Der Stack hat also einen Long-Frame-Support, der aber nicht genutzt werden kann. Meiner Meinung nach sollte das auch bei der knx secure implementierung probleme verursacht haben, habe aber keine Erfahrung damit.

Das blöde ist, dass PID_MAX_APDU_LENGTH eigentlich plattformabhängig ist und im Stack eigentlich so implementiert werden sollte. Dazu sehe ich mich nicht in der Lage, vor allem weil ich den Stack ja so nicht verwende und es somit nicht testen kann. Aber vielleicht kann ja jemand den Default-Wert von 254 auf 56 setzen, ich vermute, das würde auf den meisten Plattformen laufen und bringt schon mal einen Faktor 2 bei allen Programmierungen. Letzteres kann ich natürlich auch als Pull-Request machen, das würde ich noch schaffen .

Das 2. ist der Support fürs partielle Programmieren. Das ist - meiner Meinung nach - der Hammer schlechthin!!! Die Diskussion dazu hatten wir ja hierhin (https://knx-user-forum.de/forum/%C3%...-programmieren) ausgelagert, es war schon toll, was nach nur 2 Wochen "rumprobieren" rausgekommen ist. Inzwischen nutze ich das produktiv in allen meinen Modulen und bin begeistert. Ich hatte bei der Änderung von einem 1-Byte-Parameter folgende Programmierzeiten (bei einem Parameter-Block von 8651 Byte):

• ohne Longframe, ohne partiell-Support (also der aktuelle Stand vom Stack):
  • Ganze Applikation: ca. 3 - 3.5 Minuten
  • Partiell (in der ETS ausgewählt): ca. 3 Minuten (hier wurde immerhin die KO und GA Übertragung von der ETS weggelassen)
• mit Longframe (also mit APDU=56), ohne partiell-Support:
  • Ganze Applikation: ca. 1.5 - 2 Minuten (bringt somit etwa Faktor 2)
  • Partiell (in der ETS ausgewählt): ca. 1.5 Minuten (da auch hier wieder KO und GA Übertragung wegfällt)
• ohne Longframe (alte Schnittstelle mit APDU=15), mit partiell-Support vom Stack:
  • Ganze Applikation: ca. 60 Sekunden (hier werden alle 0x00 nicht übertragen)
  • Partiell: ca. 10-15 Sekunden (hier wird neben den ganzen Verwaltungsinformationen und Zustandsübergängen wirklich nur das 1 Byte übertragen)
• mit Longframe (also mit APDU=56), mit partiell-Support vom Stack (hier nochmal der Faktor von ca. 2 gegenüber der Variante ohne Longframe):
  • Ganze Applikation: 25-30 Sekunden
  • Partiell: etwa 5-7 Sekunden (es wird auch nur das 1 Byte übertragen, die Verwaltungsinformationen aber in größeren Frames)

Ich finde das beachtlich und möchte es nicht mehr missen. Immerhin geht es hier um eine Steigerung von bis zu Faktor 36 (Idealfall, von 3 Minuten auf 5 Sekunden), häufig noch Faktor 25 (normalfall, von 3 Minuten auf 7 Sekunden). Natürlich verschwindet der Vorteil von partieller Programmierung, je weniger Parameter man hat und je mehr man bei einer Programmierung ändert/ändern muss.

OutOfSync hat netterweise schon eine Portierung meiner Lösung auf den aktuellen Stack gemacht. Hier sind die Änderung primär in table_object.cpp. Vielleicht kann seine Lösung in den Stack einfließen, damit die Sachen nicht noch weiter auseinanderlaufen. Ich bin nicht stolz darauf, auf einem Fork zu arbeiten, aber weiß einfach nicht, wie ich die von mir genutzte Flash-Implementierung in den Originalstack bringen soll. Zumindest versuche ich auf diesem Weg, meine Erfahrungen zu teilen und Anregungen zu geben.

Gruß, Waldemar