ESP8266 KNX mit ETS

[thesing]

Danke für die Mühe.

Ich glaube nicht, dass ich die zwei Zeilen vergessen habe... Kannst du bei der Änderung an der KnxFacade mal schauen warum die ganze Datei im Pull-Request als geändert angezeigt wird? So kann ich schwer sehen, was wirklich anders ist. Bin gerade im Urlaub. Sonst würde ich selber schauen.

[mumpf]

Hi,

ich habe mir nochmal DPT9 angesehen. Mit dem ist alles OK , allerdings nicht, wenn man intern mit float arbeitet. Mit double klappt alles. Da die knxdemo auch mit float arbeitet, wird da auch immer 0 gesendet.

Für eine Korrektur muss man in knx_value.cpp:

KNXValue::KNXValue(float value)
{
[COLOR=#FF0000]   _value.doubleValue = value;
    _type = DoubleType;[/COLOR]
}

einfach das rote hinzufügen.

Edit: Habe jetzt einen Pull-Request gemacht (https://github.com/thelsing/knx/pull/27)

Gruß, Waldemar

[mumpf]

So,

nach einer Nacht-Session habe ich jetzt eine versionierbare knxprod (Fehler war trivial, aber das weiß man immer erst, nachdem man ihn gefunden hat ). Nachdem mir eingefallen ist, wie ich auch remote den Linux-Stack testen kann, habe ich es gleich versucht:

1. Wie erwartet hat die ETS gleich gemeldet, dass die Mask Version 57B0 ist, aber 07B0 erwartet wird.
2. Nachdem ich die Mask Version in bau57B0.h auf 07B0 geändert habe, konnte ich auch den Linux-Stack per IP mit meiner knxprod programmieren.

Ich bin jetzt glücklich damit, aber ich weiß nicht, ob ich durch die "falsche" Mask Version in bau57B0.h nicht irgendwelche Seiteneffekte auslöse. Kann dazu irgendjemand was sagen?

Ansonsten hätten wir jetzt einen Stack, der mit einer knxprod TP und IP unterstützt. Das finde ich ziemlich komfortabel...

Gruß, Waldemar

[mumpf]

Hi Thomas,

Mask-Version

ich habe heute den ganzen Tag Informationen zur Mask-Version gelesen, bin aber nicht viel schlauer. Verstehe ich das richtig, dass das jetzt noch die Abhängigkeit ist, die verhindert, dass ich eine knxprod für IP und TP haben kann? Denn in der knxprod muss ich ja unter Application eine MaskVersion angeben. Und da das Attribut nicht MaskVersions heißt, wird da wohl auch nur eine angegeben werden können. Und nach der Info, die ich gefunden habe, gibt die erste Stelle der MaskVersion die Kommunikation vor: 0=TP, 5=IP. Ich kann das im Urlaub nicht ausprobieren, aber ich würde jetzt erwarten, dass die ETS meckert, wenn ich meine knxprod von der TP-Linie auf die IP-Linie schiebe und das entsprechende (linux) Gerät dort versuche zu programmieren... Mist.

Könnte der Linux-Stack die MaskVersion 07B0 (statt 57B0) zurück geben und trotzdem noch korrekt funktionieren? Vielleicht nur in einer lokalen Modifikation bei mir (verletzt ja sicher die Spec)? Wie gesagt, mir sind da die Abhängigkeiten nicht wirklich klar...

Aber was solls, das ist ein Problem, dass ich sowieso erst nach meinem Urlaub weiter untersuchen kann, ich versuche erstmal weiter, meine knxprod zu versionieren und upgradebar zu machen, irgendwas mach ich da noch falsch...

Gruß, Waldemar

[thesing]

Dem Stack ist das egal. ETS fragt beim programmieren die Mask-Version vom Gerät ab und vergleicht die.

[mumpf]

Hi,

ich hab mir mal ein paar knxprod von Dummy-Geräten angeschaut, weil ich mich daran erinnert habe, dass der von mir verwendete Dummy für TP und PL verwendet werden kann. Und was soll ich sagen, der Gira-Dummy enthüllt das Geheimnis! Mit   MediumTypes="MT-0 MT-5"  bei Hardware kann man der ETS sagen, dass ein Gerät sowohl in IP- wie auch in TP-Linien sein darf. Ich kann dann auch parametrierte Geräte zwischen IP- und TP-Linien verschieben. Funktioniert auch wunderbar mit meinen knxprod Files.

Jetzt die Frage an Thomas thesing: Kann man das irgendwie mit Deinem Stack nutzen? Inwiefern ist die Applikation in dem XML (also die gesamten Parameter und KO) noch abhängig von der Linie? Mir ist natürlich klar, dass die Firmware für Linux komplett anders ist als für nen SAMD, aber kann ich beide mit der selben knxprod parametrieren oder wird das nicht funktionieren?

Gruß, Waldemar

[mumpf]

Hallo Klaus,

Doch, geht.

...aber Du darfst uns nicht verraten, wie es geht? Falls Du irgendwo eine knxprod kennst, die das macht, schaue ich auch gerne selber nach.

Gruß, Waldemar

[Klaus Gütter]

aber da die Mask-Version schon das Medium festlegt, wird man kein Applikationsprogramm für zwei Medientypen erstellen können.

Doch, geht.

[thesing]

Bernator Danke. Hab ich gemergt.

mumpf Man könnte in einer kndprod beide Applikationsprogramme rein packen, aber da die Mask-Version schon das Medium festlegt, wird man kein Applikationsprogramm für zwei Medientypen erstellen können.

[Bernator]

Ich denke ich hab das Problem mit dem neuen association table format gefixt, zumindest läufts bei mir so jetzt wieder.
Auch einen Bug bzgl. senden von extended frames hab ich im tpuart noch ausgemerzt, jetzt ist die schnellere Programmierung über die ETS auch deutlich merkbar. Mit meinem Testprojekt ist die ETS jetzt in 10 Sekunden fertig, vorher waren es ca. 15 Sekunden.

[mumpf]

Hi,

weiß jemand, ob es möglich ist, eine knxprod für TP und IP zu erstellen? Also eine für beide Medientypen? Das würde Tests und Versionierung stark vereinfachen, wenn man für beide Medientypen entwickelt...

Dass es die ETS grundsätzlich kann, sieht man am GIRA Dummy, aber da eben mit anderer Mask-Version, sonst hätte ich da schon abgeguckt .

Gruß, Waldemar

[Bernator]

Ich habe die Anzahl der Einträge für AT und GAT im CreateKnxProd auf ushort.MaxValue erhöht und die GAT auf das größere Format umgestellt. Evtl. muss man im AssociationTable::nextAsap und AssociationTable::translateAsap noch operator[](i + 1) mit operator[](i) und umgekehrt tauschen. Ich habe leider heute keine Zeit mehr das zu testen/zu debuggen. Den entsprechenden Verweis auf die Spezifikation hab ich ins commit-Kommentar geschrieben. Ich komme vor Sonntag Abend oder Montag Abend nicht zu mehr.

da scheint es tatsächlich noch ein Problem zu geben... in translateAsap läuft die Schleife bis "entries * 2" und in nextAsap nur bis "entries", der operator[] liefert aber bei ">= entryCount()" immer 0

[mumpf]

Hi Bernator,

danke für das Feedback. Ich mache gerne weitere Tests, ich wollte auch mal die millis() ausgeben, damit man sieht, wie häufig die Meldungen kommen, einige kommen nämlich am Block, dann aber wieder ne Pausen usw. Ich übertrage eben ca. 7k über den Bus beim programmieren, das dauert auch knapp 2 Minuten. Über diese Zeit verteilen sich die Meldungen. Ich hatte schon die EEPROM-Emulation im Verdacht, dass diese zwischendurch mal Seiten weg schreibt und dafür zu lange braucht, aber dann bräuchte man nicht alles im RAM spiegeln...

Langer Rede kurzer Sinn: Wegen Urlaub komme ich erst Ende August wieder an meine Hardware und kann erst dann wieder testen.

Gruß, Waldemar

[Bernator]

das #ifdef für NCN5120 wird nur beim Beenden des Stacks schlagend, hat also hier keinen Einfluss...
Wenn nur die Schleife durchläuft ist das sicher auch kein Problem und die Ursache muss woanders liegen, hast du mal den Demo Sketch versucht, nur um sicher zu gehen?

Bzgl Speicher ist es glaube ich so das die Parameter, GAs, Associations sogar 3x vorkommen, 1x Flash, 1x RAM EEPROM Emulation, 1x RAM Stack, aber das kann Thomas bestimmt besser beantworten.

[mumpf]

Hi,

ich habe noch eine Frage, die aus meinen gestrigen Tests resultiert. Ich habe es bei meinem Logikmodul auf 50 Kanäle gebracht, 60 klappen nicht mehr, es bricht entweder beim Programmieren ab oder nach den Restart werden keine GA gesendet. Dazu musste ich sowohl in memory.cpp wie auch in FlashAsEPROM die Speichergröße auf 6k setzen (6144 Bytes). Sprich, ich habe Speicherprobleme. Allerdings kann ich mir das nicht wirklich erklären...

Rein rechnerisch verbrauche ich pro Kanal:

• 110 Byte für Parameter
• 33 Byte zur Laufzeit
• 3 KO (4 Byte, 4 Byte und 14 Byte = 22 Byte)

Unabhängig von den Kanälen habe ich

• 12 Byte für Parameter
• 20 Byte zur Laufzeit
• 1 KO (1 Byte)

Wenn ich (110+33+22)*50+12+20+1 zusammen rechne, komme ich auf 8283 Byte. Selbst mit dem gespiegeltem EPROM im Ram sind das dann 8283+6144 = 14427 Bytes. Dazu kommt dann noch der Speicher für die GA, die den KO zugeordnet werden können, nehmen wir mal an das sind 256*4 Bytes = 1024 Bytes, also ein weiteres KB. Dann komme ich auf 15451 Bytes, das ist noch nicht mal die Hälfte des verfügbaren Ram. Hab ich da was übersehen oder wird der Rest von KNX-Stack verbraucht?

Ich kann zwar mit 50 Kanälen leben, aber es ist eher die untere Grenze von dem, was ich erreichen wollte, mein Traum sind ja immer noch 80.
SebastianObi : Du hattest ja auch schon Speicherprobleme, hast Du da Erkenntnisse, wie mal da besser werden kann?

Gruß, Waldemar