OTA Bootloader und Urflashen der Firmware
Moderator: Co-Administratoren
OTA Bootloader und Urflashen der Firmware
Hallo Zusammen,
aktuell habe ich eine Denkblockade. Es geht um bootloader und OTA-Flashen, aber vorher muss man noch was tun.
HW: Arduino Pro Mini
OK, ich habe verstanden und kann bzw. vorhandene Hardware:
- funktionierender USBASP (lass uns nicht von 5V - 3V3 reden
- aus asksinpp den den "Bootloader-OTA-atmega328.hex" über die "makeota.html" mit eigenen 10-Char Serial, 3-Hex Device-ID, (Config?)
erzeugen, als Ergebnis habe ich eine individuelle bootloader_ota_dev-id_serial.hex Datei
- das geht sicher auch mit "makeota.sh" unter Linux (auf raspberrymatic), ich verstehe SED und dir CRC Generierung, Ergebnis ist identisch.
- das Ganze mit "flash.sh" (also avrdude und usbasp unter windows) in den arduino brennen
- Am seriellen Monitor (jetzt usbasp abstecken und FTDI anstecken) sehe ich den Bootloader in freudiger Erwartung loopen
mit einer Textausgabe.
Step1: spezifischer Bootloader ist erzeugt und läuft im arduino, schon mal ein schöner Erfolg!
Meinen eigentlichen Sketch kann ich mit "define USE_OTA_BOOLOADER" übersetzen. Ich sehe, dass dann einige Variablen
aus dem Bootloader-Speicher gelesen werden, andere (z.B. Firmwareversion des SKETCHES) aus dem SKETCH.hex kommen.
die richtige SKETCH.hex finde ich auch.
Dann gibt es wohl zwei Varianten, aus der SKETCH.hex eine SKETCH.eq3 zu machen:
- "prepareforota.sh", welches die Konvertierung mit dem Windowsprogramm "srecord/srec_cat.exe" und danach (unter Linux mit php-cli)
den zweiten Schritt mit php macht, Ergebnis ist dann SKETCH.eq3, ist aber mit windows und php etwas holperig
- es gibt auch noch einen alternativen Weg mit "preota.sh", der nur mit Linux und ohne php das selbe Ergebnis erzielt: SKETCH.eq3
Erste Frage:
Ist es richtig, dass diese beiden Wege richtig sind, also das gleiche SKETCH.eq3 erzeugen?
Dabei ist "prepareota.sh" schnell, aber umständlich (Windows-binary und php-cli), das "preota.sh" langsam aber einfach linux?
Ok, also jetzt habe ich den Sketch in einer spezifischen firmwareversion, dann packe ich dies als "firmware.eq3" zusammen mit
einer Datei "changelog.txt" mit beliebigen (Changelog) Text und einer Datei "info" mit folgendem Inhalt:
TypeCode=61699 (das ist das DeviceModel, nicht die DeviceID! in DEZIMAL = 0xf1 0x03 HB-UNI-SENS)
Name=HB-UNI-Sens (Der Name des Gerätes, nicht zwingend Bestandteil der 10-Char Seriel)
CCUFirmwareVersionMin=2.27.0 (ok, das ist Info zur zur CCU-Version)
FirmwareVersion=1.1 (kleine Frage am Rande: MUSS das identisch mit der firmwareversion im Sketch sein? Ich vermute, nein, ist nur für GUI Anzeige)
zusammen in ein xxx.tar.gz Format (unter linux) und lade das in der Homematic-WEBGUI unter Einstellungen -> Geräte Firmware -> Neu
hoch und kann dann den neuen Eintrag in der GUI sehen.
Soweit so gut, jetzt kann ich mir das ganze schon vorstellen, wie es weitergeht ABER:
Zweite Frage:
Wie bekomme ich das allererste Mal die Firmware meines Sketches transportiert?
Ich las in diesem Forum (Seite 66...) "lässt sich gleich mitbrennen". Da komme ich aber nicht weiter.
Mit avrdude, dann aber das SKETCH.hex ohne die Wandlung ins .eq3-Format, das nur für zukünftige Updates?
Oder ein "flash-ota"??? Das zusammen mit externem HMUSB-Configurator? Habe ich nicht einen Sender in der CCU3?
Das erzeugen eines laufenden "flash-ota" ist mir auch noch nicht einfach verständlich....
Oder kann ich den IDENTISCHEN Sketch (aber ohne define USE_OTA_BOOTLOADER) vorher (vor dem OTA-Bootloader) flashen
und das HB-UNI-SENS-arduino-Teil schon mal an der CCU anlernen. Und DANN erst den OTA-Bootloader flashen und
und den IDENTISCHEN Sketch mit "define USE_OTA_BOOTLOADER" und einen erhöhten FIRMWAREVERSION
zusätzlich per OTA?
Also da hängt es bei mir ....
Hat jemand bitte eine Erleuchtung für mich?
Danke
Harvey
PS: gerne dokumentiere ich den Weg, damit er dann in die S_U_P_E_R_ Doku kann!
aktuell habe ich eine Denkblockade. Es geht um bootloader und OTA-Flashen, aber vorher muss man noch was tun.
HW: Arduino Pro Mini
OK, ich habe verstanden und kann bzw. vorhandene Hardware:
- funktionierender USBASP (lass uns nicht von 5V - 3V3 reden
- aus asksinpp den den "Bootloader-OTA-atmega328.hex" über die "makeota.html" mit eigenen 10-Char Serial, 3-Hex Device-ID, (Config?)
erzeugen, als Ergebnis habe ich eine individuelle bootloader_ota_dev-id_serial.hex Datei
- das geht sicher auch mit "makeota.sh" unter Linux (auf raspberrymatic), ich verstehe SED und dir CRC Generierung, Ergebnis ist identisch.
- das Ganze mit "flash.sh" (also avrdude und usbasp unter windows) in den arduino brennen
- Am seriellen Monitor (jetzt usbasp abstecken und FTDI anstecken) sehe ich den Bootloader in freudiger Erwartung loopen
mit einer Textausgabe.
Step1: spezifischer Bootloader ist erzeugt und läuft im arduino, schon mal ein schöner Erfolg!
Meinen eigentlichen Sketch kann ich mit "define USE_OTA_BOOLOADER" übersetzen. Ich sehe, dass dann einige Variablen
aus dem Bootloader-Speicher gelesen werden, andere (z.B. Firmwareversion des SKETCHES) aus dem SKETCH.hex kommen.
die richtige SKETCH.hex finde ich auch.
Dann gibt es wohl zwei Varianten, aus der SKETCH.hex eine SKETCH.eq3 zu machen:
- "prepareforota.sh", welches die Konvertierung mit dem Windowsprogramm "srecord/srec_cat.exe" und danach (unter Linux mit php-cli)
den zweiten Schritt mit php macht, Ergebnis ist dann SKETCH.eq3, ist aber mit windows und php etwas holperig
- es gibt auch noch einen alternativen Weg mit "preota.sh", der nur mit Linux und ohne php das selbe Ergebnis erzielt: SKETCH.eq3
Erste Frage:
Ist es richtig, dass diese beiden Wege richtig sind, also das gleiche SKETCH.eq3 erzeugen?
Dabei ist "prepareota.sh" schnell, aber umständlich (Windows-binary und php-cli), das "preota.sh" langsam aber einfach linux?
Ok, also jetzt habe ich den Sketch in einer spezifischen firmwareversion, dann packe ich dies als "firmware.eq3" zusammen mit
einer Datei "changelog.txt" mit beliebigen (Changelog) Text und einer Datei "info" mit folgendem Inhalt:
TypeCode=61699 (das ist das DeviceModel, nicht die DeviceID! in DEZIMAL = 0xf1 0x03 HB-UNI-SENS)
Name=HB-UNI-Sens (Der Name des Gerätes, nicht zwingend Bestandteil der 10-Char Seriel)
CCUFirmwareVersionMin=2.27.0 (ok, das ist Info zur zur CCU-Version)
FirmwareVersion=1.1 (kleine Frage am Rande: MUSS das identisch mit der firmwareversion im Sketch sein? Ich vermute, nein, ist nur für GUI Anzeige)
zusammen in ein xxx.tar.gz Format (unter linux) und lade das in der Homematic-WEBGUI unter Einstellungen -> Geräte Firmware -> Neu
hoch und kann dann den neuen Eintrag in der GUI sehen.
Soweit so gut, jetzt kann ich mir das ganze schon vorstellen, wie es weitergeht ABER:
Zweite Frage:
Wie bekomme ich das allererste Mal die Firmware meines Sketches transportiert?
Ich las in diesem Forum (Seite 66...) "lässt sich gleich mitbrennen". Da komme ich aber nicht weiter.
Mit avrdude, dann aber das SKETCH.hex ohne die Wandlung ins .eq3-Format, das nur für zukünftige Updates?
Oder ein "flash-ota"??? Das zusammen mit externem HMUSB-Configurator? Habe ich nicht einen Sender in der CCU3?
Das erzeugen eines laufenden "flash-ota" ist mir auch noch nicht einfach verständlich....
Oder kann ich den IDENTISCHEN Sketch (aber ohne define USE_OTA_BOOTLOADER) vorher (vor dem OTA-Bootloader) flashen
und das HB-UNI-SENS-arduino-Teil schon mal an der CCU anlernen. Und DANN erst den OTA-Bootloader flashen und
und den IDENTISCHEN Sketch mit "define USE_OTA_BOOTLOADER" und einen erhöhten FIRMWAREVERSION
zusätzlich per OTA?
Also da hängt es bei mir ....
Hat jemand bitte eine Erleuchtung für mich?
Danke
Harvey
PS: gerne dokumentiere ich den Weg, damit er dann in die S_U_P_E_R_ Doku kann!
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte
-
- Beiträge: 705
- Registriert: 22.05.2018, 10:23
- Hat sich bedankt: 24 Mal
- Danksagung erhalten: 120 Mal
Re: OTA Bootloader und Urflashen der Firmware
Wie Du das ganze für die CCU zusammen packen musst, kann ich wegen FHEM Nutzung nicht sagen. Aber zum initialen Flashen kannst Du das mit USE_OTA_BOOTLOADER erzeugte Hex in der makeota.html mit angegeben. Dann wird ein gemeinsames Hex - Anwendung und gepatcher Bootloader erzeugt. Dieses wird dann per ISP geflasht.
Siehe auch https://wiki.fhem.de/wiki/HomeMatic_Fen ... ty-Nachbau
prepareota.sh & preota.sh müssen den gleichen Output erzeugen. Das zweite kommt halt ohne die extra Windows-Programme aus und geht somit auf allen Platformen, die eine Bash ausführen können.
Siehe auch https://wiki.fhem.de/wiki/HomeMatic_Fen ... ty-Nachbau
prepareota.sh & preota.sh müssen den gleichen Output erzeugen. Das zweite kommt halt ohne die extra Windows-Programme aus und geht somit auf allen Platformen, die eine Bash ausführen können.
Anfragen zur AskSin++ werden nur im Forum beantwortet
Re: OTA Bootloader und Urflashen der Firmware
@ papa
vielen Dank für Deine schnelle Antwort.
Jetzt wird einiges klarer:
- Der Dateiinhalt des OTA-Bootloaders "Bootloader-OTA-atmega328p.hex" (und ...644.hex) ist bereits Bestandteil der "makeota.html".
- Es wird ZUSÄTZLICH die "firmware.hex" angehängt, also der Export aus dem Arduino-IDE
Die HEX-Dateien sind also nur zur Doku in dem Verzeichis enthalten, bzw. werden von den "makeota.sh" als Quelle
verwendet, wenn man NUR den bootloader generierien und flashen will.
Wunderbar. Also gemacht.
Aber dann im seriellen Monitor:
- es blinkt 6 mal schnell
- dann kommt der Text:
Also läuft etwas mit dem zusätzlichen Teil "firmware.hex" falsch???
An die "firmware.hex" bin ich so gekommen:
- in der arduino IDE -> Sketch -> Kompilierte Binardatei exportieren.
Es entstehen zwei Dateien: "<sketch>.ino.eightanaloginputs.hex" und "<sketch>.ino.with_bootloader.eightanaloginputs.hex".
Davon habe ich die erste (also ohne .with_bootloader.) in das "makeota.html" eingefügt.
Das Ergebnis dann entsprechend "flash.sh" gebrannt:
avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m
avrdude -p m328p -P usb -c usbasp -V -U flash:w:$BOOTLOADER
Als Sketch habe ich den HB-Uni-Sensor genommen, ist der zu groß für OTA???
Der Sketch verwendet 29186 Bytes (95%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 1360 Bytes (66%) des dynamischen Speichers, 688 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
Nehme ich einen anderen (modifizierter 8Temp-DS18x20) Sketch sieht das besser aus, also:
Irgendwie muss ich also noch die "zulässige" Sketchgröße beachten.
Ich arbeite mich so langsam ran, morgen geht es weiter. Vielen Dank für die Hilfe!
Jetzt bin ich zu müde.
ciao
Harvey
vielen Dank für Deine schnelle Antwort.
Jetzt wird einiges klarer:
- Der Dateiinhalt des OTA-Bootloaders "Bootloader-OTA-atmega328p.hex" (und ...644.hex) ist bereits Bestandteil der "makeota.html".
- Es wird ZUSÄTZLICH die "firmware.hex" angehängt, also der Export aus dem Arduino-IDE
Die HEX-Dateien sind also nur zur Doku in dem Verzeichis enthalten, bzw. werden von den "makeota.sh" als Quelle
verwendet, wenn man NUR den bootloader generierien und flashen will.
Wunderbar. Also gemacht.
Aber dann im seriellen Monitor:
- es blinkt 6 mal schnell
- dann kommt der Text:
Also der Bootloader arbeitet doch schon mal prächtig!!!AskSin OTA Bootloader V0.7.0
TX bootloader sequence
Wait for CB msg
Timeout
CRC fail, Reboot
Also läuft etwas mit dem zusätzlichen Teil "firmware.hex" falsch???
An die "firmware.hex" bin ich so gekommen:
- in der arduino IDE -> Sketch -> Kompilierte Binardatei exportieren.
Es entstehen zwei Dateien: "<sketch>.ino.eightanaloginputs.hex" und "<sketch>.ino.with_bootloader.eightanaloginputs.hex".
Davon habe ich die erste (also ohne .with_bootloader.) in das "makeota.html" eingefügt.
Das Ergebnis dann entsprechend "flash.sh" gebrannt:
avrdude -p m328p -P usb -c usbasp -B 10 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0xFF:m -U lock:w:0xFF:m
avrdude -p m328p -P usb -c usbasp -V -U flash:w:$BOOTLOADER
Hmmmm, wo liegt mein Fehler????C:\Program Files (x86)\Arduino\hardware\tools\avr\bin>avrdude -p m328p -P usb -c usbasp -V -U flash:w:HBUNISENS3.hex
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "HBUNISENS3.hex"
avrdude: input file HBUNISENS3.hex auto detected as Intel Hex
avrdude: writing flash (32768 bytes):
Writing | ################################################## | 100% 21.03s
avrdude: 32768 bytes of flash written
avrdude: safemode: Fuses OK (E:FF, H:D0, L:E2)
avrdude done. Thank you.
Als Sketch habe ich den HB-Uni-Sensor genommen, ist der zu groß für OTA???
Der Sketch verwendet 29186 Bytes (95%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 1360 Bytes (66%) des dynamischen Speichers, 688 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.
Nehme ich einen anderen (modifizierter 8Temp-DS18x20) Sketch sieht das besser aus, also:
Passt natürlich nicht vom DeviceModel (, hat aber keine CRC Fehler.AskSin OTA Bootloader V0.7.0
Start App
AskSin++ V3.1.2 (Jan 7 2019 23:47:05)
Address Space: 32 - 335
CC init1
CC Version: 14
- ready
Bat: 33
...
Irgendwie muss ich also noch die "zulässige" Sketchgröße beachten.
Ich arbeite mich so langsam ran, morgen geht es weiter. Vielen Dank für die Hilfe!
Jetzt bin ich zu müde.
ciao
Harvey
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte
-
- Beiträge: 705
- Registriert: 22.05.2018, 10:23
- Hat sich bedankt: 24 Mal
- Danksagung erhalten: 120 Mal
Re: OTA Bootloader und Urflashen der Firmware
Ja - ich denke das Image ist zu groß. Damit stimmt dann die Checksumme nicht und der Bootloader startet die Firmware nicht. Vielleicht sollte man da mal nen Check in den HTML-Code mit einbauen.
Der Bootloader für den 328P startet bei Adresse 0x7000 (28762). Direkt davor ist eine 2 Byte CRC Checksumme der Anwendung gespeichert. Damit bleiben 28760 Byte für die Anwendung.
Der Bootloader für den 328P startet bei Adresse 0x7000 (28762). Direkt davor ist eine 2 Byte CRC Checksumme der Anwendung gespeichert. Damit bleiben 28760 Byte für die Anwendung.
Anfragen zur AskSin++ werden nur im Forum beantwortet
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: OTA Bootloader und Urflashen der Firmware
Alternativ könnte man bei Verwendung der Arduino IDE auch schon in der boards.txt ein eigenes Board hinzufügen, damit beim Kompilieren eines zu großen Sketches ein Fehler ausgegeben wird:
Code: Alles auswählen
## ATmega328P (3.3V, 8 MHz) AskSinPP OTA
## ---------------------------------------------------
pro.menu.cpu.8MHzatmega328AskSinPPOTA=ATmega328P (3.3V, 8 MHz) AskSinPP OTA
pro.menu.cpu.8MHzatmega328AskSinPPOTA.upload.maximum_size=28760
pro.menu.cpu.8MHzatmega328AskSinPPOTA.upload.maximum_data_size=2048
pro.menu.cpu.8MHzatmega328AskSinPPOTA.upload.speed=57600
pro.menu.cpu.8MHzatmega328AskSinPPOTA.bootloader.low_fuses=0xE2
pro.menu.cpu.8MHzatmega328AskSinPPOTA.bootloader.high_fuses=0xD0
pro.menu.cpu.8MHzatmega328AskSinPPOTA.bootloader.extended_fuses=0xFF
pro.menu.cpu.8MHzatmega328AskSinPPOTA.bootloader.file=<Pfad zu>/Bootloader-OTA-atmega328.hex
pro.menu.cpu.8MHzatmega328AskSinPPOTA.build.mcu=atmega328p
pro.menu.cpu.8MHzatmega328AskSinPPOTA.build.f_cpu=8000000L
-
- Beiträge: 705
- Registriert: 22.05.2018, 10:23
- Hat sich bedankt: 24 Mal
- Danksagung erhalten: 120 Mal
Re: OTA Bootloader und Urflashen der Firmware
Der Bootloader muss aber vorher noch mit den Daten des Gerätes gepatched werden. Geht leider also nicht ganz so einfach.
Anfragen zur AskSin++ werden nur im Forum beantwortet
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: OTA Bootloader und Urflashen der Firmware
Ja das ist richtig.
Das kann das Shell-Skript machen und dann gehts weiter über Werkzeuge->Bootloader brennen.
Aber alles in einem Rutsch auf der Shell zu machen ist schon der schnellere Weg.
Das kann das Shell-Skript machen und dann gehts weiter über Werkzeuge->Bootloader brennen.
Aber alles in einem Rutsch auf der Shell zu machen ist schon der schnellere Weg.
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: OTA Bootloader und Urflashen der Firmware
...oder man bearbeitet die platform.txt dahingehend, dass bei "Bootloader brennen" statt avrdude ein Skript aufgerufen wird,
- das sich automatisch aus der übergebenen .ino die notwendigen Infos (Device Model, Device ID) grept
- die notwendige .hex generiert
- anschließend avrdude aufruft und alles auf den 328P schiebt
Wäre 1x Arbeit und man könnte es dann bequem über die IDE machen.
- das sich automatisch aus der übergebenen .ino die notwendigen Infos (Device Model, Device ID) grept
- die notwendige .hex generiert
- anschließend avrdude aufruft und alles auf den 328P schiebt
Wäre 1x Arbeit und man könnte es dann bequem über die IDE machen.
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: OTA Bootloader und Urflashen der Firmware
Die Firmware-Version im Sketch muss identisch sein mit der Firmware-Version in der 'info' Datei.
Beim Anlernen des Gerätes wird die Sketch-FW-Version der CCU mitgeteilt. Sieht man dann ja unter Einstellungen->Geräte.
Hast du nun eine neue Geräte-Firmware.tgz auf die CCU hochgeladen und die Firmware-Version in der 'info' unterscheidet sich von der Firmware-Version des Gerätes, wird dir ein "Update"-Button angeboten.
Anschließend kannst du das Update über diesen Button einfach anstoßen. Die Firmware wird übertragen und anschließend findet m.W. ein "Drüberlernen" statt -> Anlernen + Neuübertragen der Konfigurationsparameter. Dabei übermittelt das Gerät wiederum seine Firmware-Version (die ja aus dem Sketch mitkommt) an die CCU.
Ist diese nicht identisch mit der Versionangabe in der 'info' Datei, bekommst wieder den Update-Button eingeblendet.
Das wird eine Endlosschleife. Daher immer gut aufpassen, dass FW im Sketch mit FW in 'info' übereinstimmen.
Re: OTA Bootloader und Urflashen der Firmware
uiuiui, es geht voran!
das "makeota.sh" bekommt aktuell diese Werte übergeben:
usage: makeota.sh DEVMODEL HMID SERIAL [CONFIG]
CONFIG ist ja "future", aber diese Variablen sollten aus dem sketch.ino augelesen werden.
Grep alleine könnte problematisch sein, wenn diese Variablen (HMID, SERIAL) in eigene Datei
(siehe DeviceID.h in HB-UNI-SENSOR) ausgelagert sind, also nicht im sketch.ino enthalten sind.
Alternativ KÖNNTE man dies auch als sinnvolle Modifikation verstehen (so ist es sicher auch gedacht),
da damit eine Änderung der Device-Variablen für mehrere sonst gleiche Geräte und eine Änderung
des tatsächlichen Programms (im git und in der IDE) getrennt sind.
DEVMODEL gehört zum Programmcode, nicht zum individuellen Gerät: -> sketch.ino
CONFIG .... könnte ja eher zum individuellen Gerät gehören, also in DeviceID.h (wenn man diese Trennung
von Konfiguration eines Gerätes und Programmcode erstmal so hin nimmt)
Die Ideen zur boards.txt und plattform.txt finde ich super.
heute abend gehts weiter ...
ciao Harvey
PS: das mit den Firmwareversionen hatte ich mir schon so in die Richtung gedacht, nur noch nicht mit eigenen firmware.tar.gz
ausprobiert. Auch die könnte ja aus dem Sketch geparst werden und "prinzipiell" immer eine firmware.tar.gz erzeugt werden.
PS: @Jerome+papa: die berechnete Länge 0x7000 minus 2 Byte CRC ist 28670 Byte und nicht 28760 Byte, wie oben geschrieben ...
das "makeota.sh" bekommt aktuell diese Werte übergeben:
usage: makeota.sh DEVMODEL HMID SERIAL [CONFIG]
CONFIG ist ja "future", aber diese Variablen sollten aus dem sketch.ino augelesen werden.
Grep alleine könnte problematisch sein, wenn diese Variablen (HMID, SERIAL) in eigene Datei
(siehe DeviceID.h in HB-UNI-SENSOR) ausgelagert sind, also nicht im sketch.ino enthalten sind.
Alternativ KÖNNTE man dies auch als sinnvolle Modifikation verstehen (so ist es sicher auch gedacht),
da damit eine Änderung der Device-Variablen für mehrere sonst gleiche Geräte und eine Änderung
des tatsächlichen Programms (im git und in der IDE) getrennt sind.
DEVMODEL gehört zum Programmcode, nicht zum individuellen Gerät: -> sketch.ino
CONFIG .... könnte ja eher zum individuellen Gerät gehören, also in DeviceID.h (wenn man diese Trennung
von Konfiguration eines Gerätes und Programmcode erstmal so hin nimmt)
Die Ideen zur boards.txt und plattform.txt finde ich super.
heute abend gehts weiter ...
ciao Harvey
PS: das mit den Firmwareversionen hatte ich mir schon so in die Richtung gedacht, nur noch nicht mit eigenen firmware.tar.gz
ausprobiert. Auch die könnte ja aus dem Sketch geparst werden und "prinzipiell" immer eine firmware.tar.gz erzeugt werden.
PS: @Jerome+papa: die berechnete Länge 0x7000 minus 2 Byte CRC ist 28670 Byte und nicht 28760 Byte, wie oben geschrieben ...
Zuletzt geändert von harvey am 08.01.2019, 20:59, insgesamt 3-mal geändert.
Homematic raspberrymatic, iobroker, Asksinpp und Arduinos - rund 50 Geräte