ESP8266 KNX mit ETS

[IOException]

Hi Bernator,

versuch die entsprechende Stelle mal so umzubauen:

//check if echo
_isEcho = false;
if(_sendBuffer != NULL)
{
if (!((buffer[0] ^ _sendBuffer[0]) & ~0x20) && !memcmp(buffer + _convert + 1, _sendBuffer + 1, 5)) //ignore repeated bit of control byte
{
_isEcho = true;
}
}

Ja cool ich hatte parallel auch mit folgendem den Absturz beheben können:

//check if echo
if (_sendBuffer && !((buffer[0] ^ _sendBuffer[0]) & ~0x20) && !memcmp(buffer + _convert + 1, _sendBuffer + 1, 5))
{ //ignore repeated bit of control byte
    _isEcho = true;
}
else
{
    _isEcho = false;
}

Damit konnte ich jetzt auch die physikalische Addresse programmieren und parametrieren.

SEHR gut! Ich freue mich dass das nun funktioniert :-D
Einfach genial!!

Ich kann gerne meine Änderungen teilen, damit der ESP32 auch mit dem KNX-TP funktioniert.

Greets und vielen Dank für die Hilfe!
Patrick

[Bernator]

Hallo Thomas,

ich bin nicht sicher ob ich dich richtig verstehe, aber wenn Save() weiter so funktionieren soll wie bisher ist eine Flash only Variante nicht möglich da vom Interface immer Speicher im Ram alloziert werden muss welcher dann erst später über Save() in den von der Memory Klasse allozierten Speicher kopiert wird. Restore() funktioniert eigentlich wie vorher nur das eben kein Speicher alloziert wird sonder nur ein Pointer auf die bereits vorhandenen Daten übergeben wird.

Ja das mit den Platformspezifischen Speichermodi wollte ich anfangs so machen, bin dann aber irgendwo auf auf ein Problem gestoßen (hatte auch was mit der direkten Flash Nutzung zu tun) und habs dann dem Stack bekannt gegeben. Das war aber zu einem Zeitpunkt wo ich noch nicht alles so ganz durchschaut hatte, hier könnte man tatsächlich nochmal drüber nachdenken, wär auf jeden Falls eleganter.....

MemoryId könnte man auch den Index des SaveRestores nehmen aber 1,2,3.... als eindeutige ID ist nicht sonderlich originell und wenn die App selbst auch noch Flash Speicher anfordert bekommt man evtl.schnell Probleme?

[mumpf]

Hi,

Super dass du hier so aktiv Fragen beantwortest.

danke für die Blumen, aber wenn ich schon nichts beim Coding beitragen kann, kann ich wenigstens bei den einfachen Fragen helfen. Nachdem ich die Änderungen von Bernator gesehen habe, ist mir klar geworden, dass mein "löblicher" Ansatz für die Speicherverwaltung nicht mehr war als eine Idee, die ich nicht hätte realisieren können.

@Bernator: Könnte man für die MemoryId nicht ne Kombi machen? 2 Byte programmierter Präfix und das 3. Byte den Index? So was wie 0xAE5Ann, wobei nn der Index ist?

Und zum Thema Save: Ich würde davon ausgehen, dass hier jeder bereit ist, noch was an seiner Firmware zu ändern (falls man es schon genutzt hat, ich mach es z.B. im externen EEPROM), wenn man dadurch nennenswert mehr RAM zur Verfügung hat. Ich will nur sagen, ich fände es schade, falls diese Erweiterung nicht in den Stack kommt, nur weil man ein api stabil halten will. Ist nur meine Meinung, ich kann nicht behaupten, dass ich das Ganze schon durchblicke.

Gruß, Waldemar

[mumpf]

Hi Patrick ( IOException ),

freut mich, dass es auch jemanden gibt, der den ESP32 mit KNX-TP angeht. Bleib mal ruhig dabei, ich hab hier auch noch 3xESP32 rumliegen, vielleicht kann ich Deine Erfahrung nochmal gebrauchen...

Aber um Deine Frage zu beantworten:
Ich nutze derzeit das Sensormodul von Masifi, das er in dem Thread https://knx-user-forum.de/forum/proj...-sensoreinsatz vorstellt. Das ist eben fertig mit KNX Transceiver und hat auch noch ein externes EEPROM mit drauf. Außerdem passen da Standardsensoren mit I2C bus drauf, da muss ich nicht noch löten .

Am Anfang hatte ich noch ein einfaches Devel-Board aus China, da steht "Wemos SAMD21 MINI" drauf, das geht auch, aber es gibt sehr wenig Doku zu dem Board.

Gruß, Waldemar

[IOException]

freut mich, dass es auch jemanden gibt, der den ESP32 mit KNX-TP angeht. Bleib mal ruhig dabei, ich hab hier auch noch 3xESP32 rumliegen, vielleicht kann ich Deine Erfahrung nochmal gebrauchen...

Ja sehr gerne, das werde ich hier zu Hause sicherlich jetzt verstärkt einsetzen und nutzen...

Ich nutze derzeit das Sensormodul von Masifi,
[...]
Am Anfang hatte ich noch ein einfaches Devel-Board aus China, da steht "Wemos SAMD21 MINI" drauf

Cool dann werde ich das auch mal testen danke nochmal!
Patrick

[mumpf]

Hi Bernator,

kurzes Feedback zum "rudimentären" Speichertest:

Alter Stand:
Sensormodul (Temp/Hum/Co2 mit passenden Libs ) und 40 Logikkanäle problemlos möglich. 50 Kanäle gingen nicht mehr, dazwischen hab ich es nicht probiert.

Neuer Stand:
Gleiches Sensormodul, jetzt mit 60 Logikkanälen problemlos möglich. 80 Kanäle gingen nicht mehr, dazwischen hab ich es noch nicht probiert. Da aber 80 Kanäle auch über 255 KO gehen, könnte es noch einen Bug in meiner Firmware geben, dass es nicht funktioniert - zumindest bin ich mir da nicht sicher. Für die RAM-Nutzung gibt PlatformIO grob 8,6k an, ich hätte erwartet, dass das noch geht.

Die Symptome sind auch unterschiedlich: Im alten Fall brach es bei zu vielen Kanälen bei der Programmierung ab, im neuen Fall hängt es beim bzw. vor dem ersten Senden eines KO, vorher sehe ich noch Debug-Ausgaben...

Ich teste mal weiter und berichte dann, bin diese Woche allerdings in der Reha, das wird alles etwas "gemächlicher" gehen.

Gruß, Waldemar

[Bernator]

So hab nochmal etwas umgebaut um die ganzen Speichervarianten Platformspezifisch zu machen, sprich die Abstraktion findet ausschließlich in der Platform statt, der Stack selbst bleibt somit unabhängig vom verwendeten Speichertyp.
Damit das funktioniert müssen in der jeweiligen Plattform einige Methoden implementiert werden, welche das sind und was die leisten sollen hab ich in platform.h dokumentiert.
In samd_platform.cpp sind Beispielimplementierungen für die 3 zuvor genannten Speichertypen.

thesing ich denke das ist so jetzt eine recht saubere Sache, bitte schaus dir mal an....Danke

[Bernator]

mumpf es wäre toll wenn du mal testen könntest ob das Demo Projekt in der Linux und ESP Platform noch läuft...

[mumpf]

Hi,

bin letzte Woche zur Reha gewesen, deswegen ist da nicht viel passiert. Ich hoffe, ich komme dieses WE dazu, sonst wird es leider erst kommendes WE was werden (die Woche über habe ich immer noch Reha).

Ich mach das gerne, wollte auch Deinen aktuellen Umbau (also neueste Verison) auf dem SAMD noch testen, aber ich komme da leider nicht sehr schnell voran...

Gruß, Waldemar

[mumpf]

Hi Bernator,

kurzes Feedback: Ich habe heute Deinen neuen Stack mit meinem Logikmodul unter Linux laufen lassen (für das demo-projekt muss ich noch was anpassen, das mach ich dann morgen).

Es compiliert, lässt sich starten, aber der Programmiermodus geht nicht, obwohl "progmode on" in der console erscheint. Ich der ETS sehe ich das Ding nicht unter "Geräte im Programmiermodus".

Ich untersuch das morgen weiter, heute geht es ins Bett,
Gute Nacht, Waldemar

[Bernator]

Hallo,

danke fürs Feedback, leider hab ich aktuell keine Idee woran das liegen könnte. Die Änderungen beziehen sich eigentlich alle nur auf das memory handling, in wieweit das mit dem progmode zusammenhängt kann ich nicht sagen. Im fatalError() landet er aber nicht?

[mumpf]

Hi,

er landet nicht im fatalError()... Aber das oben war eher als Status gedacht, nach dem Motto "Ich hab schon was gemacht, aber noch keinen Erfolg gehabt" und nicht als Aufforderung, Lösungsideen zu liefern... Es war dann einfach spät und ich hab mittendrin aufgehört. Auf dem SAMD hatte das ja auch geklappt, einfach Deinen Stack zu nehmen und alles andere lief weiter. Und unter Linux kann ich auch debuggen, dann kann ich hoffentlich auch die Problemstellen (falls es welche gibt) genauer einkreisen.

Ich werde das jetzt systematisch angehen, die knx-demo erstmal mit Thomas Stack zum laufen bringen, dann nur den Stack austauschen und dann sehen wir weiter. Noch ist gar nicht gesagt, dass es an Dir liegt, kann auch durchaus meine Umgebung sein.

Aber man unabhängig von dem Linux-Problem: Kannst Du mir mal demnächst schreiben, wo Du über #define irgendwelche Speicher-Maximalwerte festlegst?
Ich habe bisher folgendes gesehen:

#define MAX_MEMORY_BLOCKS   6   in linux_platform.h
#define MAX_MEM 4096            in linux_platform.cpp
#define FLASHSIZE 0x10000       in linux_platform.cpp

Ich gehe mal davon aus, dass ich MAX_MEM dann für mein Logikmodul anpassen muss (bei Thomas musste ich den alloc auf 8192 setzen), würde ich dann auch machen - die Frage ist, ob ich irgendwo was übersehen habe. Und ob es eventuell beim SAMD auch noch ein MAX...-Limit gibt, dass ich noch nicht gefunden habe. Wie gesagt, ich bin ein bisschen verwundert, dass ich auf dem SAMD nur von 40 auf 60 Logikkanäle komme (wobei das natürlich auch schon ein Riesenerfolg ist) und hoffe ein bisschen, dass man noch an irgendwelchen Stellschrauben drehen kann .

Werde weiter berichten,
Gruß, Waldemar

[Hauswart]

In Kombination mit der ETS Inside gibt keine Möglichkeit, da ich knxprod nicht importieren kann - oder?

[thesing]

Hauswart : Vielleicht geht es, wenn du das Projekt in ETS von der Inside importierst, dort die knxprod hinzu fügst und dann wieder zum Inside-Server zurück synchronisierst. Ich habe das allerdings nie probiert, da ich keine Inside hab.

[Bernator]

Alles gut ich habs nicht als Aufforderung verstanden
In der reinen Flash Variante muss man keine Limits setzen, hier liefert der Flash Treiber so lange neu Speicherblöcke der entsprechenden Größe, von oben herab, bis der neu angeforderte Block mit dem text + data segment des Flash kollidieren würde, wenn das passiert landet man im fatalError().

Bei der Variante mit dem emulierten EEPROM muss man in der FlasStorage lib wie vorher auch definieren wieviel Flasch Speicher als EEPROM emuliert werden soll.
#define MAX_MEMORY_BLOCKS 6 in linux_platform.h Muss nicht geändert werden, das definiert für die mini Speicherverwaltung (der extern und emulierten EEPROM Variante) nur wieviel unterschiedliche Interface Objekte maximal gespeichert werden können (Device, Group, Assoc, Application, IPParameter, Facade)
#define MAX_MEM 4096 in linux_platform.cpp #define FLASHSIZE 0x10000 in linux_platform.cpp Kommt nicht von mir, ich vermute das definiert die größe des emulierten EEPROMs in der Linux Platform