KNX @ Arduino Pro Mini: WDT Problem

[tuxedo]

Ich schau mal dass ich die Defferenzen herausdividiere und das ganze mal auf den Kopf stelle um zu sehen was dadurch dann anders ist... Meld mich gleich wieder mit Details.

[Masifi]

Zwischenfrage: kann ich denn dann auch einen Promini mit einem 4Mhz Quartz bestücken, die Bootloader-Datei (siehe Oben) auf

optiboot32.build.f_cpu=4000000L

ändern und hoffen das dann noch alles funktioniert !? Warum ich das machen will spielt in erster Linie mal keine Rolle, es geht mir um das Verständnis an sich.


Eugenius Danke für dein Einsatz !!! :-)

[tuxedo]

So, erstes Fazit:

Das Hinzufügen des oben gezeigten Abschnitts lässt ein neues Board in der Arduino IDE erscheinen. Also ein eigenes, neues Board-Setup.
Hab daraufhin mal die Angaben des neuen Board-Eintrags mit denen des existierenden ProMini verglichen. Dazu musste ich die neuen Boardangaben erstmal in die Reihenfolge der existierenden Boards bringen um den Vergleich sauber darzustellen: board_diff.png

Dabei ist gleich aufgefallen, dass ein paar der neuen Zeilen sich gegenseitig vom Wert her überschreiben: Ich bin mir sicher, dass die Boards.txt als "Java Properties File" von der Arduino IDE eingelesen wird. Und die besteht aus "key=value" Paaren. Taucht ein "key" mehrmals auf, zählt der zuletzt gelesene, also der, der weiter hinten in der Datei steht.

Jetzt gibt's zwei Vergleiche die man anstellen kann:

1) Die Empfehlung aus https://andreasrohner.at/posts/Elect...he-bootloader/ vs. die Standardeinstellungen
2) Eugenius' Mod vs. die Standardeinstellungen

Für 1):

Die Empfehlung ändert nur den Zeiger auf das optiboot-Hex-File, sowie die upload-speed.

Für 2):
Hier liegt der Unterschied in mehreren Parametern/Keys:

* bootloader.lock_bits --> Keine Ahnung was der Unterschied ausmacht
* upload.maximum_size --> Der Optiboot-Bootloader ist kleiner, also stehen für den SKetch 1536 bytes mehr zur Verfügung??
* bootloader.low_fuses --> Keine Ahnung was der Unterschied ausmacht
* bootloader.high_fuses --> Keine Ahnung was der Unterschied ausmacht
* bootloader.file --> Logo, anderer Bootloader, andere HEX File....


Werde die Änderungen heute Abend selbst nochmal ausprobieren und schauen wie wir die Änderungen möglichst einfach ohne "Dateimodifikation" für jeden in die IDE rein bekommen (hab da schon eine Idee....). Ich hoffe ja noch auf Feedback von den Arduino-Jungs: https://github.com/arduino/Arduino/issues/4492

Gruß
Alex

[tuxedo]

Zwischenfrage: kann ich denn dann auch einen Promini mit einem 4Mhz Quartz bestücken, die Bootloader-Datei (siehe Oben) auf

optiboot32.build.f_cpu=4000000L

ändern und hoffen das dann noch alles funktioniert !? Warum ich das machen will spielt in erster Linie mal keine Rolle, es geht mir um das Verständnis an sich.

Jepp, das müsste gehen. Vielleicht wird noch eines der "fuses" verändert werden müssen, aber prinzipiell müsste das so funktionieren. Ob der Bootloader aber damit umgehen kann weiß ich nicht. Könnte sein dass er mit so wenig Speed nicht zurecht kommt?!

[Eugenius]

@Masifi:
4Mhz geht:
http://ava.upuaut.net/?p=383

8Mhz kann man komplett ohne Quarz nutzen:
http://www.homautomation.org/2014/11...ternal-quartz/

1Mhz geht auch, aber nur mit 9600 Baudrate...

optiboot32.build.f_cpu=1000000L
optiboot32.bootloader.low_fuses=0x62
optiboot32.upload.speed=9600

tuxedo, Optiboot ist wirklich kleiner, manche nutzen Optiboot genau deswegen.
zu den Fuses: http://www.engbedded.com/fusecalc

[tuxedo]

tuxedo, Optiboot ist wirklich kleiner, manche nutzen Optiboot genau deswegen.
zu den Fuses: http://www.engbedded.com/fusecalc

Danke für den Link. Damit sollte man herausfinden was genau der Unterschied in den Fuses ist.

[update]
So, hier der Vergleich:
diff_fuses.png

[tuxedo]

Die Lösung wird mit meinem 16Mhz Nano so nicht funktionieren. Es gibt nämlich keinen 16Mhz internen Oszillator.
Der Unterschied ist eigtl nur:

* 16CK/14CK vs. 6CK/14CK
* Ext. Crystal vs. interner RC Osc.
* Boot Flash Section Size: 1024 vs 256

Ich werde heute Abend mal probieren ich ich mit dem einfachen ändern der Section Size zusammen mit dem Optiboot das Problem schon beheben kann.

[update]

Interessant ist:

Wenn man in die Boards.txt schaut und nach dem Nano sucht, dann hat der auch die Fuse-Bits:

low=0xFF
high=0xDA
extended=0x05

Und wenn ich das in besagtem Fuse Bit Calculator eingebe, lande ich bei externem quartz mit 8Mhz, OBWOHL der Nano mit 16Mhz in der boards.txt angegeben ist?! Kann sich das einer erklären?

[update2]

Ahh... jetzt: In der Beschreibung (letzter Screenshot) steht ja:

"Frequency: 8.0- Mhz" ... Also "ab 8Mhz", das umfasst dann logischerweise auch 16Mhz.

[tuxedo]

Hab Feedback aus der Arduino Community bekommen:

omparing that with the original nano entry, I suspect that the fuse bits influence this. Comparing these, I've found that the clock selection is different (the nano uses the external crystal, your entry uses the internal oscillator) and the bootloader size is different (nano has 1024 words, your entry 256).
I considered the latter is the reason it doesn't work - the bootloader size defines the start address, so when that is still at 1024, the CPU boots up at the wrong place. Since unused bytes are 0xff which I think are just (effectively) nop instructions, the CPU first has to grind through (1024-256=768) 0xff bytes before reaching the bootloader, which is probably some 1600 cycles or something, or 100us. Since the smallest watchdog timeout is 2ms, optiboot should still be in time to reset MCUSR, so perhaps that's not it. Perhaps you could try modifying the nano entry to use optiboot and use high_fuses=0xDE to just set the bootloader size, to see if that is sufficient?

Deckt sich mit meinen bisherigen Erkenntnissen. Ich probier das heute Abend aus.
Die Frage ist dann aber immer noch:
Warum kann der Default-Bootloader nicht richtig mit dem WDT umgehen?! Hab das mal als Gegenfrage an die Community zurück gegeben. Vielleicht bekommen wir hier bald einen Fix für ...
Andernfalls müssen wir eine eigene Board-Konfiguration anbieten.

[Eugenius]

Aber einen anderen Bootloader zu flashen ist doch fast genauso leicht wie Sketches hochladen.
D.h. man kann einfach "meine" Lösung für die Pro Minis anbieten/voraussetzen.

[tuxedo]

Wenn wir im anderen Thread schon auf dem Level sind dass Nichtswissende Anfänger Gerätschaften nachbauen können sollen (der 0815 Anfänger gerät schon ins straucheln wenn keine USB Schnittstelle zum uploaden des Sketches da ist), und auch wenn man den Gesichtspunkt der potentiellen Fehlerquellen der Bastelei betrachtet, so bin ich um jede vermiedene Fehlerquelle froh.

Einen Bootloader flashen... Braucht man einen weiteren Nano oder vergleichbar oder einen USBTinyISP. Wenn sich das komplett vermeiden lassen würde weil die Arduino Jungs den saublöden Bug beheben, dann wäre ich echt froh drum.

Kurzum: Einem Bug-Workaround ist immer ein sauberer Bugfix vorzuziehen.

[Masifi]

Wenn man sich eine solche Platine baut und den Controller schon darauf platziert, dann kommt man um das flashen des Bootloaders eh nicht mehr drumrum.
Also ganz schlimm wäre es nicht wenn man den spezielen Bootloader flashen muss, aber Tuxedo hat da schon recht, wenn man es offiziell beheben kann ist es umso besser.

[Eugenius]

Sogar wenn die den Bug beheben, dauert es noch Monate bis die neuen Minis mit neuen Bootloader kommen. Ob die ganzen clones den neunen auch übernehmen ist auch fraglich.

Und du hast recht, als ich angefangen habe, hatte ich auch Probleme mit fehlendem USB. Jetzt ist mir egal. Bootloader habe ich gestern auch zum ersten Mal geflasht

Man kann, oder sogar muss, die Anwender in 3 Gruppen aufteilen:

• 1. 0815 Anfänger braucht fertigbestückte Platine mit einem USB Port und richtigem Bootloader, weiß nicht wie man Lötkolben nutzt
• 2. Leute die mit Pro Mini (also ohne USB-Port) arbeiten können, schaffen auch den Bootloader hochzuladen. Platine muss aber schon bestückt werden, da nicht jeder NCN5120/TP-Uart2 löten kann.
• 3. Allround-"Experten", das sind praktisch wir, keine Angst vor Testen/Bricken/Löten usw.

Gruppe 1 wird von MDT, Gira usw. bedient, falls es nicht ausreicht, müssen die in Gruppe 2/ gehen (lernen, googlen)
Gruppe 2 können wir in Prinzip bedienen, aber wo kommen die fertigbestückte Platinen her?
Gruppe 3 macht alles um der Gruppe 2 das Leben leichter zu machen.

Und wenn jemand schon sich mir Pro Mini beschäftigt, dann hat er bestimmt Uno/Mega oder was ähnlich großes um Pro Mini zu flashen. Wenn nicht, dann kann man Flascher/2. Arduino für wenige Euros kaufen.

Ich hoffe ich habe jetzt keinen beleidigt.

[Ing-Dom]

FULL ACK Eugenius!

Ich hab Pro Mini, Nano und Leo clone aus China - soll ich noch testen?
Progger hab ich auch, aber noch nie benutzt

[tuxedo]

Weitere Tests schaden nix.
Hab heute Abend vielleicht sogar einen weiteren Testfall den man ausseinander nehmen muss:

Sobald ich auf dem Nano mit unserem KNX Stack "Serial.available()" aufrufe, bootet er neu.
Allerdings ist das der Optiboot-Loader mit falsch eingestelltem Größen-Fusebit ...

Wenn es mit der richtigen Fuse immer noch nicht passt, dann schau ich dass ich das in einen weiteren Testsketch gieße ...

[Eugenius]

so, wir müssen mit "meiner Lösung" aufpasen.
ich habe da nämlich was endeckt bzgl. internal clock was ich genutzt habe...
http://www.ladyada.net/learn/avr/fuses.html

Internal Clock means that theres a little oscillator inside the chip, its not very precise but good for most projects that dont have fine timing issues. The clock varies with temperature and the power supply voltage.

D.h. ich werde noch versuchen den Optiboot mit External Quarz zu nutzen.