Asksin_OTA_Bootloader für Mega2560?

Begonnen von Tobias, 04 August 2015, 13:54:35

Vorheriges Thema - Nächstes Thema

Tobias

Hi,
kann ich den Asksin_OTA_Bootloader auch für einen Mega2560 benutzen wenn dort final kein Homematik-Sketch läuft?
Was und wie muss ich im Makefile anpassen? Ggf noch weitere Änderungen?
# Settings for HM_LC_Sw1PBU_FM (Atmega644, 8k Bootloader size)
HM_LC_Sw1PBU_FM_8k: TARGET                    = HM_LC_Sw1PBU_FM
HM_LC_Sw1PBU_FM_8k: SUFFIX                    = _8k
HM_LC_Sw1PBU_FM_8k: MCU                       = atmega644
HM_LC_Sw1PBU_FM_8k: CODE_END                  = 0xDFFF
HM_LC_Sw1PBU_FM_8k: BOOTLOADER_PAGES          = 31
HM_LC_Sw1PBU_FM_8k: BOOTLOADER_UPDATE_START   = 0xFF00

HM_LC_Sw1PBU_FM_8k: BOOTLOADER_START          = 0xE000
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_START        = 0xFFF0
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_TYPE_START   = 0xFFF0
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_SERIAL_START = 0xFFF2
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_ID_START     = 0xFFFC
HM_LC_Sw1PBU_FM_8k: hex
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

frank

hallo tobias,

hier mal ein anfang. genaueres kann wohl nur dirk erklären, oder jan.

Zitatkann ich den Asksin_OTA_Bootloader auch für einen Mega2560 benutzen wenn dort final kein Homematik-Sketch läuft?
ich denke schon. der reine bootloader ist ja erstmal ein homematic device und funkt bidcos. wenn die fw drauf ist, bleibt der bootloader ja ungenutzt. eventuell wird es eng mit dem sendelimit, da immer der komplette speicher beschrieben wird. hat der mega nicht 256k? du könntest beim flashen des sw1pbu (64k) mit der alternativen fw mal testen wieviel load der vorgang benötigt und dann hochrechnen, ob das überhaupt funktionieren kann. andererseits kann man in den definitionen vielleicht auch eine andere grösse definieren.

ZitatWas und wie muss ich im Makefile anpassen?
dein beispiel ist für 64k von denen 8k bootloader sind. der bootloader belegt das ende vom flash. deine page grösse musst du im datenblatt schauen (512byte?), ebenfalls deine gewünschte bootloadergrösse. der 644 hat eine page mit 256 byte. die allerletzte page vom flash belegt der minibootloader, der bleibt immer erhalten bei ota. die letzten bytes belegen hmid, sn und modeltyp des bootloaders. so in etwa könntest du dir diese tabelle zusammen "basteln".

ich habe die adressen mal in reihenfolge angeordnet:

## code (fw) startet bei 0x0000. dann ergeben sich die adressen in steigender reihenfolge für sw1pbu 64k/8k

HM_LC_Sw1PBU_FM_8k: CODE_END                  = 0xDFFF (letztes byte der fw)
HM_LC_Sw1PBU_FM_8k: BOOTLOADER_START          = 0xE000 (erstes byte vom bootloader, hier 8k, 32 pages a 256 = 8192 bis ende)
HM_LC_Sw1PBU_FM_8k: BOOTLOADER_UPDATE_START   = 0xFF00 (minibootloader, letzte page)
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_START        = 0xFFF0 (start der 3 folgenden daten)
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_TYPE_START   = 0xFFF0 (modeltype 2 byte)
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_SERIAL_START = 0xFFF2 (sn 10 byte)
HM_LC_Sw1PBU_FM_8k: ADDRESS_DATA_ID_START     = 0xFFFC (hmid 3 byte)


ZitatGgf noch weitere Änderungen?
sicherlich noch eine header datei für den ordner devices erstellen.

gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

justme1968

tobias,

meine idee für die ota updates war eher in richtung swap und zum teil kompatibel zu den nrg  panstamps.

in etwa so: die firmware geht per broadcast raus. d. h. parallel an mehrer der boards. die boards arbeiteten während dessen ganz normal weiter und legen die firmware im nvram ab. die übertragung soll als deltas erfolgen. wenn ein knoten dann alle daten hat baut er die komplette firmware im nvram zusammen und flasht sich selber.

damit sollte sich das funk budget effizient nutzen lassen. zur not auch über eine längere zeit verteilt.

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

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

Dirk

Hi Andre,

die Idee ist ganz gut.

So wird es in Zukunft auch bei den HM-IP Devices gemacht.
Die übertragen die Firmware "häppchenweise" wenn grade eh nicht viel los ist.
Wenn die Firmware auf dem Gerät komplett angekommen ist melden die sich dann mit "Firmwareupdate steht bereit" o.ä.
Und dann kann man den Update auslösen.

Nvram muss das nicht mal sein. Wenn das Device eh ein externes Eeprom hat bzw. bekommen soll, kann man den auch etwas größer wählen und dort die Firmware "zwischenparken"

Viele Grüße
Dirk

justme1968

klar geht das auch mit einem eeprom. nvram deshalb weil es auf dem indoor board sowieso schon vorgesehen ist und noch für andere dinge verwendet wird.

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

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