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????
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.
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
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.
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 !
@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?
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 ...
wenn man dem Modem (TNC) nach dem Verbindungsaufbau an dieses Programm hängt müsste es doch gehen, oder? Es ist halt ekein fullduplex...
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!
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
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
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
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
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
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
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
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.............
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
Wenn man das eeprom gross genug macht kann man dort auch die "alte" Programmversion als Backup halten.
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
@ 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
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
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
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 ? .....
@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
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/evertool/#etlight
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 ?
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
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
@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
@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
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
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
@ 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
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...
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 )
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)...
>>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
... 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
@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
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
@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. ?
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.
@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
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
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
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
@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
... 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.