mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR "Fernprogrammieren"


Autor: Kaktus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

Habe da ein AVR Projekt anstehen wo es praktisch wäre wenn ich den AVR
( Mega8 oder 16) fernprogrammieren könnte. Es handelt sich um eine neue
Steuerung für ein Amateurfunk 2m Relais. Der Standort des Relais ist
schlecht erreichbar und aus Erfahrung weiss ich das man immer bei der
Entwicklung eine Menge Fehler in sowas einbaut die sich dann erst in
der echten Umgebung zeigen.

Jetzt hatte ich mal so den Gedanken den AVR bei Bedarf über Funk ( z.B.
Packet Radio) neu Programmieren zu können.

Evtl. benutzt man ein externes EEprom das von einem 2ten AVR, der an
dem Packet Radio Modem dranhängt, beschrieben wird.
Evtl wäre es auch mit einem Handy möglich.
Internetanschluss besteht leider nicht.

Wie habt ihr für Ideen oder Erfahrungen????

Autor: David Epping (it-web)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, warum so umständlich, die ATmega Serie kann doch den eigenen
Programmspeicher schreiben. musst also deinen programmspeicher
großgenug wählen und dann in zwei teiel aufteilen. Einen, der dein
übertragungsprotokoll versteht und den zweiten teil mit dem code
erneuert, und diesen dann zur ausführung bringt. um in den
programmiermodus zu kommen, muss entweder der hauptprogrammcode den
aufruf starten, was aber unsicher funktioniert, wenn der code nicht
sauber läut, oder du musst irgendein anderes ereigniss haben, so dass
die updatefunktion gestartet wird.

Autor: Kaktus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das heißt ich müsste sowas wie einen Bootloader schreiben, der immer
funktioniert und auch nicht überschrieben werden kann, und die serielle
schnittstelle vom Modem überwacht auf updates. Das update dann an eine
bestimmte stelle ins eeprom schreibt usw. bloss wie sag ich dem AVR das
er das neue Programm dann mit ausführen soll?


Deshalb der Gedanke mit 2 AVR's:

Einer bekommt ein kleines Monitor Programm für die RS232. Mit diesem
Programm kann man sich dann über die Ferne "unterhalten". man kann
dann ein update starten, der 2. AVR wird dann über MISO MOSI SCK
programmiert
.

Wie das dann auschaut hab ich noch keine Ahnung

Autor: thkais (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus dem EEPROM kannst Du sowieso nichts ausführen. Mit einem Bootloader
kannst Du in den FLASH schreiben. Üblicherweise funktioniert das so:
Der Bootloader ist ein eigenständiges Programm, das in einem besonderen
Bereich des Speichers untergebracht wird (siehe Datenblatt). Er kann nun
per Reset ausgelöst oder direkt aus dem "normalen" Programm aufgerufen
werden. Dann wird das neue Programm übertragen (das alte wird
augenblicklich überschrieben), und wenn alles fertig ist und auch die
Prüfsummen gepasst haben, startet der Bootloader mit einem "jmp
$0000" das neue Programm. Ist absolut kein Hexenwerk, man kann den
Code im Datenblatt -mit Ausnahme des Übertragungsprotokolls- fast
komplett aus dem Datenblatt abschreiben.

Deine Lösung geht natürlich auch - ist aber aufwändiger.

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

update über funk schwebt mir auch schon ne weile im kopf rum...
nur giebt es ja da noch ein par unklarheiten.....

1. der rechner muss auf komando reagieren  ein update zu emfangen ?

2. der funk kann abreissen  das heist er muss dann ganz normal
weiterarbeiten  (denke timeout ?)

3. er muss prüfen ob die daten volständig und richtig sind ?

4. dan programmiert er sich selbst (das geht ja mit normalen bootlader
auch)

5. das heist das das programm 2x in speicher passen muss ?

6. das neue programm ist io.  er arbeitet wieder ganz normal weiter

7. nun kommts ...das programm fährt gegen baum ?
ermus durch wachhund wieder in den empfangsmodus gehen und auf sein
besseres programm warten ?

das waren meine überlegungen dazu ....hm... mega 32 ?
bräuchte ev. noch nen sram ?

...nun welche erkenntnisse giebt es dazu ?

73 !

Autor: Kaktus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dau-xxl
es ist alle richtig was du schreibst.

Deswegen gleich mein Gedanke an 2 AVR'rs

Einer der immer über das Modem ansprechbar ist und den anderen
programmiert.
Das neue Programm muss ja auch noch zwischengespeichert werden, und
kann  bestimmt nicht häppchenweise über den bootloader eingeladen
werden.

Es soll natürlich nicht komplizierter sein als notwendig. Wenn alles
sicher mit einem geht wär mir das auch recht.

Wie funktioniert das mit dem Bootloader genau?

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

@Kaktus

eigentlich gans einfach ... ein bootlader (kleines progamm am ende des
speicherbereiches laden )

ich habe mir da kein kopf gemacht und nen fertiges programm
megaload  findest du auch hier im forum ...orginal ..
hier
http://www.microsyl.com/megaload/megaload.html

laufen alle meine megas mit ..mann spart sich das progammierdongle
und schikkt alle per 232 in den chip

die ist bei mir ehh überall dranne ...

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ps

nur für funk taugt das  nicht ...

Autor: Kaktus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn man dem Modem (TNC) nach dem Verbindungsaufbau an dieses Programm
hängt müsste es doch gehen, oder? Es ist halt ekein fullduplex...

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm..

die gesicherte datenverbindung über tnc würde schon einiges
vereinfachen

aber ich wollte eigentlich kein tnc dafür opfern ?
un ne 2. mcu für das tnc und datenprotokoll wollte ich eigentlich auch
nicht verwenden

na mal sehen ob noch wer hier ne idee dazu hat ??

73!

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Kaktus,

genauso einen Bootloader habe ich im Auftrag geschrieben für eine
Firma, die Sympathien hat für den Amateurfunk.

Die Anforderungen an den Bootloader waren:
* Betrieb an ziemlich unzugänglichen Orten, beispielsweise auf hohen
Antennenmasten mit vogeldreckbekleckerten Sprossenleitern, mit dickem
Eis überzogen.
* Keine separate Link für den Bootloader. Das heißt, die Firmware muß
mit einem speziellen Kommando den Bootloader aufrufen.
* Muß auch bei Unterbrechung des Bootvorgangs erneut bootbar sein.
* Muß auch nach Laden einer irrigen Firmware erneut bootbar sein.
(Angenommen, die neue Firmware kann alles, bloß den Aufruf des
Bootloaders nicht mehr. Soll sich deswegen einer durch den Vogeldreck
quälen müssen?)

Was ich im Auftrag geschrieben und teuer verkauft habe, das kann ich
nicht abgeben, weil es mir nicht gehört.

Aber schreib mich erst per Email an, tauschen wir die Adressen aus,
dann schreib einen Brief mit offiziellem Kopf Deines Ortsvereins, und
ich werde ihn meinem Auftraggeber vorlegen.

Ciao
Wolfgang Horn

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wolfgang

welchen avr verwendest du dabei ?
geht das seriell über modem ?
wie gross ist bootlader selber ?
brauchst du externen ram dafür ?


jürgen

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Jürgen,

AVR?: Atmega128
Über Modem?: Komplizierter, spezielles Protokoll RS-485 halbduplex.
Zwar nicht für Funkanwendung gedacht, aber leicht machbar.
Größe: circa 8 kByte, kompiliert mit WinAVR
externes RAM: nicht notwendig, weil der Bootloader Intel-Hex-Files
liest und decodiert.

In der Investitionsgüterindustrie mit den geringen Stückzahlen pro
Projekt bezahlt man für den Prozessor lieber 3€ mehr und spart dafür
3k€ an Entwicklungskosten.

Ciao
Wolfgang Horn

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Wolfgang

hätt ich mir beinahe gedacht
ist ja eigentlich kaum ein unterschied preislich
 ...nur das mann einen mega32 noch auf ner lochrasterplatte bekommt
aber zb. für eine ablaufsteuerung an einem atv-umsetzer
sind bei 32mb-8mb wohl noch genug platz .. ?

aber du must doch erst mal das programm ablegen bis zur crc-prüfung ?
bevor du das alte programm überschreibst ?
bei funk kann mann doch nicht gleich das alte programm überbügeln ?
wer die verbindung gestört wird ist doch dann länger alles tot

jürgen

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Jürgen,

"Programm ablegen bis zur crc-Prüfung"? Wäre eine Alternative. Die
gewählte Alternative: Jeden Intel-Hex-Record prüfen, und nach dem
Brennen einer Bootpage deren Ergebnis prüfen.

"bei funk kann mann doch nicht gleich das alte programm überbügeln ?"
Bei diesem RS-485-halbduplex-Protokoll und der mehrfachen Absicherung
bis hin zum "Überbügeln" einer denkbar kaputten Firmware glauben wir,
dies "Überbügeln" vertreten zu können.

"die verbindung gestört wird..." Logisch, das erneute Bootloading
darf man erst starten, wenn die Verbindung wieder steht.

Ciao
Wolfgang Horn

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei unseren Geräten ist nach dem Power On Reset erstmal der Bootloader
aktiv und lauscht auf ein Schlüsselwort.
Dieser Bootloader kann nicht überschrieben werden und somit ist das
Ganze bombensicher gegen Fehlprogrammierung.

Kann man aber nicht einfach so einen Reset machen, braucht man
unbedingt einen 2.MC, der entweder den Reset auslöst oder gleich den
Bootloader beinhaltet.


Peter

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo peter

ja das ist eigentlich soweit klar
und ein botlader geht wohl auch controlermässig zu schützen ?

das bootladen nach einem kaltstart ist ja eigentlich üblich
wie zum beispiel bei vielen stb's
aber es giebt z.b.  auch welche die am seriellen port auf ein kommando
zum download reagieren

2. controler ist ev. doch wohl einfacher...
der kann die funkseite überwachen und das programm auf volständigkeit
überprüfen
und im positiven falle dann die eigenliche mcu resetten und download
starten

aber dann wird alles wieder grösser :-((

...muss ich wohl doch weiterhin mit nen schlepptopf aufen turm klettern
um neue soft aufzududeln ....rrrr

jürgen

Autor: Winne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja
ich denke mal berühmter Köter dochauch den Bootlader/Reset aufrufen ?

damit wäre doch ein externer Reset unnötig der reset des köters sollte
nur komplizertgenug erfolgen , als das das hauptprogramm auch sciher
laüft , oder der Bootlader aktiv ist.............

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm einen i2c epprom.. wenn ein neues prog empfangen wird kommt das da
rein... ist der crc ok startest springst du zu deinem
programmer-code... der ist primitiv weil er sich nur die bytes aus dem
eeprom holen muss und flashen tut...

das sollte auf jedem avr gehn der sich selbst programmieren kann und
den eeprom kannst du ja noch für was anderes verwenden... z.b als
mailbox am relais ;)

"online" flashen (also ohne zuerst alles zu empfangen und zu prüfen)
halte ich für zu gefährlich.. wenn da einer dein signal überpiepst ists
aus mit dem relais...

ein 32k ode 64k eeprom kostet mehr oder weniger nix.. dein
"loader"-code wird schön klein und ganz nebenbei sollte damit das
problem mit der datenübertragung auch weg sein...

73

Autor: Werner B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man das eeprom gross genug macht kann man dort auch die "alte"
Programmversion als Backup halten.

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

>* Muß auch nach Laden einer irrigen Firmware erneut bootbar sein.
>(Angenommen, die neue Firmware kann alles, bloß den Aufruf des
>Bootloaders nicht mehr.

Wie soll das bitte gehen? Ich sehe keine Möglichkeit dass eine
Firmware, die den Bootloader nicht (mehr) aufrufen kann, genau das
macht ;)
Jetzt mal im Ernst: Hat jemand einen Tipp für mich wie man sowas
realisieren kann? Weil ich überlege ein µC über Infrarot zu brennen, da
kommt mir sowas recht.

>Soll sich deswegen einer durch den Vogeldreck quälen müssen?)
Ich glaube genau das wird notwendig werden ;)

Feadi

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Feadi:

>>* Muß auch nach Laden einer irrigen Firmware erneut bootbar sein.
>>(Angenommen, die neue Firmware kann alles, bloß den Aufruf des
>>Bootloaders nicht mehr.

>Wie soll das bitte gehen? Ich sehe keine Möglichkeit dass eine
>Firmware, die den Bootloader nicht (mehr) aufrufen kann, genau das
>macht ;)

Das kann man doch aber vorher testen, bevor man die Firmware in
Richtung Vogeldreck sendet. Wenn der Test nicht gründlich war, dann ja,
muss einer durch den Vogeldreck ;)

Das einzige Problem das auftreten kann ist, dass bei der Übertragung
was schief läuft und der Flash zerschossen wird. Dann sollte aber der
Watchdog einsetzten und den Bootloader wieder starten.

Bei einer stark gestörten Verbindung kann es natürlich sein das sich
das mehrmals wiederholt. Da der Bootloader aber immer wieder einsetzt,
sollte der AVR nach jedem Reset versuchen eine neue Firmware zu laden
bis er erfolgreich ist.

Günter

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

ich seh das Problem noch nicht. Man setzt die Fusebits so das der
Bootloader bei einem Reset immer angesprungen wird. Der Bootloader
prüft nun ob eine bestimmte Bedingung zutrifft und verzweigt bei
nichtzutreffen in das Hauptprogramm. Vorher prüft er die Applikation
jedoch auf Korrektheit. D.h. der Bootloader berechnet einen Hashwert
(z.B. http://de.wikipedia.org/wiki/MD2) das gesamte Flash und prüft
diesen gegen einen ebenfalls im Flash abgelegten Wert. Sind sie
identisch springt der Bootloader endgültig ins Hauptprogramm. Ansonsten
verzweigt er in den Ladecode. Da kann im Prinzip nichts schiefgehen wenn
man die Fusebits richtig setzt.

Matthias

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, Freunde des Bootladens,

"Probezeit für die Firmware" ist der Trick, eine programmierte, aber
fehlerhafte Firmware zu hindern, ein erneutes Bootladen zu verhindern.

Klartext: Die neue Firmware wird erst getestet, und nach erfolgreichem
Abschluß des Testens dann wird im Eeprom ein Flag gesetzt, das der
Bootloader nach jedem Power-On-Reset abfragt und das Kommando dann an
die Firmware abgibt.
Und wenn der Test nicht erfolgreich war, dann wird das Flag eben nicht
gesetzt, und nach dem Power-On-Reset behält der Bootloader das
Kommando.

@Peter: Wenn wir das Gerät mit der Firmware darin auf dem Tisch stehen
haben, dann ist es ein Leichtes, notfalls den Netzstecker zu ziehen,
wieder einzustecken und nach Power-On-Reset den Bootloader noch zu
erwischen.
Wenn das Gerät aber auf einem Antennenmast steht, und die
Stromversorgung wegen anderer Verbraucher nicht abgeschaltet werden
darf, dann ist das komplizierter.

Ciao
Wolfgang Horn

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
ich merke schon das ist nichts für anfänger
dabei habe ich folgende probleme...

1. die steuerung steht schwer zugänglich auf einem antennenturm

2. die möglichkeit giebt es über TNC (ax25-modem) und 70cm-funk
   fernsteuervorgänge und parameter auszulösen

3. die soft erfüllt erst mal die notwendigsten aufgaben

4. nun muss der controller ja laufend auf ein schlüsselwort
   hören um festzustellen ob eine neue software-variante vorliegt ?

5. dann könnte ich mir vorstellen das der controller dann
   in (meinetwegen Z-modem-modus geht ) die datei zwischenspeichert
   und bei korrektheit anfängt sich neu zu programmieren ?

6. bei irgendwelchen groben fehlern wieder neu in die upload
   -rutine gehen

7. obwohl die steuerung eigentlich nicht gross ist und sonnst
   der mega16 dicke reicht  bräuchte ich sicher externen ram ?

8. oder das programm im mega128 zwischenspeichern ?

9. nächstes was ich nicht weis ....? geht das bootsegment
   vor selbst-überbrennen zu schützen ?

.....

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolfgang

"Wenn das Gerät aber auf einem Antennenmast steht, und die
Stromversorgung wegen anderer Verbraucher nicht abgeschaltet werden
darf, dann ist das komplizierter."


Genau deshalb würde ich die Variante mit einem 2.AVR nehmen, der immer
mitlauscht ob das Bootloaderschlüsselwort reinkommt, kostet ja nix.

Der kann dann sogar feststellen, ob der zu programmierende AVR den
RX-Pin blockiert (als Ausgang schaltet) und ihn dann zwangsweise
resetten.


Peter

Autor: doss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist möglich den Bootloader Flashbereich zu schützen. Es geht über die
Fuse bits. Der Bootloader ist normalerweise so geschrieben, dass er sich
nicht selbst überschreibt, sondern nur das Anwendungsprogramm. Die
Software kann in den Bootloader per Reset in den Bootloder springen.
Oder ein Pointer of Function springt in den Bootloader.
Sehr guter Bootloader ist der Bootloader im Evertool.

http://www.siwawi.arubi.uni-kl.de/avr_projects/eve...

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo peter ...

also nun hast du mich überzeugt für einen 2. controller
es ist auch einfacher die programmteile zu trennen

1. also ich stelle mir nun ein mega128 vor
   (watt solls ist genug platz drinne )  ?

2. im normalfalle hängt der nur so rum und schiebt daten von seriell
    1 nach 2 und umgedreht  übernimmt ev noch das funkprotokoll ?

3. und er wartet dabei noch auf ein schlüsselwort auf der
   funkseite  ein neues update zu empfangen und zu prüfen ?

4. war dieses nun komplett könnte er den spi-anschluss seines
   masters neu zu programmieren ?

5. dieses programmteil giebst doch schon irgendwo
   als modul für avr  ?

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll den der Hauptcontroller die ganze Zeit lang machen ?

Immerhin bei 16Mhz hast du 16 Millionen Operationen pro Sekunde und ich
schätze mal das der Hauptcontroller nur wenig zu tuen bekommt.

Also wäre es eine Verschwendung und eine weitere Fehlerquelle im Design
das mit 2 Controller machen zu wollen wenn es zeitlich für den
Hauptcontroller überhaupt kein Akt darstellt noch nebenbei am Modem zu
lauschen.

Nur mal so als Denkansatz: Wo könnten im Board mehr Probleme auftreten
? Während der Kommunikation vom Modem über Controller 2 hin zu
Controller 1 oder aber während der Kommunikation vom Modem in Controler
1 zum Programieren des Controller 1.

Ich meine wenn der Hauptcontroller genügend Zeit hat dann sollte er
sich selber flashen. Das dürfte wesentlich stabiler sein als über eine
externe Programmierung.

Gruß Hagen

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo hagen

na sicher ist auch der hauptcontroler die meiste zeit gelangweilt
 aber fürn anfänger ist es leichter die programme auseinander zu halten
?

somit währe der 2.controller eigentlich ein über ax25-funk
gelinkter isp-programmer

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen,

der 2. AVR deswegen, damit er nicht versehentlich lahmzulegen ist.

Wenn Du nur einen AVR hast und da versehentlich ein Programm
reinbrätst, das nicht mehr den Bootloader aufrufen kann, dann wars
das.


Peter

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@peter

>Wenn Du nur einen AVR hast und da versehentlich ein Programm
>reinbrätst, das nicht mehr den Bootloader aufrufen kann, dann wars
>das.

Warum das denn? Wenn der Bootloader vor dem Sprung in die Applikation
prüft ob diese korrekt geladen wurde (wie z.B. mit dem von mir
genannten Hash-Wert) dann kann da nichts schiefgehen. Wenn natürlich
der Hashwert zufällig gleich ist dann hat man ein Problem. Dieser Fall
ist aber äußerst unwahrscheinlich.

Matthias

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und dieser Fall lässt sich mit mathematisch berechenbarer
Wahrscheinlichkeit auf eine praktisch niemals eintreffende
Wahrscheinlichkeit reduzieren.

Dazu einfach zb. 16 Bytes Zufall in den Code integrieren und als
Prüfsumme mit CRC32 oder CRC64 arbeiten.

Ich meine das die Stabilität diese Updateprozesses innerhalb einer CPU
weit höher ist als mit 2 CPUs. Die Softwareanfälligkeit steigt meiner
Erfahrung nach mit der Anzahl der CPUs.

Die Sichtweise ob es nun ein "Anfänger" oder "Profi" ist halte ich
für irrelevant.

In beiden Fällen muß ein Bootloader geschrieben werden, in beiden
Fällen muß 1 oder 2 MCUs programmiert werden, in beiden Fällen muß 1
oder 2 Boards gelayoutet werden.

Der Unterschied dabei ist das mit 1 MCU sehr viel externe und damit
auch anfällige Logik bei 2 MCUs in diese eine MCU verlagert wird.

Ich sehe es wie Matthias.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gäbe EINE Außnahme, das muß ich zugeben,

Man baut ohne große SW Tests das Ding aufm Mast auf, und fängt dann an
ferngesteuert die Software ordentlich zu entwickeln. Also das was man
bei der Entwicklungsphase bequem zu Hause macht wird gleich live am
Sendemast durchgeführt. Jo, dann kann so ein Fall eintreten.

Gruß Hagen

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Wolfgang:

> "Probezeit für die Firmware" ist der Trick, eine programmierte,
aber
> fehlerhafte Firmware zu hindern, ein erneutes Bootladen zu
verhindern.

Wie soll denn so ein Test aussehen?

Natürlich muss die Firmware vorher gründlich getestet werden. Aber die
Erfahrung zeigt ja, dass da sich doch immer noch was einschleicht. Mir
ist nicht klar wie der Bootloader das abfangen kann?

Der super GAU währe doch wenn der AVR immer noch weitestgehend richtig
funktioniert, nie den Watchdog auslöst, aber nicht mehr mit der
Außenwelt kommuniziert.

Das einzig sinnvolle scheint mir zu sein, den Bootloader mit in die
Kommunikation zur Außenwelt zu schalten. Als Notbremse könnten man dann
immer noch von außen ein Kommando senden um eine neue Firmware zu
laden.

Gruß Günter

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Passwort: "Vogeldreck"

Wenn der AVR zwar noch seinen Dienst verrichtet, aber nicht mehr
Aussenwelt kommuniziert, dann ist er wohl doch nicht mehr in der Lage
seinen Dienst zu verrichten...
Wenn man die Software vernünftig plant, dann sollte der Fall entweder
nie eintreten.
Den Watchdog in einer Endlosschleife zu reseten ist nicht wirklich
sinnreich...
Als Sicherheit könnte man es so auslegen, dass der Bootloader das
Programm in einem externen EEPROM zwischenspeichert, und man exakt die
gleiche Datei erneut überträgt, wobei der Bootloader die empfangenen
Daten mit denen im EEPROM vergleicht, und das Controller-Programm erst
nach einem erfolgreichen Doppelempfang ins Flash schreibt.
Im Falle, dass das Ding seinen Dienst wirklich versagt, gilt halt das
Passwort "Vogeldreck"...
Man könnte auch gleich ein Terminal-Programm schreiben, das dann mit
dem Programmierer kommuniziert. Ich weiß allerdings nicht, was soeine
Relais-Station macht bzw. wie sie das macht, wofür sie vorgesehen
ist...

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
die aufgaben der steuerung selbst ist dagegen trivial
eigentlich werden dort nur eingänge von verschiedenen
empfänger überwacht und mit bestimmte ausgänge eine schaltfolge
angestossen ..der zustand dann über seriel über tonkanal rückgemeldet

nur die schaltfolgen und möglichkeiten ändern sich des öfteren
so das dann ein neues programm vor ort geladen wurde (bootlader)

was machmal bis zu ein monat einschränkung oder ausfall der anlage
bedeutet (bis man alle berechtigten und schlüssel zusammen hat )

Autor: Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn sich die Schaltfolgen, also eigentlich nur Parameter ändern, kann
man das auch über das EEPROM machen.
Das Programm muß einfach nur quasi ein Programm aus dem "hauseigenen"
EEPROM ablaufen lassen.
Das kann man vermutlich mit einem Struct-Array erschlagen.
Das vermutlich das gleiche, als würde man einem (perfekten) Musiker ein
anderes Notenblatt vorsetzen, dass er dann einfach nachspielt (deswegen
perfekt...).
In meinen Augen fällt die Aufgabe unter anfängertauglich (oder auch
Pippifax)...

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>nur die schaltfolgen und möglichkeiten ändern sich des öfteren
>>so das dann ein neues programm vor ort geladen wurde (bootlader)

Ah,  jetzt wirds konkreter:

Wieviele Schaltfolgen ?
Wieviele geschaltete Geräte ?

Es könnte durchaus möglich sein das eine 1Kb Lookuptabelle für alle
möglichen Schaltfolgen ausreicht. Dann besteht nämlich das Update nur
noch aus dem Übertragen und Programmieren dieser Tabelle.

Gruß Hagen

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...
das derzeitige programm ist in bascom ( geschreibselt)

dort liegt im eeprom  ja schon eine variablentabelle

die von per rs232   zb mit      #h008 #g244   überschrieben werden
kann

....aber eigentlich schwebt mir ein ganz neues system vor
 ich muss mir erst mal um die konkrete neue hardware klar werden ...

das heist grosszügig dimensioniert ..für spätere erweiterungen
...die besten einfälle kommen meist immer erst wenn man fertig ist
und an der hardware nur schwer was zu ändern ist

...deswegen ziehe ich den modularen aufbau vor
jetz ist der tnc, die steuerung, und dtmf-notabschaltung
auch getrennt

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias

"Warum das denn? Wenn der Bootloader vor dem Sprung in die
Applikation
prüft ob diese korrekt geladen wurde (wie z.B. mit dem von mir
genannten Hash-Wert) dann kann da nichts schiefgehen."

???

Der Hashwert ist doch völlig schnuppe.

Es geht darum, daß wenn Du einen Softwarefehler gemacht hast und
dadurch nicht mehr in die Bootloaderroutine gesprungen werden kann,
dann wars das. Oder in den Bootloader wird zwar gesprungen, aber
falsche Werte übergeben usw.


Wie willst Du denn garantieren, daß sämtliche Updates bugfrei sind !

Nur dann würde in der Tat ein Bootloader im selben Chip ausreichen, der
nur den Hashwert prüft.

Aber ich bin auch nur ein Mensch und würde daher nie behaupten, daß
meine Programme bugfrei sind.


Peter

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@peter
eine Software die im Feld eingesetzt werden soll wird ja vorher
hoffentlich getestet. Solange so ein System bei mir auf dem
Schreibtisch liegt kann ich ja selber auf den Reset-Knopf hämmern.

Gutes Softwaredesign zeichnet sich auch dadurch aus das selbst bei
einem Fehler eine Notfallroutine angesprungen wird. Watchdog + sinnvoll
gewählte Triggerpunkte (nicht in der Timer-ISR) ist da schonmal ein
guter Anfang.

Das sowas hervorragend funktioniert hat z.B. die NASA (besser: das
MER-Team des JPL) vor etwa zwei Jahren bewiesen als der Rechner von
MER-A (Spirit) aufgrund eines Fehlers nicht mehr anständig
funktionierte. Das Softwaredesign war aber so ausgelegt das es eben
möglich war ein Softwareupdate einzuspielen und das ohne einen zweiten
Controller und ohne jemanden dahin zu schicken :-)

Matthias

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias,

ich glaube nicht, daß man alles mit der Arbeit bei der NASA vergleichen
kann, denn da steckt doch erheblich mehr Geld dahinter, um sowas zu
realisieren.

Und daß es einmal geklappt hat, ist noch lange kein Beweis, daß es
immer gut geht.

Warum unnötig ein Risiko eingehen, wenns auch 1 Euro mehr für nen 2.MC
tut ?

Denn nach Murphys Gesetz tritt immmer genau das Problem auf, welches
man vorher ausgeschlossen hatte.


Ich weiß, Du machst natürlich nie Fehler (bist Du Gott ?).


Aber ich hatte neulich auch mal zu hektisch geklickt und schon war die
Resetfuse im ATTiny26 an. Wie gut, daß ich ein STK500 habe.


Peter


P.S.:
Wenn 1CPU-Lösungen wirklich so idiotensicher sind, warum zerflashen
sich dann täglich Leute ihre Motherboards, MP3-, DVD-Player usw. ?

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>ich glaube nicht, daß man alles mit der Arbeit bei der NASA
vergleichen
>kann, denn da steckt doch erheblich mehr Geld dahinter, um sowas zu
>realisieren.

Nicht alles. Aber als Extrembeispiele (das Versagen des
Updatemechanismus bedeutet den Totalverlust der Sonde) eignen sich
diese ganz hervorrangend da man nicht auf Redundanz setzen kann (Kosten
+ Gewicht + Energie)

>Warum unnötig ein Risiko eingehen, wenns auch 1 Euro mehr für nen
2.MC
>tut ?
>Ich weiß, Du machst natürlich nie Fehler (bist Du Gott ?).

Auch Götter machen hin und wieder Fehler ;-)

Du scheinst aber ein System aus zwei µCern fehlerfrei hinzubekommen
wärend du daran zweifelst das es bei einem System mit nur einem nicht
geht.

>Wenn 1CPU-Lösungen wirklich so idiotensicher sind, warum zerflashen
>sich dann täglich Leute ihre Motherboards, MP3-, DVD-Player usw. ?

Weil sie miserabel (ohne Notfallsystem aka Bootloader) implementiert
sind? Wer eben nur 19,90€ für seinen DVD-Player bezahlen will der darf
nicht damit rechnen das der Herr Entwickler beim Abschreiben der
App-Note des Chipherstellers (oder sogar der Chiphdesigner selber)
mitdenkt.

Matthias, der jetzt erstmal Schneeschippen geht.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias,

"Du scheinst aber ein System aus zwei µCern fehlerfrei hinzubekommen
wärend du daran zweifelst das es bei einem System mit nur einem nicht
geht."

Das nicht, aber man muß dann nur einmalig den Bootloader testen und zum
Laufen kriegen und kann ihn danach schlichtweg vergessen.


Wenn man dagegen mehrere Programme in einer CPU hat, kann es immer zu
Seiteneffekten kommen.
D.h. ein fehlerhaftes Hauptgramm kann dem fehlerfreien Bootloader
soweit ins Handwerk pfuschen (IO-Register, SRAM manipulieren), daß er
plötzlich nicht mehr läuft.

Es erscheint mir viel schwerer einen Bootloader gegen derartige
Einflüsse abzusichern, als ihn ausschließlich in einer separaten CPU
laufen zu lassen.
Man kann garnicht so verrückt denken, wie ein Amok laufendes Programm
reagiert.


"Matthias, der jetzt erstmal Schneeschippen geht."

Bei mir scheint gerade die Sonne und von Schnee ist nix zu sehen.


Peter

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias

apropo 2-prozessor-system ...
ist der usbisp-programmer ev. von dir ?
und sind dort nicht auch 2 prozessoren drinne ?

... aber mir schwebt eigentlich was anderes im kopf rum

es könnte doch möglich sein dort den usb-prozessor duch eine
funkstrecke zum pc zu ersetzen ?

... du müstest doch das protokoll doch am besten kennen ?

durch solchen programmer könnte mann zu jeder zeit unabhängig
vom ziel-system neue programme draufschreiben

...denk ich mir mal so

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

bin wieder vom Schneeschippen zurück. 80cm Neuschnee seit gestern
Nacht.

Jap. USBisp ist mein Werk. Ich seh den FT245 als
Schnittstellenkonverter und nicht als Prozessor. Im Prinzip kann man
die Schnittstelle einfach gegen eine Funkstrecke ersetzen. Bluetooth
(serielles Profil) wär da eigentlich ganz witzig. Würde das Kabel zum
PC sparen :-)

Matthias

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
80cm, Wahnsinn !

Hatte oben ein -pro- vergessen (Hauptprogramm).


Peter

Autor: Feadi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
void main()
{
  for (;;)
  {
    wdt_reset();
  }
}

Was mache ich denn wenn ich versehentlich so eine Firmware flashe?
An der Checksumme kann der BL nicht merken das etwas nicht stimmt.
Der 2. µC dagegen, kann das wieder grade bügeln.

Gruß, Feadi

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Matthias

naja bluetooth währe zwar ganz witzig, aber das sehe ich eher als
schreibtisch-funk an

5km sollte das schon halbwegs überbrücken können
könnte ev. schon mit wlan-komponenten bei geigneten antennen
gehen

die simens-usb-übertrager auf basis von dect giebts ja wohl nicht mehr
...   die sollten ein ein usb-kabelersatz darstellen
aber waren auch sehr teuer ca. 250euro

Autor: DAU-xxl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...

hier habe ich was gefunden
was eventuel geignet erscheint bei usbisp den schnitstellenwandler
durch funkstrecke zu ersetzen ?

http://www.chip45.com/index.pl?page=iDwaRF-168&lang=de

hat zwei getrennte antennen ...
so das es leicht möglich währe dort ein nachbrenner anzuhängen

und preiswert scheint es auch ?

ist zwar eigentlich nicht meine frequenz ... aber amateurfunk-fähig

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.