Autor Thema: AskSin++ Library  (Gelesen 158501 mal)

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1583
Antw:AskSin++ Library
« Antwort #1365 am: 08 Oktober 2019, 14:53:43 »
Warum nicht ? Es wird hier der Fehler des Quarzes korrigiert. Der kann auch sehr weit daneben liegen.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 521
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1366 am: 08 Oktober 2019, 17:12:00 »
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.
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline stan23

  • New Member
  • *
  • Beiträge: 38
Antw:AskSin++ Library
« Antwort #1367 am: 09 Oktober 2019, 09:22:41 »
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.

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 521
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1368 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
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 521
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1369 am: 09 Oktober 2019, 17:17:19 »
Ich vermute mal dass es dann doch wieder mehr Programm Memory braucht.
nein, das ist mit dem aktuellen code Stand egal.
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1583
Antw:AskSin++ Library
« Antwort #1370 am: 09 Oktober 2019, 20:00: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

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 521
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1371 am: 09 Oktober 2019, 23:18:04 »
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.
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1583
Antw:AskSin++ Library
« Antwort #1372 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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 521
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1373 am: 10 Oktober 2019, 12:26:01 »
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?
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices

Offline Xent

  • Full Member
  • ***
  • Beiträge: 167
Antw:AskSin++ Library
« Antwort #1374 am: 03 November 2019, 16:01:27 »
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?


Offline Xent

  • Full Member
  • ***
  • Beiträge: 167
Antw:AskSin++ Library
« Antwort #1375 am: 03 November 2019, 19:33:32 »
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.
« Letzte Änderung: 03 November 2019, 19:43:40 von Xent »

Offline papa

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1583
Antw:AskSin++ Library
« Antwort #1376 am: 03 November 2019, 20:17:50 »
Wusste gar nicht, dass man den Bootloader selbst auch per OTA updaten kann.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Offline Xent

  • Full Member
  • ***
  • Beiträge: 167
Antw:AskSin++ Library
« Antwort #1377 am: 03 November 2019, 20:41:51 »
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

  • Gast
Antw:AskSin++ Library
« Antwort #1378 am: 03 November 2019, 20:55:41 »
Man darf dann bestimmt nicht die Lock Bit Fuse BLB1: SPM_DISABLE gesetzt haben

Offline Tom Major

  • Sr. Member
  • ****
  • Beiträge: 521
    • TomMajor@github
Antw:AskSin++ Library
« Antwort #1379 am: 03 November 2019, 22:57:03 »
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.
FHEM 5.x auf Raspberry Pi 3 | OWServer mit I2C/DS2482 | 1-Wire 6fach S0-Stromzähler ATtiny/DS2423 Emu. | Heizungs-Mon. mit Firmata (mighty-1284p) | Ölstand-Mon. mit Ultraschall, RFM69 und JeeLink
RaspberryMatic HM Zentrale | diverse HM Devices | AskSinPP Devices