KNX @ Arduino Pro Mini: WDT Problem

[tuxedo]

Jepp, solltest du. Der KNX Transceiver ist da etwas empfindlich was das Timing anbelangt. Ich werde nach Möglickeit den 8Mhz Typ komplett vermeiden und bei 16Mhz bleiben (und sobald das alles mal läuft, die Lib auf den ESP8266 und wenn Matsifi dran bleibt, auf den Arduino Zero portieren).

Btw: sogar in einem kleinen Tasterinterface findet man einen 20Mhz uC ...

[Eugenius]

Ich werde nach Möglickeit den 8Mhz Typ komplett vermeiden und bei 16Mhz bleiben

16Mhz=>.5V => nicht NCN5120 => Nicht gut.

Oder man muss unbedingt 2. DC-DC-Converter auf 5V einstellen und damit die 5V Version betreiben => Stromverbrauch ist dann auch höher, d.h. mann kann weniger Peripherie anschließen.
Ich war zwar selbst immer ein Fan von 5V/16Mhz, aber mit NCN5120 hat mich Masifi auf die 3,3V/8Mhz Version "überredet"

[Masifi]

Ja ich würde auch nur ungern meine 3,3V 8MHhz aufgeben, da Eugenius recht hat, der NCN5120 braucht immer schon allein 3,3V :-(

[Ing-Dom]

ich würde auch lieber bei 3,3 bleiben wollen - die meiste Peripherie läuft mit 3,3, da spart man sich die Levelshifterei..

Bei 8MHz muss ja nicht den internen Oszi benutzen, mein 8MHz Pro Mini hat nen 8MHz Quarz drauf..

[tuxedo]

Ich besteh ja nicht auf die 5V... Ich mag einfach nur mehr Mhz ;-)

Der ESP8266 hat auch 3,3V und 80Mhz (braucht ohne WLAN 15mA@3.3V --> http://bbs.espressif.com/viewtopic.php?t=133)
Der Zero ist ebenfalls 3,3V und hat 48Mhz (3.3V Zahlen hab ich nicht gefunden... nur 12V Daten: https://www.arduino.cc/en/Tutorial/A...werConsumption)

Ich denke früher oder später wird es für den Bastler auf eine Art ESP8266 hinaus laufen. Der ist klein, einfach zu löten (einfacher als der Zero, und es gibt ihn in klein zum stecken), schnell, schweine günstig und und und. Und hat noch WLAN an Board (was man abschalten kann wenn man's nicht braucht).

Für kleine Dinge, wo eine handvoll Kommunikationsobjekte ausreichen sind die 8Mhz noch ok. Aber - meine Meinung - für alles andere sollte man was größeres nehmen. Der Code des Stacks ist nicht soooo Mini... Hab den noch nicht ganz überblickt und geschaut ob man da was optimieren kann. Aber er ist jetzt schon darauf getrimmt/abgestimmt, dass die loop() Methode mit einer bestimmten Geschwindigkeit laufen MUSS, sonst klappt's mit KNX nicht mehr so zuverlässig.

Aber das sind schon wieder "kleine Glaubenskriege" (bzgl. "welche CPU ist die beste/richtige"). Erstmal schauen dass es läuft mit dem was wir haben, dann sehen wir weiter.

[Eugenius]

http://wiki.iteadstudio.com/ESP8266_Serial_WIFI_Module

• Vcc = 3.3V (needs around 300-400mA peak)

aber auch andere Werte sind nicht KNX fähig... 80Mhz muss man ja füttern


Zero ist da viel versprechender:
https://www.arduino.cc/en/Tutorial/A...werConsumption

[tuxedo]

Wer lesen kann ist klar im Vorteil: "Peak" !

Schau unter deinem Link (http://wiki.iteadstudio.com/ESP8266_..._WIFI_Module):
Electronic Characteristics --> 1.Current Consumption


Da sind die "realistischen Werte". Und meine Angaben waren "OHNE WLAN". Den Link bzgl. der Zugrundeliegenden Informationen stammt direkt vom Hersteller. Und der schreibt: 15mA im Modem-Sleep (=WLAN aus).


Deinen zweiten Link hatte ich bereits verlinkt.

[Masifi]

Also der Zero nimmt bei 3,3V/48Mhz 5mA auf, das kann keiner so schnell topen :-)

[tuxedo]

Also der Zero nimmt bei 3,3V/48Mhz 5mA auf, das kann keiner so schnell topen :-)

Natürlich ist der Niedrig. Aber in Sachen Lötbarkeit und Performance (CPU ist nicht alles. RAM und Flash sind fast noch wichtiger) und zugehörigem Strombedarf kann der ESP8266 dennoch punkten.
Und du sagtest ja selbst dass die Zero-Entwicklung nicht mehr so einfach ist wie mit dem herkömmlichen Arduino.

Wie gesagt... alles glaubenskriege. Konzentrieren wir uns auf "lauffähig machen" und sehen dann weiter.

[Eugenius]

den 2. Link gab es in dem original Post nicht und ich habe die Seite vor dem Antwort nicht aktualisiert

[Eugenius]

3,3V Pro Mini mit Extrenal Crystal 8Mhz

##############################################################
## Optiboot on 32pin (SMT) CPUs (Nano, Pro Micro, etc.)
##############################################################
optiboot32.name=Optiboot on 32-pin cpus (3.3V Pro Mini)
optiboot32.upload.tool=arduino:avrdude
optiboot32.upload.protocol=arduino
optiboot32.upload.speed=57600
optiboot32.upload.maximum_size=32256
optiboot32.upload.maximum_data_size=2048
optiboot32.bootloader.tool=arduino:avrdude
optiboot32.bootloader.unlock_bits=0x2F
optiboot32.bootloader.lock_bits=0x0F
optiboot32.bootloader.low_fuses=0xFD
optiboot32.bootloader.high_fuses=0xDE
optiboot32.bootloader.extended_fuses=0x05
optiboot32.bootloader.file=optiboot/optiboot_atmega328.hex
optiboot32.build.f_cpu=8000000L
optiboot32.build.board=AVR_UNO
optiboot32.build.core=arduino:arduino
optiboot32.build.variant=arduino:eightanaloginputs
optiboot32.build.mcu=atmega328p

Test läuft durch

[tuxedo]

den 2. Link gab es in dem original Post nicht und ich habe die Seite vor dem Antwort nicht aktualisiert

Stimmt, mir ist nach dem Absenden aufgefallen dass ein Link ganz nützlich wäre. Sorry für die Verwirrung.

Test läuft durch

Das sind gute Nachrichten. Wenn ich unseren Junior ins Bett gebracht habe prüf ich das bei mir...

[Eugenius]

So, jetzt auch mit Menü und 5V

##############################################################

prominiopti.name=Arduino Pro Mini Optiboot
prominiopti.upload.tool=arduino:avrdude
prominiopti.upload.protocol=arduino
prominiopti.upload.maximum_size=32256
prominiopti.upload.maximum_data_size=2048
prominiopti.bootloader.tool=arduino:avrdude
prominiopti.bootloader.unlock_bits=0x2F
prominiopti.bootloader.lock_bits=0x0F
prominiopti.bootloader.extended_fuses=0x05
prominiopti.bootloader.file=optiboot/optiboot_atmega328.hex
prominiopti.build.board=AVR_UNO
prominiopti.build.core=arduino:arduino
prominiopti.build.variant=arduino:eightanaloginputs
prominiopti.build.mcu=atmega328p

## Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega328
## -------------------------------------------------
prominiopti.menu.cpu.16MHz=ATmega328 (5V, 16 MHz)
prominiopti.menu.cpu.16MHz.upload.speed=115200
prominiopti.menu.cpu.16MHz.bootloader.low_fuses=0xFF
prominiopti.menu.cpu.16MHz.bootloader.high_fuses=0xDE
prominiopti.menu.cpu.16MHz.build.f_cpu=16000000L

## Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328
## --------------------------------------------------
prominiopti.menu.cpu.8MHz=ATmega328 (3.3V, 8 MHz)
prominiopti.menu.cpu.8MHz.upload.speed=57600
prominiopti.menu.cpu.8MHz.bootloader.low_fuses=0xFD
prominiopti.menu.cpu.8MHz.bootloader.high_fuses=0xDE
prominiopti.menu.cpu.8MHz.build.f_cpu=8000000L

[tuxedo]

Funktioniert auch mit dem Nano:

nanoopti.name=Arduino Nano Optiboot

nanoopti.upload.tool=avrdude
nanoopti.upload.protocol=arduino

nanoopti.bootloader.tool=avrdude
nanoopti.bootloader.unlock_bits=0x2F
nanoopti.bootloader.lock_bits=0x0F

nanoopti.build.f_cpu=16000000L
nanoopti.build.board=AVR_NANO
nanoopti.build.core=arduino
nanoopti.build.variant=eightanaloginputs

## Arduino Nano w/ ATmega328
## -------------------------
nanoopti.menu.cpu.atmega328=ATmega328

nanoopti.menu.cpu.atmega328.upload.maximum_size=32256
nanoopti.menu.cpu.atmega328.upload.maximum_data_size=2048
nanoopti.menu.cpu.atmega328.upload.speed=115200

nanoopti.menu.cpu.atmega328.bootloader.low_fuses=0xFF
nanoopti.menu.cpu.atmega328.bootloader.high_fuses=0xDE
nanoopti.menu.cpu.atmega328.bootloader.extended_fuses=0x05
nanoopti.menu.cpu.atmega328.bootloader.file=optiboot/optiboot_atmega328.hex

nanoopti.menu.cpu.atmega328.build.mcu=atmega328p

Jetzt teste ich mein Serial-Problem mit dem available() aufruf. ....

[tuxedo]

Hab mich vertan, will doch noch nicht... hmmpf.. *suchengeh*

[update]

Kann mir jemand verraten wo der fehler liegt? hab doch alles passend übernommen?!

[update]

da promini und nano eigtl gleich sind, hab ich mal Eugenius' Einstellung übernommen und damit dem BL geflashed. Ergebnis ist das Selbe-Forever-Boot-Loop nach dem ersten Durchlaufen. Kriegt sich nur durch einen power-cycle wieder ein.... *argh*