Ankündigung

Einklappen
Keine Ankündigung bisher.

ESP8266 KNX mit ETS

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • thesing
    antwortet
    Da kann ich leider nicht helfen. Ich benutze eine MicroBCU von https://knx-user-forum.de/forum/proj...nx-transceiver

    VG
    Thomas

    Einen Kommentar schreiben:


  • DanS
    antwortet
    Hallo thesing,

    zum letzten GIT Stand, das auskommentieren des "#define USE_TP" führt bei verwendung des "knx-demo" Projektes unter Arduino zur fehlermeldung, wenn man z.B. einen SAMD21 mit TP-Uart beteriben möchte ;-)

    Ohne die Änderungen in der "tp_uart_link_layer.cpp" erhalte ich folgende Konsolen ausgabe in zusammenspiel mit der Siemens BCU
    Code:
    readMemory<\r><\n>
    RESTORED FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF <\r><\n>
    saved memory doesn't match manufacturerId, version or hardwaretype<\r><\n>
    manufacturerId: FFFF FA<\r><\n>
    version: FFFF 3<\r><\n>
    hardwareType: FF FF FF FF FF FF <\r><\n>
    00 00 00 00 00 00 <\r><\n>
    ownaddr 0<\r><\n>
    progmode on<\r><\n>
    progmode off<\r><\n>
    progmode on<\r><\n>
    expected L_DATA_CON not received<\r><\n>
    got L_ACKN_IND<\r><\n>
    got L_ACKN_IND<\r><\n>
    got L_ACKN_IND<\r><\n>
    got L_ACKN_IND<\r><\n>
    got UNEXPECTED: 0xE1<\r><\n>
    got U_CONFIGURE_IND: 0x1<\r><\n>
    got L_ACKN_IND<\r><\n>
    got U_STATE_IND: 0xCF<\r><\n>
    got unexpected L_DATA_CON<\r><\n>
    expected L_DATA_CON not received<\r><\n>
    got L_ACKN_IND<\r><\n>
    got L_ACKN_IND<\r><\n>
    got L_ACKN_IND<\r><\n>
    got L_ACKN_IND<\r><\n>
    got UNEXPECTED: 0xE1<\r><\n>
    got U_CONFIGURE_IND: 0x1<\r><\n>
    got L_ACKN_IND<\r><\n>
    got U_STATE_IND: 0xCF<\r><\n>
    got unexpected L_DATA_CON<\r>
    Elektrisch habe ich keine Probleme mehr, nutze jetzt ein 4081 (AND-gate) als Levelshifter 3.3V auf 5V, 5V auf 3,3V mit Widerstandsteiler.
    Signale habe ich mittlerweile mit meinem Oszi verifiziert.
    Vih/Vil Pegel auf beiden Seiten werden erreicht.
    Delay rise 195ns
    Delay fall 139ns
    Also mehr als ausreichend für 19,5 kBaud

    Hast du noch eine Idee, wonach ich sehen könnte?

    Elektronik Updates:

    Optokoppler:
    Um die Geschwindigkeit mit den TLP281 möglich machen benötigt man recht viel Strom und ein sehr hochohmigen Eingang, was mit die Siemens BCU nicht zu sein scheint, somit ist es mit der auf dem Breakout board vorliegenden Schaltung nicht möglich was hin zu bekomme, da man den Pull-up und den Basis Vorwiderstand nicht separat verändern kann. :-(
    Mit geändertem Transistor ist die Schaltung schon schneller, aber je nach verwendeten Transistor nicht Leistungsfähig genug um die SiemensBCU zu befeuern.
    Also noch kein erfolg :-(

    Geplant ist ein Gatter zwischen Optokoppler und SiemensBCU zu hängen.
    (Hochohmiger Eingang, Niederohmiger Ausgang)

    Levelshifer:
    Getestet habe ich auch bidirektionale Levelshifter, die einfachen N-MOS Transistor basierten sowie einen mit TI IC. (Warum bi-dierektional, hatte ich noch da...)
    Leider ohne erfolg, da die Siemens BCU zu niederohmig ist.
    Ein beschalten mit pull-ups/downs hat auch nicht geholfen :-(

    Somit wie oben beschrieben ein AND-Gate für 3V3 -> 5V und ein R-Teiler für 5V-> 3,3V



    Was verwendet ihr für ein NCN5120 Board?

    Einen Kommentar schreiben:


  • thesing
    antwortet
    So ich habe den aktuellen git-Stand nun (hoffentlich) repariert.

    Einen Kommentar schreiben:


  • thesing
    antwortet
    Für mich klingt das nach einem elektronischen Problem. Ich glaube es haben schon Leute den Stack mit einer Siemens BCU genutzt.

    Einen Kommentar schreiben:


  • DanS
    antwortet
    Hallo zusammen,

    sehr cooles Projekt, Respekt!

    Nachdem ich mit dem ESP32 und TPUART2 nicht wirklich weiter gekommen bin.
    Habe ich mich erstmal dazu entschlossen mit der SAMD21 HW zu starten.
    Nach ein paar seltsamen Fehlern mit meinen Optokopplern (4-fach TLP281)
    Hat sich rausgestellt, das sich diese in der verlöteten Schaltung viel zu träge für 19200 Baud.
    Verbesserung ist in der Mache.
    Verwende jetzt einen USB-UART Wandler mit optokopplern zum debuggen und trenne den TPUART2 vom KNX beim USB-flashen.
    Um die GPIOs des SAMD nicht zu brutzeln benutze ich jetzt einfache levelshifter.
    Da das programmieren über ETS immer noch nicht funktioniert hat bin ich auch mal in den Code abgestiegen.
    Leider musste ich feststellen das der TPUART2 doch nicht so gleich wie der NCN5120 ist :-(
    Hier meine Interpretation:

    Code:
    // services Host -> Controller :
    // internal commands, device specific
    #define U_RESET_REQ 0x01 //Same
    #define U_STATE_REQ 0x02 //Same
    #define U_SET_BUSY_REQ 0x03 //NCN5120
    // #define U_SET_BUSY_REQ 0x21 //TPUART2
    #define U_QUIT_BUSY_REQ 0x04 //NCN5120
    // #define U_QUIT_BUSY_REQ 0x22 //TPUART2
    #define U_BUSMON_REQ 0x05 //Same
    #define U_SET_ADDRESS_REQ 0xF1 // NCN5120 different on TP-UART
    // #define U_SET_ADDRESS_REQ 0x28 // TPUART2 different on TP-UART
    
    #define U_SET_REPETITION_REQ 0xF2 //NCN5120
    // #define U_SET_REPETITION_REQ 0x24 //TPUART2
    
    //knx transmit data commands
    #define U_L_DATA_START_CONT_REQ 0x80 //-0xBF
    #define U_L_DATA_END_REQ 0x40 //-0x7F NCN5120
    // #define U_L_DATA_END_REQ 0x47 //-0x7F TPUART2
    Doch leider ist es das wohl noch nicht gewesen...
    Hat jemand noch ne Idee bekomme folgende Nachrichten:
    Code:
    frame with invalid crc ignored<\r><\n>
    got UNEXPECTED: 0xFE<\r><\n>
    got U_STATE_IND: 0xEF<\r><\n>
    got U_STATE_IND: 0xFF<\r><\n>
    got U_STATE_IND: 0xBF<\r><\n>
    got U_FRAME_STATE_IND: 0xFB<\r><\n>
    got UNEXPECTED: 0xED<\r><\n>
    got U_STATE_IND: 0x57<\r><\n>
    frame with invalid crc ignored<\r><\n>
    got UNEXPECTED: 0xFE<\r><\n>
    got U_STATE_IND: 0xEF<\r><\n>
    got U_STATE_IND: 0xFF<\r><\n>
    got U_STATE_IND: 0xBF<\r><\n>
    got U_FRAME_STATE_IND: 0xFB<\r><\n>
    got UNEXPECTED: 0xED<\r><\n>
    got U_STATE_IND: 0x77<\r><\n>
    frame with invalid crc ignored<\r><\n>
    got UNEXPECTED: 0xFE<\r><\n>
    got U_STATE_IND: 0xEF<\r><\n>
    got U_STATE_IND: 0xFF<\r><\n>
    got U_STATE_IND: 0xBF<\r><\n>
    got U_FRAME_STATE_IND: 0xFB<\r><\n>
    got UNEXPECTED: 0xED<\r><\n>
    got U_STATE_IND: 0x77<\r><\n>
    frame with invalid crc ignored<\r><\n>
    got UNEXPECTED: 0xFE<\r><\n>
    got U_STATE_IND: 0xEF<\r><\n>
    got U_STATE_IND: 0xFF<\r><\n>
    got U_STATE_IND: 0xBF<\r><\n>
    got U_FRAME_STATE_IND: 0xFB<\r><\n>
    got UNEXPECTED: 0xED<\r><\n>
    got U_STATE_IND: 0x77<\r><\n>
    got unexpected L_DATA_CON<\r><\n>
    L_DATA_CON not received within expected time
    Zum programmieren verwende ich ETS5 seit Jahren in kombination mit eibf/knxd erfolgreich.

    Habe ich in der "tpuart_data_link_layer.cpp" noch was vergessen zu ändern?
    Datenblätter:
    NCN:
    https://www.mouser.de/datasheet/2/30...0-D-278521.pdf
    TPUART2
    http://www.opternus.com/uploads/medi...t_20130806.pdf

    Welche HW Kombination mit KNX-TP auf µC (nicht Linux) wurde schon getestet?

    Kann mir jemand evtl. schon mal paar Tipps geben wie ich die TPUART geschichte auf einem ESP32 zum laufen bekomme?
    (Meine Idee, in der knx_facade.cpp/.h die ifdef Geschichte des SAMD21 auf die ESP32 platform anzuwenden.)

    Grüße DanS

    Einen Kommentar schreiben:


  • blaubaer
    antwortet
    Zitat von blaubaer Beitrag anzeigen
    Wird es da bald eine Lösung geben
    Hallo Thomas,
    also bisher sieht es schlecht aus, ich warte noch auf die Optokoppler für die galvanische Trennung.

    Dafür habe ich heute den Weinzierl kBerry bekommen. Dieses läuft jetzt mit knxd und Raspberry 2 (ging ohne Probleme). Jetzt entwickle ich die von mir geplanten Geräte über die IP Schnittstelle.

    Gruß

    Werner

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    Zitat von Bernator Beitrag anzeigen
    Aber im Prinzip ist auch gar nicht so relevant wo blockiert wird, denn um zu keinem Zeitpunkt ein Telegramm ACK zu versäumen muss die Loop immer schneller als diese 1,7ms sein.
    Da hast Du auch wieder recht - nur leider ist dann die Ursache für mein Problem (kein ACK) nicht das, was ich dachte. So wie Du das beschreibst, gäbe es bei meinen 1-5ms nur mal sporadisch fehlende ACK und nicht reproduzierbar bei jedem WriteRequest.

    Ich werde das am Wochenende mal untersuchen und meine Findings berichten...

    Danke für die Einblicke,
    Waldemar

    Einen Kommentar schreiben:


  • Bernator
    antwortet
    Ja der rx-Buffer wird byteweise abgearbeitet aber die Reihenfolge ist anderst, das ACK wird nicht am Ende der Telegrammauswertung gesendet sondern sobald das "address type" Byte verarbeitet wurde, die eigentlichen Daten des Telegrammes kommen erst noch danach. Der Callback wird als letztes aufgerufen wenn das Telegramm den Stack durchlaufen hat.
    Aber im Prinzip ist auch gar nicht so relevant wo blockiert wird, denn um zu keinem Zeitpunkt ein Telegramm ACK zu versäumen muss die Loop immer schneller als diese 1,7ms sein.

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    Hi Bernhard,

    ich möchte betonen, dass ich bei Dir bin:
    Zitat von Bernator Beitrag anzeigen
    B) Loop Zeiten durch entsprechende Programmstruktur kurz halten (effizienteste Variante)
    Ich halte B) für sinnvoll und werde daran arbeiten, auch hier noch weiter zu optimieren (vor der Fehlermeldung hätte ich gesagt, dass ich schon gut optimiert habe ).

    Aber diesen Satz verstehe ich nicht:
    Zitat von Bernator Beitrag anzeigen
    Du hast einen Denkfehler, der Callback wird auch jetzt erst aufgerufen nachdem das Telegramm vollständig empfangen wurde, das Problem ist aber das ein langsamer Callback bzw. main Loop, den Empfang des nächsten Telegramms verzögert.
    Was ich meinte bisher verstanden zu haben:
    • Du arbeitest den rx-Buffer byteweise ab
    • Wenn ein ganzes Telegramm angekommen ist (in meinem Fall geht es um ein Schreibtelegramm), wird im Stack der GA-Lookup gemacht
    • Der Stack findet das passende KO und ruft den Callback auf
    • irgendwann ist man wieder in der loop() und Du sendest ein ACK
    • Wenn zwischen "Telegramm angekommen" und "ACK" zu viel Zeit vergeht (weil z.B. man im Callback trödelt), kommt das ACK zu spät und es gibt Telegrammwiederholungen.
    Das zumindest ist das Problem, dass ich habe, dass kein ACK gesendet wird (oder zu spät, das werde ich erst am Wochenende ausprobieren können, insofern ist alles nur theoretisch).

    Ich habe gar kein Problem mit dem Empfang des nächsten Telegramms, eher umgekehrt, die nächsten Telegramme sind Wiederholungen, die kommen durchaus an und die will ich eigentlich gar nicht haben.

    Oder meinst Du mit "Empfang des nächsten Telegramms", dass man den Empfang eines ACK verpasst? Darum geht es mir wie gesagt nicht, es geht um das Senden eines ACK nach dem Empfang eines Schreibtelegramms.

    Aber ich will auch nicht nerven, ich werde mich am WE mal hinsetzen und ein paar Tests machen, dann hoffe ich, dass ich die Materie besser verstanden habe.

    Gruß, Waldemar

    Einen Kommentar schreiben:


  • Bernator
    antwortet
    Eine Verbesserung der aktuellen Implementierung ist mir gerade noch eingefallen, man könnte die Kontrolle nicht pauschal nach jedem Byte an die main Loop abgeben sondern zumindest alle Bytes im RX Buffer bearbeiten....

    Einen Kommentar schreiben:


  • Bernator
    antwortet
    Du hast einen Denkfehler, der Callback wird auch jetzt erst aufgerufen nachdem das Telegramm vollständig empfangen wurde, das Problem ist aber das ein langsamer Callback bzw. main Loop, den Empfang des nächsten Telegramms verzögert.
    Natürlich könnte man hergehen und immer ganze Telegramme empfangen und erst dann zurück in die Main Loop springen, dann wäre die Warscheinlichkeit ein ACK zu verpassen geringer (nicht ausgeschlossen).
    Allerdings kostet das einiges, es wird damit der gesamte Programmablauf in den langsamen 9600baud Takt der Seriellen gezwungen, der Stack blockiert damit bei jedem Telegramm am Bus (auch fremde) zwischen 11ms (8 Byte) und 31ms (23Byte, bei Extended Frames bis zu 356ms).
    Das wäre zwar der klassische Arduino Ansatz, hauptsache ich (Library) funktioniere, alles was nach mir kommt (Kombi mit anderen Libraries) ist mir egal, aber gerade für einen Kommunikationsstack der ja nur neben der eigentlichen Applikation laufen soll finde ich das nicht sonderlich prickelnd

    Folgende Möglichkeiten sehe ich:

    A) gesamte Telegramm in einem Rutsch einlesen, Stack blockiert in der Zeit (je nach Applikation die parallel laufen soll problematisch)
    B) Loop Zeiten durch entsprechende Programmstruktur kurz halten (effizienteste Variante)
    C) Teile des Telegramm empfanges in Interrupt (ISR) auslagern (Zeit GA Tabelle durchsuchen im Auge behalten)
    D) OS verwenden und mit unterschiedlichen Task prioritäten arbeiten (mit OS overhead leben)
    E) Auto ACK beim tpuart aktivieren und damit mehr Spielraum beim Timing gewinnen (darf man pauschal alle GAs mit ACK bestätigen??)

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    Hallo Bernhard,

    vielen Dank für die ausführliche Erklärung. Und kaum weiß ich, was abgeht, habe ich schon gesehen, dass ich für das KO, bei dem das Problem festgestellt wurde, im Callback zu viel mache (ca. 1-5 ms). Ich hätte aber noch 2 eher konzeptionelle Fragen:
    1. Da so ein ACK nun mal zeitkritisch ist, wäre es nicht sinnvoller, das Telegramm zu empfangen, den GA-Lookup zu machen, den ACK zu senden und dann erst den Callback aufzurufen? Wobei ich nicht wirklich weiß, ob das technisch geht, bin immer noch unterwegs und kann nicht testen.
    2. Wenn ein Telegramm X empfangen wurde und "nur" der ACK zu spät gesendet wurde, sollte dann nicht der Stack die Wiederholungen X1, X2, X3 ignorieren, selbst wenn sie verschickt werde bzw. dann nach der X1 nochmal (zeitnah) einen ACK schicken anstatt die Wiederholung wieder zum Callback durchzureichen?
    Wie gesagt, ich werde mit der vorhandenen Info hoffentlich die Probleme lösen können, aber so wie es implementiert ist, kann es bei zukünftigen Erweiterungen/Änderungen wieder zu Verzögerungen und erneut zu ACK-Ausfällen kommen. Andersrum würde der Stack zuverlässig für einen ACK sorgen und dann erst die Kontrolle abgeben...

    Gruß, Waldemar

    Einen Kommentar schreiben:


  • Bernator
    antwortet
    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.

    Einen Kommentar schreiben:


  • thesing
    antwortet
    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

    Einen Kommentar schreiben:


  • mumpf
    antwortet
    Hi Bernhard,

    Zitat von Bernator Beitrag anzeigen
    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

    Einen Kommentar schreiben:

Lädt...
X