AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

papa

Warum nicht ? Es wird hier der Fehler des Quarzes korrigiert. Der kann auch sehr weit daneben liegen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 08 Oktober 2019, 14:53:43
Warum nicht ? Es wird hier der Fehler des Quarzes korrigiert. Der kann auch sehr weit daneben liegen.

Schon klar.
Ich meinte nur das es keinen Grund für die Asymmetrie gegenüber der center Frequenz gibt.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

stan23

Zitat von: Tom Major am 08 Oktober 2019, 12:13:53
Besser wäre z.B. 62..69, das ergibt ca. 350kHz in beide Richtungen.
Ich vermute mal dass es dann doch wieder mehr Programm Memory braucht.

Tom Major

Habe mal einen PR gemacht für einen Vorschlag:
"Bessere symmetrische Grenzen für den CONFIG_FREQ1 check um die default HM Frequenz herum"
868,3MHz -550kHz/+567kHz
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: stan23 am 09 Oktober 2019, 09:22:41
Ich vermute mal dass es dann doch wieder mehr Programm Memory braucht.
nein, das ist mit dem aktuellen code Stand egal.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Zitat von: Tom Major am 09 Oktober 2019, 17:16:28
Habe mal einen PR gemacht für einen Vorschlag:
"Bessere symmetrische Grenzen für den CONFIG_FREQ1 check um die default HM Frequenz herum"
868,3MHz -550kHz/+567kHz
Warum wollen wir das unnötig weit einschränken ? Eigentlich reicht doch auch ein Test ungleich 0x00 && ungleich 0xFF.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 09 Oktober 2019, 20:00:28
Warum wollen wir das unnötig weit einschränken ? Eigentlich reicht doch auch ein Test ungleich 0x00 && ungleich 0xFF.

Hallo papa,
streng genommen hättest du die Frage gestern stellen sollen als Jerome den PR für die Einschränkung auf 0x6x gemacht hat und du akzeptiert hast.
Ich wollte heute nur die Asymmetrie des ranges von Jeromes PR korrigieren (für die es imho keinen Grund gibt) und auch gleich bei der Gelegenheit den Range des Frequenz checks dokumentieren.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

papa

Ich habe ja auch gefragt und bisher keine Zeit gehabt, alles bis zum Ende durchzudenken :-)
Wir wissen nicht, wie weit die Funkmodule im Einzelfall abweichen. Wenn der Testsketch eine funktionierende Frequenz raus kriegt und speichert, sollte diese auch genutzt werden. Es muss nur sichergestellt werden, dass der uninitialisierte Zustand erkannt wird. Das hatte ich falsch mit 0x00 gemacht. Der EEProm ist aber per default auf 0xff.
Vielleicht müsste man auch beim ersten Schreiben den gesamten Bereich "formatieren" - also auf einen definierten Zustand bringen. So wie es jetzt ist, könnte durch eine vorherige Anwendung schon Daten im EEProm stehen und das Schreiben der RebootFlags würde dann auch die Frequenz aktivieren und die Firmeware würde mit einem völlig unsinnigen Wert starten.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Tom Major

Zitat von: papa am 10 Oktober 2019, 07:21:47
Ich habe ja auch gefragt und bisher keine Zeit gehabt, alles bis zum Ende durchzudenken :-)
Wir wissen nicht, wie weit die Funkmodule im Einzelfall abweichen. Wenn der Testsketch eine funktionierende Frequenz raus kriegt und speichert, sollte diese auch genutzt werden. Es muss nur sichergestellt werden, dass der uninitialisierte Zustand erkannt wird. Das hatte ich falsch mit 0x00 gemacht. Der EEProm ist aber per default auf 0xff.
Vielleicht müsste man auch beim ersten Schreiben den gesamten Bereich "formatieren" - also auf einen definierten Zustand bringen. So wie es jetzt ist, könnte durch eine vorherige Anwendung schon Daten im EEProm stehen und das Schreiben der RebootFlags würde dann auch die Frequenz aktivieren und die Firmeware würde mit einem völlig unsinnigen Wert starten.

ja, mein Gedanke war auch das durch vorherige Belegung ein Wert ungleich FF drinsteht der aber trotzdem keine gültige Frequenz ist. Deswegen habe ich einen sauberen symmetrischen check um die default HM Frequenz vorgeschlagen. Ich hatte bisher nie mehr als 100 kHz Abweichung, imho sollten +-500 alles abdecken.

Oder man macht für Config area auch eine crc16 genau so wie für device data area, wäre man dann safe?
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Xent

Ich hab mich in letzter zeit etwas mit dem Thema OTA auseinander gesetzt und mir ist aufgefallen, dass sich der Bootloader selbst updaten könnte.

Ich hatte bei einem Aktor das Problem, dass beim OTA Flashen immer der CC1101 ausgestiegen ist und nichts mehr empfangen hat.
Ich hab darauf hin den Bootloader etwas angepasst und auch das Flash-Tool um eine Option zur Angabe der maximalen Versuche ergänzt.
Darauf hin konnte ich den Aktor immer wieder ohne Probleme flashen.

https://github.com/alexreinert/Asksin_OTA_Bootloader/pull/2
https://github.com/jp112sdl/hmcfgusb/pull/1

Jetzt habe ich schon eine RGB Gartenleuchte zusammengebaut, dort ist aber noch die alte Version des Bootloaders drauf.
Aus Bequemlichkeit und Interesse würde ich gerne dort auch den Bootloader aktualisieren ohne sie wieder auseinander zu nehmen.

Hat schonmal jemand soeine Firmware gebaut, wo auch der Bootloader aktualisiert wurde?


Xent

#1375
Habe mich jetzt mal weiter eingearbeitet.

Also damit man den Bootloader OTA aktualisieren kann, muss man ihn an die die Stelle 0x0000 Flashen und ein Magicword an Adresse 0x6FFC schreiben.
Dann liest der Bootloader den Flash von 0x0000 und überschreibt den aktuellen Bootloader ab 0x7000 mit 30 Pages a 128 Bytes

Aber eigentlich dürfte er doch nur 29 pages schreiben, da in der obersten Page also 0x7F00 der Code fürs Bootloaderupdate drin steht.

Danach muss man wieder die gewünschte Firmware OTA Flashen.

Habe mich auch mal an dem Makefile versucht.
https://github.com/Xento/Asksin_OTA_Bootloader/commit/09650a063225b644cffaa3853f6b005c7ee10b26

https://pastebin.com/7EH7msJE

Damit sollte der Flash wie benötigt aussehen.

papa

Wusste gar nicht, dass man den Bootloader selbst auch per OTA updaten kann.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Xent

Klar sollte das gehen.

Der Einsprung ist hier
https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/faf129629ee1bb8ee9bd6c3dc27fd60d5100d818/bootloader.c#L373

Und geflasht wird hier.
Wobei ich der Meinung bin, dass nur 29 Pages geschrieben werden dürfen, da er sonst de letzte Page wo der Flashcode drin sitzt, also 0x7F00, überschreibt.
https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/faf129629ee1bb8ee9bd6c3dc27fd60d5100d818/bootloader.c#L651

jp112sdl

Man darf dann bestimmt nicht die Lock Bit Fuse BLB1: SPM_DISABLE gesetzt haben

Tom Major

Zitat von: jp112sdl am 03 November 2019, 20:55:41
Man darf dann bestimmt nicht die Lock Bit Fuse BLB1: SPM_DISABLE gesetzt haben

Genau, das kam mir als erstes auch in den Sinn, ich setzte diese Fuse immer beim bootloader.

Außerdem muss der 'alte' bootloader dieses Feature bereits unterstützen.
Ein sauber programmierter bootloader ohne ein solches Feature schaut sich die Adressen/Pages an und flasht nur die die zur Application gehören.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker