standardisierte ablage von firmware files ?

Begonnen von justme1968, 01 Juni 2014, 18:50:27

Vorheriges Thema - Nächstes Thema

justme1968

HCS hat gerade in das jeelink modul die möglichkeit eingebaut direkt aus fhem heraus das flashen der firmware anzustossen (http://forum.fhem.de/index.php/topic,14786.msg173160.html#msg173160). im cul modul ist das schon möglich, bei homematic ist es gerade für das oha update der atkoren in arbeit und ich möchte den ota update für panstamp/swap einbauen.

wie wäre es mit einem standardisierten ablageort für die firmware (hex) files und einer namenskonvention um zu sehen zu welchem modul und für welche funktion das hex file ist?

sollte man das kommando zum anstossen des flashen selber auch vereinheitlichen?

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Ich habe CULflash gebaut, erst als Teil von autocreate (damit ungeflashte Module direkt beim FHEM-Start geflasht und eingebunden werden), spaeter wurde es in eine separate Datei ausgegliedert. update liefert die CUL*.hex Dateien aus, und speichert sie in fhem/FHEM.

Ich habe kein Problem mit einer Vereinheitlichung, viele Synergieeffekte sehe ich aber nicht, hoechstens wird es fuer Leute, die mehrere Systeme verwenden, sauberer. Eine Vorreiterrolle will ich nicht spielen, falls es eine Entscheidung gibt, werde ich CULflash & co nachziehen.

PeMue

Hallo zusammen,

was spricht dagegen, die hex-Dateien im Verzeichnis firmware abzulegen?
Ich würde mir dann folgende Nomenklatur vorstellen:
<Hardwarebezeichnung | Sketchbezeichnung>_<HWVersion>_<FW_Version>
z.B.
CUL_V3_V1.58.hex oder
PCA301_V1_V10i
Ggf. kann man über den Programmertyp rausbekommen, welche Hardware dranhängt, aber bestimmt habe ich auf die Schnelle nicht alles bedacht ...
Vielleicht gibt es dann für die Sketche auch (für mich) nachvollziehbarere Namen  ;)

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

justme1968

ja. so etwas hatte ich mir auch vorgestellt. eventuell noch den namen des fhem moduls das dafür zuständig ist.

das mit dem rausbekommen/auflisten/... ist aber eher die kür und kommt bestimmt erst wenn es wirklich viele anwender gibt.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

HCS

Ich würde dieses Thema gerne angehen, zumindest mal initial für den LaCrosse sketch.
Es gibt doch immer wieder Anwender, die mit dem Compilieren Probleme haben und nur mit Hilfestellung den JeeLink geflasht bekommen.
Aus dem bisher Diskutierten leite ich mal Folgendes ab:

Ablage der HEX-Files: im neuen (@rudolfkoenig: OK?) Verzeichnis firmware

nach dem Schema Hardwarebezeichnung_FirmwareName_Version

Beispiele:   
firmware/JeeLink_LaCrosse_V10.1d.hex
firmware/JeeLink_PCA301_x.y.hex

Im 36_JeeLink.pm würde ich set flash dann so anpassen:
   
set myJeeLink flash /myHexFiles/LaCrosse.hex
-> verwendet /myHexFiles/LaCrosse.hex

set myJeeLink flash <SketchName>
-> verwendet das HEX File in firmware, das mit JeeLink_ beginnt und danach mit <SketchName> weiter geht
Beispiele:
set myJeeLink flash LaCrosse
-> nimmt firmware/JeeLink_LaCrosse_V10.1d.hex

set myJeeLink flash PCA301
-> nimmt firmware/JeeLink_PCA301_x.y.hex


Kommentare / Vorschläge?

rudolfkoenig

Ich habe nichts gegen ein firmware Verzeichnis einzuwenden, aber die Versionierung sollten wir SVN ueberlassen. Das Einbinden ins update muss eine Woche noch warten, und jedes Unterverzeichnis muss von mir explizit eingetragen werden.

HCS

OK, dann wäre das Namensschema: Hardwarebezeichnung_FirmwareName

Ohne Version ist auch das Bilden angenehmer, da man nicht immer die Namen anpassen muss.

Beispiele:   
firmware/JeeLink_LaCrosse.hex
firmware/JeeLink_PCA301.hex
firmware/FHEMduino_default.hex


JoWiemann hat mich noch per PM (magels Schreíbrechten hier) angetriggert, ob man etwas universelles gemeinsames bauen könnte da er es in FHEMduino auch benötigt.
Zumindest für alles, was einen ATmega328 hat, sollte das ja universell machbar sein.

Hat jemand einen Überblick, was es außer JeeLink und FHEMduino noch an Hardware mit einem ATmega328 in FHEM gibt, das von dem Flash profitieren könnte?

Zitat von: rudolfkoenig am 27 Juli 2014, 22:09:18
Das Einbinden ins update muss eine Woche noch warten, und jedes Unterverzeichnis muss von mir explizit eingetragen werden.
Ja, das eilt ja nun auch nicht so sehr.

Ist nur ein Verzeichnis. In firmware sind ja keine weiteren Verzeichnisse vorgesehen?

justme1968

alles was sich per avrdude flashen lässt oder sich sollte direkt gehen. die konfiguration ist aber jetzt schon so flexibel das auch exotischere dinge gehen sollten. wie wäre es den flash teil in eine flash.pm auszulagern und dann in mehr als einem modul zu nutzen?

ich würde das verzeichnis  gerne auch für die panstamps nutzen. vermutlich aber erst mal mit extra anstecken und dann flashen. ota update muss ich erst noch einbauen.

die homebrew hm devices fallen mir noch ein. vielleicht gibt es dort auch Interesse den ablageort und das namensschema mit zu nutzen.

homematic selber hat firmware updates auch schon implementiert. vielleicht wäre ein allgemeiner ablageort hier auch interessant.

firmata könnte noch ein kandidat sein.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

HCS

Zitat von: justme1968 am 27 Juli 2014, 23:09:59wie wäre es den flash teil in eine flash.pm auszulagern und dann in mehr als einem modul zu nutzen?
Ja, genau das habe ich JoWiemann vor drei Minuten vorgeschlagen, um den "Kern" mit FHEMduino gemeinsam zu verwenden.

Zitat von: justme1968 am 27 Juli 2014, 23:09:59firmata könnte noch ein kandidat sein.
firmware oder firmata, ist mir beides gleich recht.

justme1968

ich meinte firmata module könnten auch ein kanditdat sein dort firmware abzulegen :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

HCS

Ah ...

das hatte ich ja ganz falsch verstanden  :) :)

HCS

Das neue Verzeichnis firmware soll parallel zu docs, FHEM, log, ... liegen?

rudolfkoenig


justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Ich habe jetzt:
- FHEM/firmware angelegt. CUL*.hex wird aber weiterhin direkt aus dem culfw SVN geladen.
- CULflash verallgemeinert. Ich werde es nach flash umbenennen (mit CULflash als alias), nachdem man mir die ersten Patches dazu geschickt hat.
- deusche Doku geschrieben.
- CULflash konsultiert nicht mehr controls_fhem.cfg, sondern laedt die Datei direkt von fhem.de herunter, letzteres war aber auch bisher der Fall. Die zum flashen heruntergeledanen Dateien werden in FHEM/firmware gespeichert. Sie werden als OK betrachtet, wenn sie ein  ":00000001FF" enthalten (Intel standard .hex File)
-  CUL*.hex wird nicht mehr per update ausgeliefert.