standardisierte ablage von firmware files ?

HCS · 31 August 2014, 09:58:04

Ich habe jetzt die JeeLink_LaCrosse.hex in FHEM/firmware/ reingelegt.

@justme1968: machst Du die Anpassung in 36_JeeLink.pm oder soll ich da ran?
Meine Idee ist, dass man im 36_JeeLink ein Attribut mit der Auswahl der Firmware hat (LaCrosse, PCA301, ...)
Wenn man das gesetzt hat, dann ist für den "set flash" klar, was genommen werden muss:
./firmware/JeeLink_ + FirmwareName + .hex

Und da ich gerade gesehen habe, dass Du der maintainer für die PCA301 bist: könntest du die aktuelle JeeLink_PCA301.hex dazukippen?

justme1968 · 31 August 2014, 10:10:40

meine idee war die firmware Auswahl von der aktuell installierten firmware abhängig zu machen. d.h. per default immer die gleiche zu flashen und beim flash kommando anzugeben wenn es doch eine andere sein soll. ich glaube das ist unterm strich einfacher als ein extra attribut.

wenn du gerade zeit hast kannst du den neuen pfad gerne ein einbauen. ich komme vermutlich erst in ein paar tagen dazu.

den aktuellen pca sketch checke ich ein.

HCS · 31 August 2014, 10:35:20

Zitat von: justme1968 am 31 August 2014, 10:10:40
meine idee war die firmware Auswahl von der aktuell installierten firmware abhängig zu machen. d.h. per default immer die gleiche zu flashen und beim flash kommando anzugeben wenn es doch eine andere sein soll. ich glaube das ist unterm strich einfacher als ein extra attribut.

Ja, die Idee finde ich auch gut.
Dann wird es

Code Auswählen

set flash [FirmwareName]
FirmwareName optional LaCrosse, PCA301, ...
ohne FirmwareName angegeben:
wenn in model "LaCrosse" vorkommt, dann LaCrosse
wenn in model "pcaSerial" *1) vorkommt, dann PCA301

*1) stimmt das?

Zitat von: justme1968 am 31 August 2014, 10:10:40
wenn du gerade zeit hast kannst du den neuen pfad gerne ein einbauen. ich komme vermutlich erst in ein paar tagen dazu.

Es regent. Somit besteht eine Chance auf "Zeit haben"

justme1968 · 31 August 2014, 10:40:38

ja. genau. das war die idee.

pcaSerial stimmt auch.

hier (noch) nicht

gruss
andre

HCS · 31 August 2014, 21:18:11

Was ist denn der "offizielle" Weg, ein Attribut loszuwerden?

Wenn man es aus AttrList rausnimmt, gibt es ja beim nächsten Lesen der fhem.cfg eine Reklamation.

Code Auswählen

myJeeLink: unknown attribute hexFile. Type 'attr myJeeLink ?' for a detailed list.

justme1968 · 01 September 2014, 09:34:45

ich denke da gibt es keinen "offiziellen" weg. das einfachste ist die meldung zu ignroieren. beim nächsten mal ist sie ja weg.

du könntest eine version der attrFn bauen die das setzen ignoriert und das gesetzte attribut löscht und dann später in einem zweiten update das attribut entfernen. das hilft aber auch nicht wenn jemand das erste update übersprungen hat. ist also den aufwand eigentlich nicht wert....

gruss
andre

PeMue · 01 September 2014, 22:06:15

Zitat von: justme1968 am 31 August 2014, 10:40:38
pcaSerial stimmt auch.

Ich hätte den Sketch gerne pca301 genannt, da mich das serial irgendwie irritiert. Allerdings geht wohl ein pca301.c, pca301.h und ein pca301.ino nicht. Daher heißt es jetzt wieder pca301serial. Warum der Sketch dann auch noch genau im gleich benamten Verzeichnis liegen soll, ist mir schleierhaft (http://www.smiliecenter.de/smilies/nachdenkliche/nachdenkliche_smilies_0004.gif) ...

Gruß PeMue

justme1968 · 01 September 2014, 22:16:00

mir würde pca301.hex auch besser gefallen.

schau mal ob du pca301.ino in sketch.ino umbenennen kannst. mit dem ino tool würde das gehen. ich weiss aber nicht ob die ide damit klar kommt.

selbst wenn beim kompilieren nicht automatisch ein pca301.hex raus kommt spricht je nichts gegen umbenennen vor dem einchecken.

gruss
andre

HCS · 01 September 2014, 22:39:12

pca301.ino, pca301lib.cpp und pca301lib.h
geht.

Dann kann's (oder muss

) auch wieder ein pca301 Verzeichnis sein.

Die Arduino IDE ist der absolute Supergau.

Tip: Wer vernünftig arbeiten will und ein VisualStudio hat, kann sich mal VisualMicro anschauen.
Mit IntelliSense, SVN Integration und allem, was VS halt so zu bieten hat.

justme1968 · 02 September 2014, 11:16:09

die arduino ide ist wirklich ein krampf. das ino tool macht es was die projekt organisation angeht schon deutlich besser. leider nicht mehr ganz so platform unabhängig. und genau das ist das k.o. kriterium für visual studio

das gibt es nur unter windows und sogar dort ist das kompilieren auf kommandozeile schon nicht mehr optimal.

einer der wirklichen gründe von problemen mit der arduino ide ist aber eigentlich das verwenden der dort vorgesehen lib und include mechnismen und ino files. wenn man den teil komplett aussen vor lässt und die 'normale' standard c/c++ include und deklarations mechnissmen verwendet hat man hier deutlich weniger probleme und das ganze ist auch noch portabler.

gruss
andre

HCS · 02 September 2014, 11:56:13

Das firmware-Verzeichnis ist beim FHEM-Update leider nicht mitgekommen

rudolfkoenig · 02 September 2014, 12:21:30

Stimmt, ich habe die firmware Dateien aus dem update control File ganz entfernt. Sie werden aber weiterhin auf http://fhem.de/fhemupdate/FHEM/firmware/ hochgeladen.

Ich habe sie rausgenommen, da:
- CULflash die .hex Datei von der Webseite laedt. Die frueher im update vorhandene Datei wurde schon immer ignoriert. Und wenn es nie verwendet wird, wozu per update verteilen.
- CULFlash laedt die Version von der Webseite, weil es auch beim ersten FHEM-Start durch "usb create" getriggert wird (um die angesteckten Geraete zu flashen), und da is noch kein FHEM-update gelaufen.
- Wenn ein CUL schon einmal geflasht ist, dann wird nicht mehr automatisch geflasht, deswegen wollte ich die neueste Version haben.

Ja, man koennte es auch anders machen, sehe aber z.Zt noch nicht, wieso.

HCS · 02 September 2014, 12:29:40

Der Sketch, der auf den JeeLink geflasht ist und die 36_JeeLink.pm (jetzt mal die beiden als Beispiel genommen) sollten ja zusammenpassen.
Ist es da nicht eher ungeschickt, wenn zu einer evtl. nicht aktuellen 36_JeeLink.pm (weil lange kein Update gemacht) die aktuellste Version vom Sketch genommen wird?
Wenn das Update den Sketch mitnimmt, dann hätte man die "Pärchen"immer zusammenpassend.

justme1968 · 02 September 2014, 12:39:58

die idee hinter den firmware verzeichniss war es anwendern die nicht selber kompilieren wollen oder damit probleme haben an einer stelle automatische aktuelle versionen bereitzustellen die dann auch direkt aus fhem heraus geflashed werden können. das ist besonders für die arduino/jeeljnk/panstamp basierten dinge bei denen mehr wie eine firmware gibt und sich auch mehr oder weniger oft änderungen oder ergänzungen ergeben vielleicht wichtiger als beim cul.

wenn die firmware files nicht automatisch im update verteilt werden können wir auch beim contrib/arduino verzeichniss bleiben. mit gebau den bisherigen nachteilen.

das konzept eines zentralen verzeichnisses an dem hoffentlich noch weitere module teil nehmen (siehe oben für mögliche kandidaten) ist für normale endanwender nur dann praktikabel wenn es einfach und automatisch funktioniert.

wenn du angst hast das zu viel daten unnötig verteilt werden könnte ein parameter oder eine option um das firmware verzeichniss zu aktivieren/deaktivieren helfen.

aber ich denke das der vorteil aktuelle daten zu verteilen die paar k bei weitem aufwiegt.

rudolfkoenig · 03 September 2014, 09:57:41

Habe die im SVN befindlichen FHEM/firmware/.* Dateien zum update hinzugefuegt, danach fhemupdate.pl durchgefuehrt und update getestet:

Zitat2014-09-03 09:52:31 Global global UPD FHEM/firmware/JeeLink_LaCrosse.hex

Da die CUL*.hex Dateien aus einem anderen Verzeichnis spaeter hinzugefuegt werden, sind diese nicht im update enthalten, was aber fuer mich kein Bug sondern Feature ist.