AVR Firmewareupdate über KNX

[andi11]

Ist es in Zukunft mal angedacht, dass man über KNX die Firmware von Geräten aktualisieren kann? Mir geht es im speziellen um AVR basierte Systeme.
Für den Bootloader ist ja doch relativ speicher abzweigbar im AVR, allerdings kollidiert das ggf. mit dem Update per USB.
Für I2C habe ich vor einigen Jahren mal einen erfolgreich geschrieben (Bascom aber das kann man übersetzen) und mit einbringen.

[tuxedo]

Angedacht ja, aber bis jetzt noch nicht genauer angeschaut. Zumindest nicht für die AVRs. Eines der größten Probleme ist der Speicherplatz: Wo lagerst du die Firmware zwischen bis sie mit dem nächsten Reboot zum Einsatz kommt? Den Kompletten KNX Stack willst du nicht unbedingt im Bootloader mitschleppen.

Für den ESP8266 ist das eigentich kein Thema. Platz ist da genug, und er bringt dafür auch gleich das passende Bootloader-Feature mit. Primär geht's da per WLAN, aber auch über KNX wäre kein großes Problem. Problem ist da viel eher die Größe der Firmware (beim ESP werkelt noch einiges mehr im Hintergrund, weswegen die Firmware da per se größer ist als bei den AVRs.

[andi11]

Ok dann schau ich mir mal an, ob man einen KNX Lite Stack in den AVR Bootloader Bereich packen kann (2048Words ist ja einiges). Ich hatte ursprünglich mit einem eigenen KNX Stack angefangen (KNX Anschaltung ohne NCN o.ä.) der hätte locker reingepasst, aber dann habe ich KONNEKTING gefunden.
Ansonsten wäre evl. eine Option auf den ISP Stecker einen SPI Flash Speicher zu stecken.

[tuxedo]

Eine andere Option: du baust den Bootloader so, dass von einem angeschlossenen Eeprom/Flash die Firmware in den AVR geschrieben wird. Dann könnte man bequem zur Laufzeit mit der Lib die Firmware entgegen nehmen, auf dem separaten Eeprom/Flash ablegen und beim nächsten reboot über den Bootloader einspielen.

Das würde das neu implementieren/abspecken ersparen und wir hatten nach wie vor eine einheitliche codebase.

[andi11]

Ja das war die Idee, wenn man einen zusätzlichen SPI Flash auf den ISP Stecker packt. Wenns nur ums abspecken geht würde ich mit Präprozessorbefehlen arbeiten, würde halt die Fummelei mit zusätzlicher Leiterplatte sparen.

[tuxedo]

Das mit der Platine ist kein Thema und eigentlich kein großes Ding. Soll ja auch in ein passendes Gehäuse etc.

Würde statt SPI lieber I2C nehmen. Denn für die meisten gebräuchlichen Anwendungen wird man so oder so auf I2C zurückgreifen:

PortExtender, PWM, Relaisansteuerung, ...

[andi11]

Ich dachte an SPI, da man damit quasi jedes vorhandene Board erweitern kann, da es sowieso meistens einen ISP Stecker gibt, und Hardware SPI im Bootloaderbereich einfach weniger Speicher braucht als Software I2C.

[tuxedo]

Jepp I2C ist ggf. etwas aufwendiger im Code, aber immer noch einfacher als KNX in den Bootloader zu quetschen.

Da meist der ProMini zum einsatz kommt, wäre der SPI Speicher an Pin D10, D11, D12 und D13 gebunden.

I2C wäre mit den Pins A4+A5 zum einen etwas "sparsamer" (nur 2 Pins statt 4), und zum anderen werden keine Digitalpins (welche man häufiger braucht als die Analogpins) benutzt. Vor allem wäre Pin D10+D11 noch ein PWM fähiger Pin die dann beide wegfallen, und Pin D13 hängt für gewöhnlich an der OnBoard LED die man als Status-LED dann auch vergessen kann.

I2C hingegen wird man wie gesagt sowieso für allerlei andere Dinge brauchen, womit man sich mit dem I2C Speicher wohl nichts "verbaut". Man müsste nur drauf achten, dass man einen Speicher nimmt der in der Adresswahl so gestaltbar ist, dass er mit anderen geläufigen I2C Komponenten nicht kollidiert und man so die I2C Adresse des Speichers für 99% der Fälle im Bootloader festschreiben kann und 99% der User daran auch nix ändern müssen.


Der häufig zum einsatz kommende ProMini hat übrigens kein ICSP Stecker... Den haben erst die Nanos und größere Arduinos.

[andi11]

Der häufig zum einsatz kommende ProMini hat übrigens kein ICSP Stecker... Den haben erst die Nanos und größere Arduinos.

Das erklärt warum du I2C favorisierst

[tuxedo]

Nein,d as erklärt es nicht, ist aber einer der Nebengründe... Der eigentliche Grund ist die Sache mit der Pin-Belegung durch SPI.

Hier arbeitet jemand übrigens an exakt diesem Szenario: externer I2C EEPROM und update des Sketches im Bootloader über diesen EEPROM:

http://forum.arduino.cc/index.php?topic=169988.0

[andi11]

Hab heute durch Zufall das hier entdeckt: http://www.rotwang.co.uk/projects/bootloader.html
Sieht ja schon sehr sehr vollständig aus, zumindest auf Bootloaderseite