LaCrosseGateway mit miniCUL und 2.4" Nextion Display

[bitbiter]

Moin Moin.

Ich habe seit Tagen vom BME280 IMMER den gleichen Wert (1015). Dachte der Wert wäre dynamisch und würde sich je nach Wetterlage verändern?

Oder liege ich absolut falsch und alles ist OK?

Gruss
Alex

[HCS]

Ich habe seit Tagen vom BME280 IMMER den gleichen Wert (1015).

Ich nicht. Siehe Anhang.

[bitbiter]

Hallo HCS,

sieht aus als ob sich doch was tut an meinem BME280... minimal, aber es regt sich was :

Gruss
Alex

[bitbiter]

Einen guten Abend allerseits.

Nachdem ich meine 868er und 433er USB-CULs mit der WLAN-Lösung von Locutus ersetzte, kam es zu folgenden Änderungen mit meinen Messungen
der Revolt Dosen (siehe angehängte Screenshots)

Ich habe zig-Spitzen im Laufe des Tages, die bei dem USB-CUL nicht auftauchten... da waren die zwar auch da, aber rarer. Wenn ich das noch richtig in Erinnerung habe, wurde die culfw leicht für das LCGW geändert. Kann es dabei auch zu diesem Problem kommen, das bei mir aufgetaucht ist?

Oder bin ich der einzige in der Comunity der die Dinger überhaupt noch im Einsatz hat? 
(weil bisher wohl kein anderer ausser meiner Wenigkeit dieses "Phänomen" hat)

Gruss
Alex

[HCS]

Wenn ich das noch richtig in Erinnerung habe, wurde die culfw leicht für das LCGW geändert. Kann es dabei auch zu diesem Problem kommen, das bei mir aufgetaucht ist?

Ich wüsste jetzt keine Grund, warum für das LGW die CUL Firmware hätte geändert werden müssen.
Das LGW verlängert (bildlich gesprochen) den seriellen Port über das WiFi nach FHEM rein und interessiert sich in keiner Weise dafür, was in einem nanoCUL oder miniCUL passiert.

[bitbiter]

Hi HCS....

bin nochmal auf die Suche gegangen:

"Hinweis zu a-culfw ab V 1.21.00
Björn hat einige Änderungen an der a-culfw für miniCUL vorgenommen:"

Das war der Hinweis den ich meinte. Aber es gilt für den miniCUL.... (mea culpa!)
(Muss mir angewöhnen, immer EIN Projekt nach dem anderen durchzuführen...)

Wie ich schon sagte: Spitzenprodukt!! 

Gruss
Alex

[PeMue]

Hallo locutus,

ich habe jetzt ziemlich lange gesucht, aber nichts über die Einstellung einer Fuse für die "unlock bits" gefunden. Wo muss ich diese einstellen, wenn ich den Bootloader flashe?

Danke + Gruß

PeMue

Edit:
Und dann noch eine Frage: muss ein Atmega328P verwendet werden, oder reicht auch ein Atmega328?

[locutus]

Ich brenne den Bootloader sorglos mit der Arduino Software. Das Softwarepaket beinhaltet den Bootloder, die Fuses sind voreigestellt. Die Gefahr, den ATMEGA mit falsch eingestellten AVR Fuses zu zerstören, ist somit ausgeschlossen.
P (Pico-Power) ist in diesem Fall nicht relevant.

[PeMue]

Ich brenne den Bootloader sorglos mit der Arduino Software.
P (Pico-Power) ist in diesem Fall nicht relevant.

Habe ich probiert, aber beim Brennen mit der Arduino IDE kam folgende Fehlermeldung:

Code Auswählen Erweitern

Fehler beim Brennen des Bootloaders.
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9514 (probably m328)
avrdude: Expected signature for ATmega328P is 1E 95 0F
         Double check chip, or use -F to override this check.
Daher habe ich das ganze "von Hand" gemacht und es hat funktioniert (zumindest das Aufspielen).
Vermutlich müsste ich ein Board mit dem Atmega328 (ohne P) und 8 MHz definieren, dann würde das auch wieder funktionieren 

Gruß PeMue

Edit:
Jetzt bräuchte ich doch Hilfe:

Was ich gemacht habe:
- den Bootloader per USBtinyISP aufgespielt, die Fuses gesetzt, Auszug aus dem log

Code Auswählen Erweitern


Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x0F:
avrdude: load data lock data from input file 0x0F:
avrdude: input file 0x0F contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "ATmegaBOOT_atmega328_8MHz.hex"
avrdude: writing flash (32652 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 32652 bytes of flash written
avrdude: verifying flash memory against ATmegaBOOT_atmega328_8MHz.hex:
avrdude: load data flash data from input file ATmegaBOOT_atmega328_8MHz.hex:
avrdude: input file ATmegaBOOT_atmega328_8MHz.hex contains 32652 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: 32652 bytes of flash verified
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as DA
avrdude: safemode: efuse reads as 5
avrdude: safemode: Fuses OK (H:05, E:DA, L:FF)
- da ich den USBtinyISP dran hatte, habe ich auch gleich miniCUL_433MHZ.hex aufgespielt
- die beiden Lötbrücken auf der Unterseite geöffnet

Was funktioniert:
- ich habe das Modul per USBseriell Wandler an meinen Raspberry Pi angeschlossen und der miniCUL (als USB Variante) wird erkannt (die Version bzw. ccconf wird sauber ausgelesen, Funksignale werden noch nicht decodiert, weil die Antenne fehlt  )
- die LED blinkt im Sekundentakt, d.h. die Frequenz ist mit 8 MHz korrekt, Baudrate mit 38400 baud ist auch ok

Was nicht funktioniert:
Wenn ich jetzt versuche, die Firmware per USBseriell Wandler (3,3V, GND, TX, RX (gekreuzt) bzw. DTR an Reset) aufzuspielen, kommt folgende Fehlermeldung:

Code Auswählen Erweitern

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x01
Irgendwo ist noch etwas, was ich nicht bedacht habe 

Danke + Gruß

PeMue

[locutus]

Ja, die AVR Signature Bytes hatte ich außer Acht gelassen.
Du hast die miniCUL.hex per ISP übertragen und somit eventuell vorhandenen Bootloader überschrieben.

[PeMue]

So, jetzt habe ich es geschafft:
- von hier die Boarddefinition geladen https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard
- diese im Verzeichnis <arduino>\portable\sketchbook installiert und wie folgt geändert:

Code Auswählen Erweitern

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

atmega328bb.name=ATmega328 on a breadboard (8 MHz internal clock)

atmega328bb.upload.protocol=arduino
atmega328bb.upload.maximum_size=30720
atmega328bb.upload.speed=57600

# fuses for LGW carrier with CUL
# low fuses = 0xFF (bread board: 0xE2)
# high fuses = 0xDA
# extended fuses = 0x05
# fuse settings: int. 8 MHz, 65 ms startup, bodlevel 2.7 V
atmega328bb.bootloader.low_fuses=0xFF
atmega328bb.bootloader.high_fuses=0xDA
atmega328bb.bootloader.extended_fuses=0x05

atmega328bb.bootloader.file=atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex
atmega328bb.bootloader.unlock_bits=0x3F
atmega328bb.bootloader.lock_bits=0x0F

# change between atmega328 and atemga328p
atmega328bb.build.mcu=atmega328
atmega328bb.build.f_cpu=8000000L
atmega328bb.build.core=arduino:arduino
atmega328bb.build.variant=arduino:standard

atmega328bb.bootloader.tool=arduino:avrdude
atmega328bb.upload.tool=arduino:avrdude
Nach Ändern die IDE erneut starten  .

Rein technisch macht die Arduino IDE folgendes:
Fuses setzen:

Code Auswählen Erweitern

F:\software\arduino165\portable\packages\arduino\tools\avrdude\6.3.0-arduino6/bin/avrdude -CF:\software\arduino165\portable\packages\arduino\tools\avrdude\6.3.0-arduino6/etc/avrdude.conf -v -patmega328 -cusbtiny -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m
hier mit unlock bit 0x3F und
Bootloader brennen

Code Auswählen Erweitern

F:\software\arduino165\portable\packages\arduino\tools\avrdude\6.3.0-arduino6/bin/avrdude -CF:\software\arduino165\portable\packages\arduino\tools\avrdude\6.3.0-arduino6/etc/avrdude.conf -v -patmega328 -cusbtiny -Uflash:w:F:\software\arduino165\portable\sketchbook\hardware\breadboard\avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex:i -Ulock:w:0x0F:m
hier mit lock bit 0x0F.
Das erste Mal geht das Flashen per Bootloader, noch einmal flashen (auch mit DTR an Reset) geht irgendwie nicht 

Gruß PeMue

[locutus]

Fehlt der 100nF Kondensator zwischen DTR und Reset Pin? C1 im Schaltplan.

[PeMue]

C1 ist drin. Aber wenn ich seriell flashen will, kann das nicht funktionieren, weil ich auf den GPIO5 vom SC16IS750 keinen Zugriff habe. Und DTR direkt an Reset wird dann auch nicht funktionieren.

Gruß PeMue

[locutus]

In dem Fall wird logischerweise ein 100nF Kondensator zwischen ATMEGA Reset-Pin und serieller Adapter DTR-Pin geklemmt.
Für den SubProzessor am LGW gilt grundsätzlich Reset-Pin via 100nF Kondensator an GPIO5-Pin vom SC16IS750.

[PeMue]

Vorschlag für die nächste Layoutüberarbeitung:
Ein zusätzlicher Pin an J4 mit 100 nF gegen Reset (Beschriftung DTR), damit man auch per serieller Schnittstelle den Subprozessor flashen kann (zum Bootloader testen).

Danke + Gruß

PeMue

Edit:
Mit ein bisschen Nachdenken ginge da auch ein 100 nF Kondensator, der an den Reset Pin des Programmiersteckers gesteckt wird und wo dann DTR angeschlossen wird. Beim ersten Programmieren (nur Bootloader) funktioniert die Sache ja sowieso (habe ich heute gelernt  ).