ESP8266 KNX mit ETS

[thesing]

mumpf Kannst du dein Tool bitte auf github packen? Wenn es direkt auf der xml arbeitet macht es IMO keinen Sinne es in das Tool von Fabian zu integrieren, da diese auf dem aus dem xsd-basierenden Objektmodel arbeitet. Dann hätte man die Varianten:
- CreateKnxProd für einfache Sachen
- manuell xml erstellen/generieren und mit deinem Tool signieren

[mumpf]

thesing : Thomas, du hast Recht. Ich werde heute noch etwas aufräumen, dann gebe ich das Mal frei.

Danke übrigens für das xsd, mit ein paar Anpassungen kann man das gut zum editieren nutzen. Die Anpassungen sind nur Elemente aus meinem namespace für Erweiterungen wie z.B. include.

Gruß, Waldemar

[metaneutrons]

Servus zusammen...ich habe jetzt mal meine aktuellen Änderung gepusht. @mumpf: Bei mir funktioniert (wegen der Nutzung des Objektmodels) auch die Edit-Funktionalität, wenn ich manuelle Änderungen im XML-File vornehme.

Herzliche Grüße, Fabian

[mumpf]

Hi Thomas,

eine Frage, die sich aus der Antwort von Klaus Gütter in dem Thread https://knx-user-forum.de/forum/öffentlicher-bereich/knx-eib-forum/knx-einsteiger/1405379-ip-routing-mit-ets?p=1408990#post1408990 ergeben hat: Damit ich in der ETS5 unter "Gefundene Verbindungen" eine Netzwerkkarte sehe, muss ich den eibd (oder knxd) im Router-Modus laufen lassen. Wenn ich nur eine Linux-Instanz von meinem Logikmodul laufen lasse, dann sehe ich die Netzwerkkarte in der ETS5 nicht. So wie ich die Antwort von Klaus verstehe, sollte aber eine Instanz eines IP-Gerätes dazu führen, dass die Netzwerkkarte erscheint. Fehlt da im Stack noch was, dass der ETS5 korrekt antwortet?

Ist nur interessehalber, ich komme auch so klar, ich weiß jetzt, wie ich die Netzwerkkarte auswählen kann...

Gruß, Waldemar

[thesing]

Ja da fehlt noch was. Ich wollte damit als nächstes weiter machen.

[manu241]

Hallo,

verstehe ich dieses Projekt richtig, dass der Arduino ein "KNX-Gerät" ist, dass eigenständig ohne KNX-Kabel über ein KNX-Router Daten auf mein Bussystem schreiben kann, je nachdem welcher Sensor etc angeschlossen ist.

Ich finde es sehr intressant, da ich damit gerne einen Regenmesser realisieren würde (wie in diesem Projekt https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/diy-do-it-yourself/36798-arudino-knx-regenmesser nur ohne TPUART)

Gruß Manuel

[mumpf]

Hi Manuel,

ja, mit der ESP-Plattform kannst Du über das eingebaute WLAN-Modul und über Deinen KNX-Router Daten auf den Bus senden/empfangen. Das Projekt selbst kann noch viel mehr

Gruß, Waldemar

[manu241]

Hallo,

ich wollte mich morgen mal an diesem Projekt versuchen. Dazu habe ich mir das Demo-Projekt geladen, sowie das CreateKNXProd.
Dort steht:

Configuration: Change the path in CreateKnxProd.exe.config to your ETS4 Path. If you have ETS5 use the path to the ETS4 dlls of ETS5. For example: C:\Program Files (x86)\ETS5\CV\4.0.1997.50261 You can also change UICulture and Culture from 'de' to 'en' there.

Jedoch finde ich im Downloadverzeichnis dieses file :

CreateKnxProd.exe.config

nicht. Verstehe ich da etwas falsch?

Sorry für die Anfängerfragen.

Gruß Manuel

[manu241]

Moin,

Ich habe nun auch mal versucht das Demo-Projekt in ein Nodemcu 1.0 ESP-12E zu laden. Jedoch steht im Seriellen Monitor : ISR not in IRAM! Was hat das zu bedeuten und was müsste ich anders machen ?

Gruß Manuel

[mumpf]

Hi Thomas,

ich habe nach längeren Tests jetzt den Pull-Request fürs "Restart Device" gestellt. Es funktioniert mit allen Geräten, dich ich im Haus habe (wobei ich nicht jedes Gerät, sondern nur Gerätekategorie/Hersteller-Kombis getestet habe). Wäre schön, wenn das in den Haupt-Stack mit rein könnte.

manu241: Ich hab mit dem ESP noch nichts gemacht, aber so wie ich das verstanden habe, ist derzeit nur der ESP8266 und der ESP32 unterstützt. Und zum CreateKnxProd: Ich habe gerade mal Version 2.0 runtergeladen, das hat ohne Probleme geklappt und das config-File ist in dem Zip drin.

Gruß, Waldemar

[manu241]

Hallo mumpf,

Auf dem NodeMCU Wifi-Chip steht ESP8266MOD. Ich hoffe, dann sollte es passen, oder ? Geladen habe ich die KNX-Demo und Lade es via Arduino 1.8.10 in den NodeMCU. Jedoch wie geschrieben, bekomme ich diese Meldung:

ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1384, room 16 
tail 8
chksum 0x2d
csum 0x2d
v8b899c12
~ld
ISR not in IRAM!

Gruß Manuel

[mumpf]

Hi Manuel,

leider kann ich dir hier nicht helfen, ich bin auf der SAMD Plattform unterwegs. Ich hab mir zum Spielen einen ESP 32 besorgt, aber noch nichts damit gemacht.

Mir hat es aber sehr geholfen, die ersten Schritte unter Linux zu machen, und dann erst auf die Zielhardware zu wechseln.

Gruß, Waldemar

[manu241]

Oh mann... Ich war einfach nur zu dumm... Ich habe irgendwie die Falsche Version der KNX-Demo geladen ...
Nun geht schonmal etwas...

Gruß Manuel

[mumpf]

Hi Thomas ( thesing ) et all,

ich wollte hier mal ein paar Fragen zur Speicherverwaltung los werden und hoffe auf Tipps...

Ausgangssituation: Ich habe mal auf dem SAMD ein Speichern und Lesen der ETS-Daten auf einem I2C-EEPROM statt im Flash implementiert, in der Hoffnung, damit RAM zu sparen (das war zugegebenermaßen blauäugig und ohne es zu Ende zu überlegen). Die Daten werden ja immer erstmal ins RAM geladen, egal ob aus dem Flash oder aus dem EEPROM... Immerhin kann ich jetzt nach einem Flash der Firmware sofort testen, da die Parametrisierung der ETS nicht mehr verloren geht.

Dann habe ich mir den Startup vom knx-Stack weiter angesehen und festgestellt, dass die jeweiligen TableObject die Daten nochmal ins eigene Objektmodell deserialisieren, also wird der Inhalt nochmal ins RAM gepackt. Und wenn man so programmiert wie ich, dann packt man die Parameter- und KO-Werte in Variablen und hat dann so die Daten ein drittes mal im Speicher . Das "3. mal im Speicher" habe ich inzwischen behoben, aber ich hätte gerne noch mehr RAM frei .

Ich würde gerne folgendes probieren (aber vorher mit euch diskutieren, um nicht wieder komplett falsch zu liegen):

• TableObject wird so umgebaut, dass es nur mit einer Speicherreferenz auf den Anfang eines Speicherblocks arbeiten kann und kein einziger Wert ins RAM kopiert wird.
• Damit könnte man für die Parameter und die GA-Zuordnungen direkt auf den Flash referenzieren, da sich diese Tabellen ja zur Laufzeit nicht ändern (nur beim Programmieren -> kommt noch). Damit könnte man für diese Tabellen auf ein malloc verzichten.
• KO und deren Werte werden weiterhin im RAM belassen. Dazu muss hier ein malloc passieren, das müsste dann "außerhalb" der TableObject-Klasse passieren (oder über einen alternativen Konstruktor, das kann man ja noch sehen)
• Beim Programmieren gehe ich davon aus, dass die eigentliche Firmware (also das, was den Stack nutzt) gestoppt ist. Sollte diese RAM brauchen, dann wird dieser während der Programmierung nicht gebraucht und kann "missbraucht" werden - für die zu programmierenden TableObject (Parameter, KO und GA).
• Nach dem Programmieren werden die Daten ins Flash geschrieben und dann der SAMD neu gestartet, dann bekommt die Firmware ja ihr RAM wieder.
• Ich muss nochmal untersuchen, was beim partiellen Programmieren abgeht, das blicke ich noch nicht ganz, obiges würde nur (falls überhaupt) für das Programmieren der gesamten Applikation funktionieren.

Wenn das so gehen würde, hätte ich

• alle Parameter im Flash (bei mir ca. 5k, gerne mehr)
• alle GA-Zurodnungen im Flash (das können auch viele werden, wenn man viele KO hat)
• alle KO im RAM
• Es gibt noch eine 4. Tabelle, von der weiß ich nicht, was drin steht, aber die ist nie groß, könnte also auch ins RAM...

Liege ich da komplett falsch? Oder könnte das klappen?

Ich sage jetzt nicht, dass ich wirklich in der Lage bin, das zu programmieren - ich bin noch recht neu dabei, aber ich würde es gerne versuchen. Die Frage ist, was ich nicht bedacht habe oder ob ich etwas falsch verstanden habe...

Gruß, Waldemar

[Bernator]

lustig das du das genau jetzt schreibst, ich habe vor genau dazu einen pull request zu machen

habe den Stack nämlich folgendermaßen erweitert damit es möglich ist 3 unterschiedliche NV Memory "Typen" zu handeln:

• internalRam = externe Library welche die Daten eines externen Speichers selbst in den Ram kopiert (wie zb. die aktuell verwendeteFlashStorage lib). Hier wird den saveRestore Objekten dann aber nur der Pointer auf diese Daten übergeben und nicht nochmal dupliziert
• internalFlash = hier wird direkt (kleinere Buffer im Ram sind nötig) alles in den Flash geschrieben und gelesen, dazu braucht es ein memory management welches malloc/free etc. auf den Flash ermöglicht (hab ich für den sam in samd_flash.h gemacht). Beim Programmieren fordert allocTable() dann Speicher der jeweiligen Größe von der Platform an. Die Daten selbst kommen dann später häppchenweise über memoryWriteIndication()
• external = hier wird im memory Objekt ein Ram buffer für jedes saveRestore Objekt erzeugt mit welchem der Stack dann arbeitet, die Daten für den buffer können byteweise aus dem externen Speicher gelesen/geschrieben werden. Hier könnte man noch ansetzen und die selten/langsam benötigten Daten vom z.b. Application Table (Parameter) nicht im Ram zu buffern sondern byteweise direkt in den externen Speicher zu schreiben/lesen (hab ich aber noch nicht implementiert)

zu finden ist das Ganze in meinem Fork: https://github.com/Bernator/knx/tree/memory_rework/src
In samd_platform.cpp findet man Beispiele (meine Tests) für die Implementierung der 3 Varianten.....

Für den Samd sollte das bereits alles funktionieren, bei den anderen Plattformen hab ich versucht die "internalRam" Variante zu implementieren (wie vorher nur ohne die zusätzliche Ram Kopie in den Stack Objekten) aber das ist alles ungetestet. Hier könntest du Waldemar evtl. aushelfen und zumindest die Linux Variante mal anschaun, ich hab dazu nämlich nicht wirklich was am Start

Auch interessant wäre wie weit du beim SamD mit deiner Kanalduplizierung kommst, ich hab mit meinem Testprojekt mal grob die max Ram usage angeschaut, absolut natürlich wenig aussagekräftig aber relativ zueinander schon plausibel: (ETS Daten sind hier ca. 1,1k)

original Stack	12,8k	EEPROM_EMULATION_SIZE = 2048k
internalRam	11,7k	EEPROM_EMULATION_SIZE = 2048k
external	12,8k	EEPROM_EMULATION_SIZE = 2048k, hier werden die Daten dupliziert weil ich den externen EEPROM nur emuliere, sonst wären es 2k weniger also ca. 10,8k
internalFlash	8,3k

thesing vielleicht findest du auch die Zeit und schaust dir das mal an, evtl. hast du noch div. Anregungen

PS: mein flash memory management arbeitet von oben herab bis zur nächsten Row der text+data Adresse, bleibt somit also auch beim neu Flashen des MC erhalten wenn man nicht vorher den ganzen Flash löscht (macht das der Arduino Bootloader?) und somit muss man auch nicht immer neu programmieren über die ETS