Erfahrungsberichte

[Masifi]

Das kann sein, wenn du UC2 nicht auf GND verbunden hast. Im Post Nr 20 von Eugen sind die Lötbrücken eingezeichnet.

Unbenannt.PNG

[mode]

Hab ich auch gerade im Datenblatt gesehen. Dann ist wohl UC2 Pin 29 des NCN nicht richtig verlötet und daher nicht LOW.
Werde ich morgen korrigieren

[mode]

Soo nun auch mal gute Nachrichten.
Pin 29 sah optisch Top aus. Trotzdem nachgelötet. Lib wieder auf Parität Even gestellt und:

Setup KnxTools
createProgComObject
Manufacturer: DEADhex
Device: FFhex
Revision: 0hex
numberOfCommObjects: 3
_deviceFlags: 10001bin
Using EEPROM
ComObj index=1 Suite-ID=0 HI: 0x0 LO: 0x1 GA: 0x1 Settings: 0x80 Active: 1
ComObj index=2 Suite-ID=1 HI: 0x0 LO: 0x2 GA: 0x2 Settings: 0x80 Active: 1
IA: 0x11C7
KnxDevice startup status: 0x0
getParamValue: index=0 _paramTableStartindex=19 skipBytes=0 paramLen=2
 val[0]@19 --> 0xFF
 val[1]@20 --> 0xFF
Toggle every 4294967295 ms
Setup is ready. go to loop...

Und Kommunikation mit dem NCN ist auch sauber. Wie das Scope so schön sagt. Parität "sonst". Ich liebe gute Übersetzungen


NewFile1.png

[tuxedo]

Das sind gute Nachrichten. Und auch ein wichtiger Hinweis hinsichtlich der Löt-Qualität des NCN. Meine Lötstellen sehen auch "super" aus. Aber ausprobiert hab ich die noch nie (meine Platinenbestellung dauert noch ein wenig).

[mode]

Nachtrag: Testsketch lässt sich mit Testprojekt in der Suite konfigurieren und tut was er soll. So jetzt steht eine stabile Basis auf der ich aufsetzen möchte.
Gibt es schon einen Horizont für die Beta 4? Was wird sich darin für den "Anwender" der Lib ändern?

LG

Mode

[tuxedo]

Guckst du hier: https://knx-user-forum.de/forum/proj...-entwicklungen

Einen beta3 Sketch wirst du anpassen müssen dass er mit Beta4 funktioniert. Wird aber nicht soo wild werden.

[mode]

Eine Frage noch zum Init des NCN.
Wir senden 0x28 0x11 0xC7 wobei die letzen beiden Bits die PA sind.
0x28 entspricht dem KOmmando U_IntRegWr.req auf Register 00. Register 00 ist aber für den Watchdog des NCN zuständig. Wie kann so die PA gesetzt werden? Ich hätte hier ein 0xF1 U_SetAddress.req erwartet...

[tuxedo]

So ins Detail hab ich da noch nicht rein geschaut. Gibts mit dem Verhalten irgend ein Problem, oder interessiert es dich einfach nur?
Muss da selbst erstmal die Doku dazu befragen.


[update]

In der Tat, das ist verwirrend. 0x28 steht für U_IntRegWr.req auf Registeradresse 0x00, was dem Watchdog-Register entspricht.

0x11 0xC7 wobei die letzen beiden Bits die PA sind

Was du meinst sind nicht Bits, sondern Bytes.

Noch verwirrender ist aber der Umstand, dass beim Schreiben (0x28) auf das Register (0x00) nur ein Byte geschrieben werden kann und nicht zwei.

In KnxTpUart.h (https://github.com/KONNEKTING/Konnek...nxTpUart.h#L61) ist TPUART_SET_ADDR_REQ auch tatsächlich auf 0x28 eingestellt.

Interessanterweise passt die PA aber wenn der Arduino Daten auf den Bus sendet. D.h. "irgendwie" funktioniert es. Aber warum?

Du kannst ja mal probieren 0x28 in der Header-File durch 0xF1 zu ersetzen?!

[update2]
Die PA muss im BCU auch nicht hinterlegt werden... Wenn der Arduino ein Gruppen-Telegramm sendet, dann trägt er direkt in das Telegramm die PA ein.

Aus der NCN Doku:

Set Address Service
Sets the physical address of the device and activates the auto−acknowledge function. NCN5120 starts accepting all frames whose destination address corresponds to the stored physical address or whose destination address is the group address by sending IACK on the bus. In case of an error detected during such frame reception, NCN5120 sends NACK instead of IACK.

Heißt zu deutsch: Wenn man die PA hiermit setzen würde, müsste man sich nicht selbst um das ACK/NACK kümmern und hätte dies auf Hardware-Level ausgelagert. Tut man das nicht, so muss sich die Logik im Arduino selbst darum kümmern. Was auch nicht sooo verkehrt ist. Denn damit kann man z.B. ein Gerät mit mehreren PAs ausstatten (hat z.B. MDTs neuer IP Router so drin... Da gibt's zwei PAs, weil es eigentlich zwei Geräte in einem sind).

Zurück zu unserem Code:

https://github.com/KONNEKTING/Konnek...pUart.cpp#L223

Wenn man den Block in Zeile 223-227 einfach weg lässt, dürfte das nach meinem befinden nichts am Code ändern, denn der Request ist sowieso fehlerhaft (in das register kann man nur 1 byte schreiben, und keine zwei...).

Wenn du 0x28 im Header durch 0xF1 tauschst, "könnte" das Auswirkungen auf den restlichen Code haben. Denn da senden wir selbst entsprechende ACK/NACK Nachrichten wenn wir im Programmiermodus sind. Im schlimmsten Fall funktioniert die Kommunikation nicht richtig wenn der BCU selbst ein ACK sendet wo wir z.B. ein NACK senden würden.

Kurzum: Probier's aus. Einmal mit 0xF1 statt 0x28, und einmal komplett ohne den Block in Zeile 223-227.


[update3]
Gerade eben erst gemerkt: Das Auto-ACK des BCU basierend auf der PA betrifft ja nur Nicht-Gruppen-Telegramme. Denn Gruppen-Telegramme werden anhand der Gruppenadresse adressiert und nicht anhand der PA (die gibt's im Telegramm nur als "absender).
Die PA als adressierung gibt's nur bei Dingen wie "property-read/write" oder "memory-read/write" (beides wird bei "echten" KNX Geräten dazu benutzt die das Gerät zu programmieren. Kann man in der ETS im Gruppenmonitor verfolgen wenn man ein Gerät mittels ETS programmiert). Denn die werden an ein bestimmten Gerät anhand der PA adressiert.
Aber das kann unsere Implementierung noch gar nicht.
Ergo: Selbst wenn man das von 0x28 auf 0xF1 "korrigiert", dürfte das den aktuellen Code zur Laufzeit nicht beeinflussen.
Würde deshalb eher den Block Zeile 223-227 streichen/entfernen und - wenn das dann immer noch alles funktioniert - an dieser Stelle dokumentieren dass man normalerweise 0xF1 zum setzen der PA benutzt. Falls wir das mal brauchen.

[mode]

Vielen Dank für die Analyse. Ich habe jetzt bald meinen cpp Kurs durchgearbeitet und versuche nun die Lib vollständig zu verstehen. Da ist mir das eben aufgefallen. Ein Problem damit gibt es nicht. Ausser dass der WD des NCN mit ungültigen Werten konfiguriert wird, was aber kein Problem darstellt, da er von der Hardware her nicht mit dem ATmega verbunden ist.
Könnte man den WD des NCN nicht als externen WD für den Atmega nutzen? Dann könnte der NCN den Atmega resetten und wir würden das Bootloop Problem umschiffen.

Watchdog
NCN5120 provides a Watchdog function to the host
controller. The Watchdog function can be enabled by means
of the WDEN−bit (<WDEN>, see Watchdog Register, p51).
Once this bit is set to ‘1’, the host controller needs to re−write
this bit to clear the internal timer before the Watchdog
Timeout Interval expires (Watchdog Timeout Interval =
<WDT>, see Watchdog Register, p51).
In case the Watchdog is acknowledged too early (before
tWDPR) or not within the Watchdog Timeout Interval
(tWDTO), the RESETB−pin will be made low (= reset host
controller).
Table 8 gives the Watchdog timings tWDTO and tWDPR.
Details on <WDT> can be found in the Watchdog Register,
p51.

[tuxedo]

Theoretisch wäre das möglich. Hat aber auch etwaige Nachteile. Würde das erstmal nicht direkt verdrahten wollen. Das Reboot-Problem ist damit auch nicht gelöst. Denn nach der Programmierung brauchen wir den Reset (die Parameter und KOs werden nur nach dem Start eingelesen). Wenn der WDT einen passenden Reset an den AVR weitergeben würde, würde das den Reboot-Loop abwürgen, aber das Register im AVR für den AVR eigenen WDT ist noch gesetzt und der Reboot läuft weiter in einer Schleife. Das lässt sich nur durch einen Power-Cycle lösen.


Die ganze Lib musst du übrigens nicht direkt verstehen. Da steckt viel C++ Zeugs drin, das man in einer "normalen C++ Welt" so nicht unbedingt machen würde, aber in einem solchen "Embedded System" gang und gebe ist. Das hab ich auch schon schmerzlich erfahren müssen bei diversen Umbauaktionen (die dann im nachhinein ein Reinfall waren weil sich das in einem Embedded-System so nicht machen lässt).

Kurzum:

Schau dir die Beispiel-Sketches an die im Examples-Ordner liegen. Damit hast du einen Großteil (>90%) der Lib-Funktionalität gesehen. Wie sie intern arbeitet ist nicht unbedingt interessant.