Kopp Free Control und NanoCUL

[Feuerdrache]

Moin,
soweit ich das in der nanoCul.c sehen kann werden 2s für den Watchdog eingestellt, möglich sind Zeiten von 15ms bis 8s.

Das folgende habe ich mir Angelesen:
Bei einem Reset durch den Watchdog wird auch die Watchdogzeit zurückgesetzter nicht der jedoch Watchdog deaktiviert. Das führt dazu, das der Programmcode innerhalb von 16ms (Minimum des Watchdogtimers) den Watchdog deaktivieren oder anderweitig bedienen muss. Dies würde der CulFw Code auch als erstes tun, dazu kommt es jedoch nicht, das der Bootloader nicht in der verbleibenden Zeit abgearbeitet wird und der Watchdog erneut auslöst. Dieser Fehler ist vom standard Bootloader des Arduino Nano bekannt und als Lösung wird Optikboot Vorgeschlagen, da der Bootloader deutlich schneller den eigentlichen Programmcode startet und damit das abschalten des Watchdogs im Programmcode wirken kann, bevor der Watchdog zuschlägt.

Daraufhin habe ich einen nano mit Optikboot über einen anderen nano per ISP-Sketch versehen. (Details wie es geht bei Bedarf.)

Mit dem Optikboot habe ich es bisher nicht hinbekommen den nanoCul zum Absturz zu bringen. Als Gegenprobe habe ich den nanoCUL wieder mit den Original Bootloader versehen und habe ich es wieder hinbekommen den nanoCul zum Absturz zu bringen.

Ich hoffe ich hab nichts vergessen. Mein Produktiver nanoCul (Kopp_FC) läuft jetzt erstmal mit dem alternativen Bootloader und ich hoffe das er stabiler läuft als bisher.

Gruß FD

[RaspII]

Hi,
es hat mir einfach keine Ruhe gelassen, warum es überhaupt zu Nullbotschaften kommen konnte.
Ich hatte zwar schon eine Abfanglösung eingebaut, verstanden hatte ich den Wirkmechanismus aber nicht (bis eben).

Ich habe meinen alten Post
https://forum.fhem.de/index.php/topic,47846.msg409228.html#msg409228
angepasst. Ein  verbessertes kopp-fc kommt bei Gelegenheit.

Bgzl. Watchdog:
Danke für die Info.
Ich habe noch nicht herausgefunden, zu welchem Zeitpunkt der Watchdog in der culfw offiziel zurückgesetzt wird.
Meine Empfangsroutine benötigt eigentlich nicht viel Zeit, deshalb kann ich mir nicht vorstellen, dass hier etwas schief geht.
Wann hattest Du mit dem alten Bootloader die Watchdog Resets gesehen (oder vermutet).
Wenn die Kopp Handsender viel Aktivität erzeugen (nanoCUL empfängt Daten) oder wenn Du über den nanoCUL viel Datenverkehr erzeugst (beim Senden)?
Ich könnte Dir je nach Antwort Testversionen zur Verfügung stellen, die den Watchdog entsprechend ruhig stellen.

[Feuerdrache]

Heute habe ich es nur mit häufigem senden provozieren können, Gestern auch beim Empfang. Ich erzeuge beim testen die Daten mit einem anderen nanocul auf einem anderen FHEM. Im Tagesbetrieb kam es auch immer mal wieder vor, wenn man nur zwei oder drei Tasten auf der original FB gedrückt hat. Ich vermute ein Zusammenhang mit dem was hier so in der Nachbarschaft funkt.

Besser fände ich eine Debug version, die Nachrichten produziert, wenn der watchdogs behandelt wurde, dann kann man im log evt nachvollziehen, was passiert ist.

[RaspII]

Hi,
das wird schwierig, weil ich mich mit der Standard Watchdog Behandlung nicht auskenne.

Ich bau Dir mal eine Testversion die den Watchdog immer dann ruhigstellt wenn meine kopp-fc "gerufen" wird.
Dann kannst Du zumindest sicher sein, dass die kopp-fc die Ursache für die Watchdog Resets ist.
Sollt das funktionieren muss ich mir überlegen (am besten mit Support von Rudi) wie eine saubere Lösung aussieht,
falls nicht muss Du nach anderen Ursachen suchen, wie z.B.
- Spannungsversorgung ist nicht stabil/bringt zu wenig Strom

Ich fang mal mit dem Watchdog an, evt. bekommst Du schon in ca. 1 Stunde die Testversion.

[Feuerdrache]

Lass dir Zeit, ich komme wahrscheinlich erst am we wieder dazu etwas zu testen.

Gruß FD

[RaspII]

Zu spät 

Anbei die Testversion der kopp-fc.c.

Änderungen:
1.
Bei jedem Aufruf einer Sende oder Empfangstask wird pauschal der Watchdog bedient.
Die Laufzeiten innerhalb der kopp-fc sollten damit nicht mehr zu einem Watchdogreset führen können (das war ja Deine Theorie).

2.
Ich habe für die Empfangsroutine noch einen Debugmode eingebaut
Das Kommando krS startet wie gehabt den "normalen" Empfangsmode u.A. für FHEM
Das Kommando KrS1 gibt alle empfangen Blöcke incl. eventuelle Checksummenfehler aus (letzteres konnte ich mangels Fehler nicht testen)
Das Kommando KrS2 gibt alle empfangen Bytes aus, also auch die "Füll Nullen" am Ende der Botschaft sowie im Fehlerfall jeden Schrott

Dazu muss man eines beachten/wissen:
Der CC1101 ist so konfiguriert, dass er sein Fifo nur füllt sobald ein gültiges Sync Pattern (=AA54 Hex) empfangen wurde.
D.h. typischerweise werden keine Botschaften anderer Prototkolle weitergereicht, es sei denn es wird zufällig ein gültiges Sync Pattern gesendet.
Also nicht wundern, auch im Byte Mode kommen normalerweise nur gültige Kopp Botschaften.
Ich zumindest habe noch nie andere Botschaften gesehen, es sei denn ich hatte Verdrahtungsfehler beim GDO2 Pin.

So, dann wünsch ich Dir viel Spass beim Dauertest

P.S.:
Ich habe bei meinem CCD Modul (läuft im Dauerbetrieb im Kopp-Mode) die Uptime ausgelesen, das Modul läuft seit
7 Tagen,  00:00:34 (Stunden Minuten Sekunden) ohne Reset

Nachtrag 22:09:
die im Beitrag https://forum.fhem.de/index.php/topic,47846.msg434618.html#msg434618
angekündigte Verbesserung bzgl. Ausgabe von "Nullbotschaften" habe ich ebenfalls implementiert

[Feuerdrache]

So, ich bin zum testen gekommen.
Mit der neuen Kopf_fc.c hab ich es nicht wieder geschafft den nanoCUL zum Absturz zu bringen. Hab vorher extra nochmal mit der Trunk 553 Version getestet um eine Veränderung zu sehen. Also eine gute Änderung.

Ich werde die Versions nachher mal auf meinen Produktiven nanoCUL machen und die Woche beobachten.

Beim testen ist mir noch ein Fehler aufgefallen: Nachdem der nanoCUL ein Reset gemacht hat empfängt FHEM nichts mehr, bis man ein reopen macht.  Dabei ist es egal ob man den Resetbutton drückt, oder ob der watchdog den Reset auslöst.

Soweit ich das sehe, bekommt FHEM einen Reset des nanoCUL nicht mit und initialisiert ihn nicht neu. Ich vermute das das ein generelles Thema von FHEM ist. Hab nur noch keine Idee, wo ich das einkippen kann bzw wen ich anschreiben kann.

Soweit erstmal.

Gruß FD

[RaspII]

Hallo Feuerdrache,

bzgl.:

Hab vorher extra nochmal mit der Trunk 553 Version getestet

Du hast nicht geschrieben wie Dein Test mit der Trunk Version ausgegangen ist.
Ich nehme mal an, Du hattest damit noch die Probleme?

Ja, mir ist das auch schon aufgefallen, dass nach einem RESET keine Neuinitialisierung passiert, beim abziehen des CULs allerdings schon
(wundert mich etwas).

Generell denke ich aber, dass man das Watchdog/Resetproblem in Griff bekommen sollte.
Ich hatte Rudolf deswegen schonmal angeschrieben, er hatte mir damals auch einige nützliche Tipps gegeben.

Generell denke ich aber man muss defininieren, wie sich die jeweiligen Protokolle bzgl. Watchdog verhalten sollen.
(oder wie viel Zeit man in seinen Routinen benutzen darf)

Was ich im Augenblick beim Kopp Protokoll mache sollte man eigentlich nicht tun (den Watchdog einfach mal bedienen).
Wenn man ausversehen in Endlosschleifen gerät schlägt dann der Watchdog evt. nicht mehr zu und das System bleibt stehen.

Trotz allem macht es schon Sinn wenn FHEM auf Resets reagieren würde.
Dazu müsst man mit dem CUL eine Art "Resetbotschaft" senden und FHEM müsste diese Botschaft auswerten.
Am besten Du startes zu diesem Thema einen neuen Thread.


Hast Du mal nachgeschaut, ob Dein nanoCUL (ATMEGA 328) dieselbe Watchdogzeiten hat wie der Original CUL (32U4) mit 8Mhz?

Was mich noch interessieren würde ist ob Dein System (Kopp) stabil läuft.
Kannst Du mir mal ein Log mit dem Terminal Program zusenden
1x Empfang via Befehl krS1
1x Empfang via Befehl krS2

mich interessiert auch was passiert wenn keine Taste an der Fernbedienung gedrückt wird.
Siehst Du dann Botschaften oder nicht?

Gruß
RaspII

[Feuerdrache]

Moin,
da ist wohl ein Satz verloren gegangen. Ja mit der trunk Version hab ich den nanoCUL mit häufigem senden zum Absturz bringen können. Nachdem Austausch der Kopp_fc.c nicht mehr. Die angepasste version läuft jetzt auch auf meinem Produktiven FEHM/nanoCUL.

Ich finde es nicht bedenklich, wenn die Kopp Routine den Watchdog beim Aufruf bedient, allerdings habe ich mich in dem Culfw code noch nicht zurechtgefunden. womit arbeitest Du, wenn Du den Code bearbeitest, bzw. wie bekomme ich eine Übersicht welcher Datei ich welche Funktion finde, ohne alle Dateien durchzusehen?

Bezüglich Reset: Fhem bekommt das abziehen und anstecken über den Seriellen port mit, wenn der atmega 328 einen reset macht, bekommt der ftdi seriell zu USB Konverter das evt mit, meldet es aber nicht weiter. Ich sehe das genauso wie Du, es  gibt nur die Lösung, das die Culfw beim booten eine Meldung von sich gibt und damit FHEM mitbekommt, das es was tun muss, aber das werde ich mal in einem neuen Thread schreiben.

Das Log mit dem Terminalprogramm muss ich dir noch etwas schuldig bleiben... verschoben, aber nicht vergessen.

Gruß FD

[RaspII]

Hi,
für die SW Entwicklung nutze ich WIN-AVR bzw. den mitinstallierten Programmers' Notepad.

Das ist eine gute Entwicklungsumgebung bei der man seine Projekte definieren kann und schnellen Zugriff auf die wesentlichen Daeien hat (legt man im linken Browserfenster fest).
Ich nutze das Tool eigentlich nur als Editor.
Zusätzlich gibt es eine Suche
a) im Dokument
b) über eine Verzeichnisstruktur (siehe Anhang), das Ergebnis steht unten im Ergebnis Fenster.
Dazu musst Du oben in das Folder Symbol neben der Suchleiste anklicken.

Meinen Source Code habe ich auf dem Raspberry Pi und zwar als SVN Clone.
Auf dem Raspi habe ich eine Samba Freigabe eingerichten, damit kann ich komfortabel vom PC aus zugreifen.

Compiliert wird das ganze dann auf dem Raspi.
(Würde theoretisch auch auf dem PC gehen, auf dem Raspi hat man aber schneller die richtige Compiler etc. verfügbar, sollte Rudolf umsteigen (mir war wichtig, das das kompilierte Projekt binärkompatibel zur Übersetzung von Rudolf ist, sofern ich die selben Dateien übersetze).

[Feuerdrache]

Moin Rspii, die Testversion von dir verrichtet klaglos ihren Dienst bei mir und macht keine Mucken. Hab trotz Standard Bootloader keine Notschreien mehr gehabt.


Gesendet mit einer zu kleinen Tastatur

[RaspII]

Hi,
Ok, dann mache ich die neue FW bei Gelegenheit mal "offiziell".
Aktuelle kopp-fc ist in SVN eingestellt. Sobald Rudolf die FW wieder baut gibt es dann die nächste offizielle Version.

[Herby22]

Hi,
Ok, dann mache ich die neue FW bei Gelegenheit mal "offiziell".
Aktuelle kopp-fc ist in SVN eingestellt. Sobald Rudolf die FW wieder baut gibt es dann die nächste offizielle Version.

[RaspII]

Hi,
finde nur das Zitat, keinen weiteren Kommentar?
Trotzdem mal den Status:
Es könnte beim Bauen der neuen CUL FW zum Überlauf des Flashes kommen, da mein kopp_fc Modul jetzt mehr Speicher braucht wie verfügbar.
Da sich das Kopp Modul nur exclusive nutzen lässt, werde ich vermutlich eine eigene Kopp culfw Variante bauen.

Ich ahbe aber gerade keine Zeit, d.h. komme vermutlich erst im Herbst dazu.

Gruß
RaspII

[dieter114]

Hallo RaspII
Ich habe mal einen Nano mit 868MHz aufgebaut.
Der Kopp Rolladenschalter 8080.02 wird erkannt allerdings geht nur eine Richtung.
define Rolladen KOPP_FC F7 9EAA 03 00
Also stop, down, bottom geht aber nix mit rauf.
CUL_A_RAWMSG kr079EAAE8F7CC0F0346
Definitionsfehler oder was könnte das sein?

Gruß Dieter