ESP8266 KNX mit ETS

[Bernator]

Gute Besserung, wir kämpfen auch

Nein mir sind keine Unterschiede diesbezüglich zwischen tpuart und ncn bekannt.
Man hat 17bit Zeit nachdem der Addresstype an den Host gesendet wurde, bei den 9600baud sind das ca. 1,7ms, aber Achtung die Zeit beginnt logischerweise zu laufen sobald das Byte durch den Interrupt im Arduino rx buffer landent und nicht erst wenn das Byte dann tatächlich vom Stack an o.g. Stelle ausgewertet wird.

ack.JPG

Alternativ kann man im tpuart oder ncn mit U_SetAddress die physikalische Adresse bekannt geben und damit die auto-ack Funktion aktivieren, dann sendet der Chip automatisch ein ACK bei allen Gruppenadressen (auch jene die im Device gar nicht vorkommen) und wenn die Zieladresse die eigene physikalische ist.

[thesing]

Bei mir sind zuhause alle krank. Daher nur kurz:
- der aktuelle git-Stand funktioniert unter Linux. Daher sollte das Problem bei den anderen Platformen nicht allzu groß sein.
- Das ACK gibt es nur bei Knx-TP. Bei Knx-IP nicht. Das sollte dein TP<->IP-Router schicken.
- Der TPUART kann das ACK nur bei direkt adressierter Kommunikation senden. Bei Gruppenkommunikation nicht, da er dann die Gruppen-Adressen-Tabelle kennen müsste. Das Ack sollte hier https://github.com/thelsing/knx/blob...layer.cpp#L257 gemacht werden.
- welches SAMD21 Board es genau ist spielt keine Rolle. Ich hab ein "WeMos D1 SAMD21 M0 Mini" von ebay.

VG
Thomas

[mumpf]

Hi Bernhard,

Ich könnte mir vorstellen das es ein timing Problem gibt und der Stack nicht schnell genug aufgerufen wird und somit das Zeitfenster für den Ack_Req verpasst...

ich schau auf jeden Fall mal nach, ich hatte mir zwar eingebildet, dass ich im Callback nichts lang laufendes mache, aber der Teufel steckt wie immer im Detail, ich mach mal ein paar Zeitausgaben. Jetzt wo ich die Stelle weiß, kann ich es besser analysieren.

Aber der Vollständigkeit halber: Ich verwende den NCN5130, ich habe gesehen, Du hast ein #define für den NCN5120, wodurch ich vermute, dass Du das für den NCN5120 implementiert hast. Siehst (oder kennst) Du irgendwelche Unterschiede zwischen den beiden, die hier eine Rolle spielen könnten?

Im NCN5130 Datasheet habe ich was gesehen, dass nach einem Frame wohl 2.6ms Pause gemacht werden und in der Zeit der IACK kommen muss. Ich bin mir aber nicht sicher, ob ich das richtig interpretiert habe. Ist das die Zeit, die Du meinst, die maximal vergehen darf?

Danke nochmal für die Info, ich werde berichten, was ich rausgefunden habe!

Gruß, Waldemar

[wkaa]

arbeitest Du an der seriellen Kommunikation für Linux?

Hi Thomas,

ja, aber das kann länger dauern, Wochen oder Monate. Auch wenn es nicht so ein großes Thema ist, aber ich nutze es auch um den Code zu verstehen und habe leider immer nur kurz Zeit.

Gruß
Werner

[blaubaer]

Hallo,
bei dem "SAMD21" handelt es sich da um den Arduino Zero und Arduino MKR? Oder welche Boards sind damit gemeint.
Gruß
Thomas

[blaubaer]

ich fange jetzt mit der RS232 Kommunkation unter Linux an

Hallo,

arbeitest Du an der seriellen Kommunikation für Linux? Wird es da bald eine Lösung geben? Ich wäre sehr daran interessiert.

Gruß
THomas

[Bernator]

Das Ack sendet der tpuart selbstständig zum richtigen Zeitpunkt, dazu muss aber vom Host (der SamD) ein Ack_Req im richtigen Zeitfenster kommen, das passiert hier nachdem geprüft wurde ob die GA überhaupt vorhanden ist im Device.
Was der tpuart mach wenn der Ack_Req zu spät oder gar nicht kommt weiß ich grad nicht, vermutlich macht er nix und das Telegramm bekommt somit kein Ack.

Ich könnte mir vorstellen das es ein timing Problem gibt und der Stack nicht schnell genug aufgerufen wird und somit das Zeitfenster für den Ack_Req verpasst...

[mumpf]

Hi,

wer (welche Stelle) macht eigentlich im Stack das ACK für die Gruppenkommunikation?

Folgende Situation: Ich habe eine GA an einem Eingangs-KO (also S-Flag gesetzt), wenn ich auf diese GA eine 1 schicke (per ETS oder von einem anderen KNX-Device ist egal), wird mein Callback für dieses KO 4 mal aufgerufen und im Busmonitor sehe ich 4 Wiederholungen. Wenn ich diese GA auch noch mit einem anderen Eingang eines gekauften KNX-Devices verbinde, gibt es ein ACK (im Busmonitor steht da LL_ACK) und es gibt keine Wiederholungen.

Für mich sieht das so aus, als ob das Modul kein ACK sendet und ich wollte wissen, wo ich reindebuggen muss, um das zu prüfen...

• Passiert das generisch im Stack?
• Oder in der tpuart-Implementierung?
• Oder gar durch die tpuart-Hardware? Dann würde bei mir irgendeine Einstellung fehlen...

Ist übrigens ein Problem bei einem Bekannten, bei mir zu Hause ist es bisher nicht aufgefallen, weil ich (wegen meiner Visu) den Linienkoppler auf "Alle Telegramme auf der Hauptlinie bestätigen" stehen habe. Ich werde - sobald ich wieder zu Hause bin - versuchen, das Problem zu reproduzieren, wollte mir vorher aber das Coding anschauen... Ich habe auch schon im Coding gesucht, aber es sind so viele Methoden mit "ack" in der Signatur, dass ich den Wald vor lauter Bäumen nicht sehe...

Bin für jeden Tipp dankbar,
Gruß, Waldemar

[demacus]

Hallo zusammen und gesundes Neues!

Keine Platform lässt sich mit dem aktuellen Stand per ETS programmieren, der Controller Antwortet nicht auf "DeviceDescriptorRead".

Der letzte Funktionierende Stand ist für mich Commit 4ef513410a7122d6892c3aa963e82d2abbbdeaf3

Da ihr gerade beim Thema seid dachte ich ich erwähne das Mal, eventuell hat ja jemand eine Idee was ich tun muss damit der aktuelle Stand läuft.


Edit: getestet habe ich auf mit ESP8266 (Wemos D1) sowie SAMD21 (generisches Breakout)

[Bernator]

Alles klar Zeit hab ich auch immer zu wenig
Problem ist die Meldung wie oben erwähnt und das er dort nicht weiter macht wenn es nicht zusammen passt, aber ich hab die Dinge im DeviceObject jetzt gefunden, werde das dann nochmal testen. Vielleicht kommst du mal dazu das im Demo Projekt zu ergänzen, aktuell fehlt das dort ja auch noch und somit muss eine ETS Programmierung auch dort scheitern.

[mumpf]

Hi Bernhard,

neee, ich hab schon lange nicht mehr aktualisiert. Ich will erstmal das, was ich hier mache, halbwegs produktiv bekommen, mit Deiner Flash-Optimierung und meiner RAM-Optimierung (kleinere KO). Ich bekomme irgendwann meine 20 Sensormodule und will dann die Firmware dafür fertig haben.

Ich versuch mich zur Zeit mit ner sauberen BME680 implementierung, die aber mein Logikmodul nicht blockieren darf, dann will ich noch den SAVE-Interrupt vom NCN5130 nutzen (beim Stromausfall alle Werte ins EEPROM sichern) und dann noch einige sporadische Hänger vom I2C-Bus ausbügeln, das dauert alles viel länger als ich gedacht hatte und die Testintervalle sind auch recht lang - es sind eben sporadische Fehler zu entdecken und auszubügeln.

Deswegen bin ich auch nicht auf die aktuellste Version gegangen, dann müsste ich auch nochmal all die Sachen testen, die ich bei Deiner Flash-Optimierung getestet habe - dazu hab ich derzeit keinen Nerv...

Das heißt nicht, dass ich das nicht machen werde - ich will vorher nur all die anderen Bugs und Unschönheiten weg haben, bevor ich den Stack austausche. Sonst frage ich mich immer wieder, ob der Fehler jetzt durch den neuen Stack oder durch mein Coding passiert ist.

Da ich jetzt wieder fulltime arbeite, hab ich auch nicht mehr so viel Zeit, hieran zu arbeiten, insofern wird es noch 2-3 Monate dauern, bis ich mich wieder dem Stack widmen kann. So ist zumindest der Plan...

Gruß, Waldemar

[thesing]

Die erste KO ist bei System B die 1. Bei System 7 ist es die 0. Die ManufacturerId, Version und Hardwaretype kann man am DeviceObject einstellen. Es kann sein, dass die entsprechenden Properties an der KnxFacade noch fehlen. Diese Zahlen ersetzen die Magic Numbers am Start des Flashs. Dadurch kann man sicher stellen, dass nur Daten aus dem Flash gelesen werden, wenn der Sketch auch dazu passt. Der aktuelle Stand im git funktioniert zumindest unter Linux. Auf den MCUs teste ich nicht all zu oft. Was ist denn das Problem?

VG
Thomas

[Bernator]

Danke, läuft bei dir der aktuelle git Stand?

[mumpf]

Hi Bernhard,

irgendwo in den Thread stand das schon mal: Erstes KO ist die 1. Den Grund weiß ich nicht mehr. Ich mach es einfach...

Gruß, Waldemar

[Bernator]

Noch etwas ist mir aufgefallen, in den Beispiel xml files beginnt das erste KO bei

Number="1"

in kommerziellen knxprod files beginnt es mit

Number="0"

Wenn ich ein knxprod file mit 0er KO erstelle, hängt der MC sobald er auf diesem KO was empfängt...
getGroupObject(x) macht auch irgendwann ein (x-1) also geht dein Stack aktuell davon aus das die KOs mit 1 beginnen?