embedded Update konzepte

[Stefan (Gast)]

Hallo!

ich bin gerade am recherchieren für meine Bachelorarbeit, bei welcher es 
darum geht einen Überblick über verschiedene Update-Konzepte, 
Bibliotheken und Tools für Embedded Systems zu geben.

Da ich über Dr. Google nur mäßig Informationen erhalte, wollte ich 
wissen, ob jemand aus dem Umfeld schon erfahrungen sammeln hat können!

Eine der möglichkeiten ist das Updaten des Programmcodes über den 
Bootloader. Dabei stellt sich mir trotzdem die Frage, ob es nicht so auf 
die Art 0815 Schemen gibt, an die man sich halten kann um sein eigenes 
Update-System zu entwickeln.

Weitere Fragen wären z.B.
- welche Möglichkeiten gibt es, ein Update anzustoßen?
- sind incrementelle Updates möglich? Bzw. ja, sind sie - nur wie ist 
bei der Implementierung vorzugehen?
- Wie kann sichergestellt werden, ob das Update erfolgreich war bzw. das 
System in den Ausgangszustand (vor Update) zurückzusetzen wenn ein 
Fehler auftritt (unterbrochene Versorgung während Update)


Seit kurzem ist das .Net Microframework 4.2 verfügbar. Lt. Releasenote 
soll es 'Remote Firmware Updates' unterstützen. Hat hier schon jemand 
erste Erfahrungen sammeln können?


Ich wäre sehr dankbar für ein paar Anregungen und vlt. auch eigene 
Erfahrungen!

Vielen Dank im vorraus,
Stefan

[Stefan (Gast)]

Hab was vergessen:

Sagt jemandem das Stichwort 'Ginseng' etwas?
-> http://www.cs.umd.edu/projects/PL/dsu/software.shtml

viele grüße

[♪Geist (Gast)]

@ Stefan: sag mir bitte wo dieser Schrott im Embedded Bereich eingesetzt 
wird?

Weitere Fragen wären z.B.
- welche Möglichkeiten gibt es, ein Update anzustoßen?
- sind incrementelle Updates möglich? Bzw. ja, sind sie - nur wie ist
bei der Implementierung vorzugehen?
- Wie kann sichergestellt werden, ob das Update erfolgreich war bzw. das
System in den Ausgangszustand (vor Update) zurückzusetzen wenn ein
Fehler auftritt (unterbrochene Versorgung während Update)


Hier ist ein gewöhnlicher (recht sicherer) Ablauf:

- Zum Hex File eine Header Datei bilden, und die Infos
- Code in einen Speicher downloaden (SPI Flash etc.)
- Flag "neue Firmware verfügbar" im gleich Speicher setzten (falls 
erfolgreich)
- uC mittels Watchdog abstürzen lassen
- im Bootloader Modus prüfen ob Flag "neue Firmware verfügbar" gesetzt 
ist, Flag löschen und mit dem Update beginnen.
- Update erfolgreich (CRC o.ä.) -> zum Programmcode springen, wenn nein 
aus dem SPI Speicher die letzte funktionierende Version lesen und den uC 
flashen.

[Stefan (Gast)]

♪Geist schrieb:
> - Update erfolgreich (CRC o.ä.) -> zum Programmcode springen, wenn nein
> aus dem SPI Speicher die letzte funktionierende Version lesen und den uC
> flashen.

das setzt aber vorraus, dass ich den doppelten Speicher brauche, was ja 
bekanntermaßen in embedded systemen eher eine deutliche Einschränkung 
darstellt.

um deine Frage zu beantworten:
diesen 'Schrott' kann man sehr wohl auch in diesem Bereich brauchen. Hat 
man z.B. die Möglichkeit, partielle Updates zu fahren, belastet man den 
Speicher nicht mit unnötigen Überschreibeoperationen, das Update dauert 
wesentlich kürzer... nur ein paar Punkte.

Aber vielen Dank für deine rasche Antwort! und deinen Ablauf! :)

thx