Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

unimatrix · 21 August 2014, 13:42:32

Die Fuses sind doch in der README beschrieben? Was fehlt dir?

Tobias · 21 August 2014, 14:04:14

ich wollte nur wissen ob die fuses bei Nutzung eines MyAVR ISP Programmers identisch sind wie bei Raspberry GPIO Programmierung.
Ich denke mal "ja", aber will sicher gehen... Sorry, kenn mich da nicht so aus

Mr. P · 21 August 2014, 14:18:04

Die Fuses an sich sind gleich.
Es ändern sich nur die Parameter, damit avrdude weiß, womit er die Fuses setzt.

unimatrix · 21 August 2014, 14:18:56

ach so. ja. das ist natürlich das gleiche. Mit den Fuses werden im Controller bestimmte Optionen gesetzt, z.b. Prozessortakt usw.

Ohne alles aus dem Datenblatt suchen zu müssen kann man mit folgendem Onlinetool ganz schnell nachvollziehen, was welche Fuses bewirken.

http://www.engbedded.com/fusecalc/

frank · 21 August 2014, 20:49:42

eigentlich wollte ich gerade mal den neuen bootloader testen. ich habe nun aber zweifel, ob das funktionieren könnte.

1. ist es nun richtig, dass ich mit einem vorhandenen alten bootloader den neuen bootloader laden kann? oder kann erst ein nächster neuer bootloader mit dem jetzt neuen bootloader geladen werden?

2. sollte 1. zutreffen, also der aktuelle kann durch einen alten bootloader geladen werden, stellen sich die nächsten fragen. auf meinem schalter ist im augenblick der bootloader von jan von ca anfang mai (8k schätze ich mal). damals wurden die fuses wohl so gesetzt:

Code Auswählen

avrdude -p m644 -P usb -c usbasp -U lfuse:w:0xFD:m -U hfuse:w:0xD8:m

die neuen sehen ja etwas anders aus:

Code Auswählen

avrdude -p m644 -P usb -c usbasp -U lfuse:w:0xFD:m -U hfuse:w:0xDA:m -U lock:w:0x2F:m

also lfuse jeweils gleich. hfuse hat sich geändert. lockbits sind dazu gekommen.

2a. hat die geänderte hfuse mit der jetzigen bootloader grösse von nun 4k zu tun? müsste dann für den jetzigen 8k bootloader auch wieder hfuse=0xD8 sein?

2b. sind die lockbits eine sicherheitsmassnahme, so dass es auch ohne lockbits gehen würde? oder sind die zwingend nötig?

3. kann ein update meines bootloaders mit dem neuen über ota mit meinen fuse setttings funktionieren?

gruss frank

T.ihmann · 21 August 2014, 23:31:05

Zitat von: unimatrix am 21 August 2014, 12:24:25
Habe eine Version fertig, mit der sich der Bootloader selbst flashen kann. Das ganze ist noch im Teststadium und ich habe es nur auf dem 644a getestet.

Wer mit testen möchte, findet das ganze auf meinem Fork: https://github.com/unimatrix27/Asksin_OTA_Bootloader

Ihr verwirrt mich ...

Ist das jetzt die Version die in diesem Thread http://forum.fhem.de/index.php/topic,18071.msg193411.html#msg193411 erwähnt wurde. Heißt dies bei diesem Bootloader brauche ich gar nicht zu löten, sondern kann den Bootloader OTA flashen und dann OTA die Firmware ? Habe noch Schalter im Orginalzustand.

Eine andere kurze Frage: OTA flashen geht nur mit USB HM_CFG der geht auch ein CUL (den hätte ich nämlich...)

frank · 21 August 2014, 23:38:43

ZitatIhr verwirrt mich ... Ist das jetzt die Version die in diesem Thread http://forum.fhem.de/index.php/topic,18071.msg193411.html#msg193411 erwähnt wurde.

ja.

ZitatHeißt dies bei diesem Bootloader brauche ich gar nicht zu löten, sondern kann den Bootloader OTA flashen und dann OTA die Firmware ? Habe noch Schalter im Orginalzustand.

nein. einmal löten, fuses setzen und flashen. spätere bootloader updates per otau.

ZitatOTA flashen geht nur mit USB HM_CFG der geht auch ein CUL (den hätte ich nämlich...)

hmusb und cul.

Mr. P · 21 August 2014, 23:40:59

Und zur Zeit warten ein paar Leute ganz gespannt auf eine Response von frank's nicht ganz unwesentlichen Fragen.

unimatrix · 22 August 2014, 10:49:09

Hallo,

also zuerst: Der neue OTA-flashbare Bootloader ist in einem absolut experimentellen Stadium. Jeder der hier mit testet muss damit rechnen, ggf. wieder mit dem ISP ran zu müssen da das ganze sicher noch nicht 100% bugfrei ist.

Zu den Fragen:

Mit einem Bootloader vor der neuen Version von gestern kann man nicht OTA-Flashen. Um diese Funktion zu ermöglichen, muss zumindest "noch einmal" per ISP geflasht werden. Erst dieser neue Bootloader hat dann das Feature, zukünftige Updates per OTA anzunehmen (wahrscheinlich haben wir jetzt alles durch so dass keine neuen Updates mehr kommen haha)

Die Fuses von Jan sind ok bzw. die Änderungen betreffen nur die Bootloader-Größe (da kann man sich beim Schalter entscheiden, es ist letztlich egal, man kann einfach 8k nehmen, der Flash ist mehr als groß genug für alles was der Schalter je tun können wird). Die Lockbits darf man aber nicht setzen, wenn man die OTA-Updatefähigkeit haben will, ansonsten kann sich der Bootloader nicht selbst löschen. Hier muss man sich also entscheiden, ob man das möchte oder nicht. Im Grunde kann man die Lockbits verwenden, um sich das OTA-Feature zu aktivieren/deaktivieren. Die OTA-Funktion wird mit gesetzten Lockbits nicht funktionieren, alles andere in dem BL würde aber gehen.

Ja, die Fuseänderung betrifft nur die Größe und reduziert sie in dem Fall auf 4k

Es geht natürlich auch ganz ohne Lockbits, dann ist man potentiellen Bugs ausgesetzt (z.B gibts zurzeit keine Prüfung ob das OTA-IMage zu groß ist

Frank, deine letzte Frage beantwortet sich insofern. Deine Fuses sind ok, aber du kannst nicht OTA updaten ohne noch einmal zu flashen.

Hoffe das klärt das meiste

VG

Mr. P · 22 August 2014, 11:12:12

Zitat von: unimatrix am 22 August 2014, 10:49:09
also zuerst: Der neue OTA-flashbare Bootloader ist in einem absolut experimentellen Stadium. Jeder der hier mit testet muss damit rechnen, ggf. wieder mit dem ISP ran zu müssen da das ganze sicher noch nicht 100% bugfrei ist.

Ja... Sollte in der Tat klar sein.

Zitat von: unimatrix am 22 August 2014, 10:49:09
Mit einem Bootloader vor der neuen Version von gestern kann man nicht OTA-Flashen. Um diese Funktion zu ermöglichen, muss zumindest "noch einmal" per ISP geflasht werden. Erst dieser neue Bootloader hat dann das Feature, zukünftige Updates per OTA anzunehmen (wahrscheinlich haben wir jetzt alles durch so dass keine neuen Updates mehr kommen haha)

Also doch... Ist zwar schade, aber was sein muss, muss eben sein.

Danke für die Infos!

frank · 22 August 2014, 13:05:42

hallo unimatrix,

ZitatHoffe das klärt das meiste

ja, danke für die erklärungen.

da in deiner readme.md auch die möglichkeit zum flashen des 8k-bootloaders beschrieben wird, sollte dann auch das setzen der dann nötigen fuses beschrieben werden, denke ich. oder man setzt mit dem fuse-beispiel die bootloader-grösse generell auf 8k.

eventuell wären auch ein paar worte zum unterschied von 4k- und 8k-bootloader sinnvoll. nach meiner erinnerung dieses threads und des wettersensor threads sind die funktionen wohl identisch. nur die debug ausgabe ist "verstümmelt".

jetzt nochmal zu den lockbits:

ZitatDie Lockbits darf man aber nicht setzen, wenn man die OTA-Updatefähigkeit haben will, ansonsten kann sich der Bootloader nicht selbst löschen. Hier muss man sich also entscheiden, ob man das möchte oder nicht. Im Grunde kann man die Lockbits verwenden, um sich das OTA-Feature zu aktivieren/deaktivieren. Die OTA-Funktion wird mit gesetzten Lockbits nicht funktionieren, alles andere in dem BL würde aber gehen.

demnach würde das schöne, neue feature des bootloader-updates mit dem fuse beispiel aus der readme.md ja gar nicht funktionieren. das sollte man in der readme.md beschreiben, sonnst gibt es noch ärger, wenn mann später doch wieder löten muss, um die fuses zu ändern.

ZitatEs geht natürlich auch ganz ohne Lockbits, dann ist man potentiellen Bugs ausgesetzt (z.B gibts zurzeit keine Prüfung ob das OTA-IMage zu groß ist

aus beiden aussagen zusammen, entnehme ich, dass es auch eine nicht beschriebene lockbit einstellung geben könnte. also:

1. mit der beschriebenen fuse einstellung in der readme.md ist sowohl das ota-feature "disabled", als auch ein schutz vor potentiellen bugs etabliert. => vollschutz
2. ganz ohne lockbits ist das ota-feature "enabled" und kein "bug-schutz" vorhanden. => kein schutz
3. eine nicht beschriebene einstellung, die das ota-feature enabled und trotzdem einen "bug-schutz" ermöglicht. => bug-schutz
oder habe ich hier zu viel zwischen den zeilen gelesen?

könnte man das bootloader ota-feature folgenderweise testen:
1. deinen aktuellen bootloader über isp flashen.
2. einen alten bootloader dann über ota flashen.
dann müsste man zwar wieder löten, hätte die funktion aber getestet. richtig?

gruss frank

Dirk · 22 August 2014, 13:18:51

Zitat von: frank am 22 August 2014, 13:05:42
eventuell wären auch ein paar worte zum unterschied von 4k- und 8k-bootloader sinnvoll. nach meiner erinnerung dieses threads und des wettersensor threads sind die funktionen wohl identisch. nur die debug ausgabe ist "verstümmelt".

Aktuell gibt es gar keine Unterschiede. Die Debugausgaben sind auch nicht verstümmelt, da derzeit noch alles rein passt.
Für spätere Erweiterungen könnte es eng werden.
Wenn man also genug Platz hat dann ist es sicher nicht verkehrt den Bootloader in 8k zu packen.

Zitatdemnach würde das schöne, neue feature des bootloader-updates mit dem fuse beispiel aus der readme.md ja gar nicht funktionieren. das sollte man in der readme.md beschreiben, sonnst gibt es noch ärger, wenn mann später doch wieder löten muss, um die fuses zu ändern.

Die aktuell beschriebenen Lockbits schützen den Bootloader vor dem überschreiben. Wenn man den Bootloader updatebar machen möchte, darf man dieses Lockbis nicht setzen.
Man kann sich dann aber den Bootloader kaput machen. Dann müßte wieder der ISP her. Daher sollte man noch ein paar Checks einbauen.

Zitat2. ganz ohne lockbits ist das ota-feature "enabled" und kein "bug-schutz" vorhanden. => kein schutz

Ein "Bug-Schutz" können die Fusebitsnicht sein. Denn auch, wenn der Bootloader sich selbst vor z.B. überschreiben schützt, kann durch einen Bug des neu geflasthen Bootloaders dieser auch unbrauchbar werden. Auch dann muss der ISP wieder her.
Damit sowas nicht passiert, muss ein neuer Bootloader vorher gut getestet werden.

Zitatkönnte man das bootloader ota-feature folgenderweise testen:
1. deinen aktuellen bootloader über isp flashen.
2. einen alten bootloader dann über ota flashen.
dann müsste man zwar wieder löten, hätte die funktion aber getestet. richtig?

Oder 3. einen geänderten neuen Bootloader. Z.b andere Debugausgeben, zusätzliches LED-Blinken o.Ä

Gruß
Dirk

frank · 22 August 2014, 14:05:01

hallo dirk,

ZitatDie aktuell beschriebenen Lockbits schützen den Bootloader vor dem überschreiben. Wenn man den Bootloader updatebar machen möchte, darf man dieses Lockbis nicht setzen.

ok, danke. also 2 möglichkeiten. entweder lockbits wie beschrieben oder eben gar keine lockbits

gruss frank

mmattern · 22 August 2014, 23:52:30

Zitat von: Dirk am 14 August 2014, 23:08:06
Hallo Michael,

mein Fork mit letzten Version liegt hier:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader

Viele Grüße
Dirk

Hallo zusammen,

wow, hier ist ja einiges los... bin nicht eher dazu gekommen, aber jetzt ist der aktuell dort liegende Bootloader geflashed, Firmware mit CRC-Check OTA drauf...
Ich habe im Bootloader noch die "\n" durch "\n\r" ersetzt, sonst funktionieren bei mir die Zeilenumbrüche nicht (auf Raspberry Pi mit Minicom).

Funktioniert das OTA-Update nun auch schon aus FHEM heraus?

Viele Grüße
Michael

mmattern · 23 August 2014, 16:11:31

Hallo zusammen,

ich habe jetzt den neuen Bootloader in Verbindung mit der alternativen Firmware aufgespielt und folgendes Problem:
Es wird zwar im Reading "current" Stromfluss angezeigt, sobald der Stromkreis geschlossen ist (im Device auf Kanal 4), jedoch bleibt der Status auf "off", sofern er es vorher war... auch die Readings "level" und "pct" bleiben auf Null...

Hat jemand das schon mal korrekt zum Laufen gebracht? Ich werde als nächsten Schritt mal testen, die Firmware ohne Bootloader direkt zu flashen um zu sehen, ob der Bootloader "schuld" ist...

Viele Grüße
Michael