ESP8266 KNX mit ETS

[SebastianObi]

Das klingt stark nach nicht initialisierten Speicher. Ich habe jetzt hinzugefügt, dass die Daten vom GroupObject mit 0 initialisiert werden. Kannst du bitte testen ob damit der Problem behoben ist?

Hallo,

danke. Dies hat das Problem mit DPT 1 gelöst.

Jetzt habe ich nur noch ein anderes Phänomen. Sobald ich mehr Parameter und Gruppenadressen verwendet bekomme ich des öfteren die Fehlermeldung "Adress is not valid 5294967289". Obwohl die Produktdatenbank und das C++ Programm 100% tig schon mal funktioniert hatte. Dann habe ich es einen Tag später probiert und dann ging es plötzlich ohne Fehler. Jetzt hänge ich wieder da, wo es reproduzierbar nicht mehr funktioniert. Wie kann ich dies weiter analysieren? Im Anhang habe ich mal die Daten vom ETS Monitor angehängt.

VG Sebastian

[henfri]

Hallo,

ja genau, davon spreche ich doch. Was dachtest du denn, wovon ich sprach?
thesing sprach oben, dass mittlerweile alles auf Github veröffentlicht ist und ich meine, ich hätte kürzlich auch alles von der Github Seite geladen und erfolgreich kompiliert

Gruß,
Hendrik

[thesing]

Ich habe eine Idee woran es liegen könnte. Du kannst als Workaround Die beiden Zeilen

    if (_memoryReference == 0)
        _memoryReference = address;

in uint8_t* Platform::allocMemory(size_t size) auskommentieren.

Ich muss mir mal überlegen wie ich das grundlegende Problem richtig löse.

[SebastianObi]

Funktioniert bei mir nicht, wenn ich dies auskommentiere kommt die Fehlermeldung noch früher.

[thesing]

Dann probier doch mal die Zeile auf:

    if (_memoryReference == 0 || address < _memoryReference)
        _memoryReference = address;

zu ändern.

[jorues]

Dann probier doch mal die Zeile auf:

if (_memoryReference == 0 || address < _memoryReference)
_memoryReference = address;

zu ändern.

Damit lässt sich bei mir der Sketch aus der ETS heraus programmieren. Allerdings sind die gesendeten Werte vom Sketch (bme680) alle "0".

Grüße und besten Dank für die Unterstützung

[thesing]

Ich habe mal eine (ungetestete) Änderung committed. Vielleicht geht es damit.

[henfri]

Sorry, hab den Faden verloren.
Was fixt das?

[Bernator]

Hallo,

was mich ein wenig stört ist die Tatsache das knx.loop() teilweise doch recht lange blockiert, so wie ich das sehe liegt es hauptsächlich an 2 Punkten:

1. der tpuart Treiber pollt die serielle Schnittstelle solange bis ein komplettes Frame empfangen wurde
2. beim senden eines Telegrammes wird der eigentlich asynchrone Vorgang (send, confirm) im data_link_layer synchronisiert, d.h. der stack wartet bis das telegramm gesendet und wieder empfangen (confirm) wurde.

Stimmt das oder übersehe ich etwas?

[SebastianObi]

Ich habe mal eine (ungetestete) Änderung committed. Vielleicht geht es damit.

Hallo,

damit ist der "Adress is not valid" Fehler behoben. Sonst scheint auch alles weitere zu funktionieren.

Jetzt habe ich nur noch eine Anforderung/Problem.
Was ist die maximale Anzahl an Gruppenadressen und Parameter/Bytes?
Ich programmiere gerade ein Enocean & 433MHz Gateway und verwende dort sehr viele Parameter und Gruppenadressen auch als Reserve/Optionen. Welche so auch nicht alle parallel je nach Konfiguration verwendet werden. 804 Gruppenadressen und 1108 Bytes Parameter. Ja ich weis, das ist extrem viel Am Ende des Applikations-Übertragungsprozesses bleibt der Microcontroller hängen/friert ein. Vermutlich gibt es hier irgendwo einen Variablenüberlauf oder Speicher kann nicht adressiert werden. Ich habe in der FlashStorage-Library eigentlich genügend Speicher reserviert.

[mumpf]

Hi,

ich habe mal einen Testlauf mit 240 KO (was in der Software Gruppenadresse heißt) und 9120 Bytes Parameter versucht, allerdings nur in der Linux-Implementation und nur als Machbarkeitsstudie, sprich: Ob man es prinzipiell programmieren kann. Da gab es keinen Hänger, ich muss es aber mit dem aktuellen Stand erneut probieren.
Bin derzeit am Debuggen von 3 KO und 114 Bytes Parameter und will das später um Faktor 80 erhöhen...

Wie gesagt, ich hab noch keine negativeffekte gefunden, aber ich habe es auch noch nicht auf die Zielplattform, den SAMD, gebracht.

Gruß, Waldemar

P.S.: In der ETS gibt es bei mir 80*27 = 2160 KO, aber es sind max. 240 davon sichtbar und somit für die Laufzeit relevant.

[thesing]

SebastianObi Es gibt keine fest einprogrammierte Begrenzung. Ich fürchte dein Problem wirst du nur mit zusätzlichen Debugausgaben finden können. Dazu kannst du die print* Funktionen aus bits.h nutzen. Die werden auf die entsprechende serielle Schnittstelle umgebogen. Lesen und schreiben vom Flash findet in memory.cpp statt. Ich seh gerade, dass bei void Memory::readMemory() nur 512 Byte vom Flash gelesen werden. Vielleicht hilft es dir schon wenn man die Zahl erhöht. Wahrscheinlich wäre es besser gar keine feste Anzahl zu lesen und statt dessen am Anfang die Zahl der gespeicherten Bytes im Flash abzulegen.

Bernator 1 stimmt soweit. 2 nur in so fern, dass auf das darauf gewartet wird, bis das Paket versendet wurde. Beides kann man sicherlich besser machen. Falls du dich daran versuchen möchtest muss du nur ein eigenes Datalinklayer schreiben und in Bau07B0 nutzen. Dabei bitte darauf achten, dass selbst versendete Frames nicht auch als solche erkannt werden wenn sie wieder empfangen werden. (Es wir ein Fehlerflag gesetzt, wenn der Stack ein Paket verarbeitet, welches die eigene Geräteadresse hat. Das kann ETS abfragen. Das wird wahrscheinlich im Rahmen einer Fehlerdiagnose oder Installationsdiagnose gemacht. ) Patches welcome

Wenn man eine USB-Schnittstelle unter Linux nutzen wollen würde, kann man ähnlich vorgehen. Dabei müsste man wahrscheinlich du die Bytes vom CemiFrame direkt ins /dev/ttyUSBX oder so schreiben bzw. lesen.

[Bernator]

Bist du sicher? Ich verstehe das so das sendFrame ja per Schleife darauf wartet bis _sendBuffer=0 wird und das passiert ja erst im receive Teile wenn das Echo +L_Data.con empfangen wurde:

if (len == _sendBufferLength && memcmp(_sendBuffer, buffer, len) == 0)
        {
            //we got the send telegramm back next byte is L_Data.con byte
            uint8_t confirm = _platform.readUart();
            confirm &= L_DATA_CON_MASK;
            _sendResult = (confirm > 0);
            _sendBuffer = 0;
            _sendBufferLength = 0;

            return true;
        }

btw. ist "_platform.readUart()" hier nicht potentiell gefährlich da es -1 returned wenn L_Data.con noch nicht im rx buffer des Arduino angekommen ist?

Dabei bitte darauf achten, dass selbst versendete Frames nicht auch als solche erkannt werden wenn sie wieder empfangen werden. (Es wir ein Fehlerflag gesetzt, wenn der Stack ein Paket verarbeitet, welches die eigene Geräteadresse hat.

Da kann ich dir nicht ganz folgen, eigene Frames sollen nicht erkannt werden?

Falls du dich daran versuchen möchtest muss du nur ein eigenes Datalinklayer schreiben

vielleicht mach ich das

[henfri]

Wenn ich sehe was ihr hier vor habt dann bin ich optimistisch, dass bald die Kommunikation über TCP implementiert werden wird...
:-)
Habt ihr da bessere Erfahrungen gemacht als ich?
Auch im Zusammenhang der knx Implementation für tasmota wird ja auch immer wieder über verlorene Telegramme berichtet. (Auch ESP)

Gruß,
Hendrik

[thesing]

Bernator Ich habe nochmal in die Doku vom NCN geschaut. Du hast recht. Es wird effektiv auf das Ack gewartet. Ggf. ist die Stelle eh falsch, da nach dem Frame erst U_FRAMESTATE_IND kommt. Ich meinte, dass die selbst versendeten Frames erkannt werden müssen und nicht an DataLinkLayer::frameRecieved übergeben werden dürfen. Frames die jemand anderes mit der gleichen Geräteadresse wie man selbst hat empfängt, sollen aber weiter gegeben werden. Man kann also nicht einfach auf die Quelladresse des Frames prüfen.

henfri TCP-Kommunikation gibt es nur beim Programmieren von Geräten und beim Tunnelling. Bei TCP müsste das Gerät die IP-Adresse und Port einer IP-Schnittstelle kennen. Die könnte man natürlich als Parameter in ETS einstellen, aber das wäre dann eine Gerät das mit anderen KNX-Geräten reden kann, aber kein KNX-Gerät. Ich würde eher diese zuverlässige Kommunikation von Gira implementieren. Wenn man dann noch ein RoutingNetworkLayer baut, kann man mit einem ESP oder einem Raspberry-Pi einen Router bauen. Dazu bräuchte ich aber einen Wireshark-Mitschnitt damit ich mir anschauen kann wie das genau funktioniert.

VG
Thomas