ESP8266 KNX mit ETS

[MarS1]

Hallo Thomas,
kann ich mit deinem Stack auch Data Secure realisieren?
Vielen Dank schon mal.
VG Marcus

[thesing]

Getestet habe ich es nicht, aber es sollte funktionieren. Ggf. musst du den richtigen SerialPort bei Erstellung der Esp32Platform übergeben (oder den Standard ändern https://github.com/thelsing/knx/blob...latform.cpp#L9)

VG Thomas

[SebastianObi]

Hallo Thomas,

Ich benutze deinen Stack schon länger mit dem SAMD21 ohne Probleme. Jetzt würde ich gerne auf den Leistungsfähigeren ESP8266 oder so umsteigen. Da ein Projekt das erfordert um andere Hardware anzuschließen die beim SAMD nicht läuft.

Soweit ich verstanden habe hat der ESP8266 keinen richtigen Seriellen Port um KNX TP anzuschließen, richtig?
Der ESP32 hat wohl mehrere Uarts. Unterstützt dein Stack den ESP32 mit TP? Das wäre für mich den Idealfall. WLAN würde ich gerne nicht benutzen.

VG Sebastian

[thesing]

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

VG
Thomas

[DanS]

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

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?

[thesing]

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

[thesing]

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

[DanS]

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:

// 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:

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

[blaubaer]

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

[mumpf]

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

[Bernator]

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.

[mumpf]

Hi Bernhard,

ich möchte betonen, dass ich bei Dir bin:

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:

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

[Bernator]

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....

[Bernator]

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??)

[mumpf]

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