Hallo, meine Frage. Ist es möglich im Bootloader ein Byte austauschen? Also, eine bestimmte Adresse z.B. 0x01FE10 lesen und vergleichen. Wenn da 0x02 drin stecht, dann soll 0x03 reinschreiben werden. Hab es mit pgm_read_byte probiert, leider ohne Erfolg. WinAVR-20070525 Atmega128
hallo, klar geht das. sollte denn aber pgm_read_byte_far heißen, nicht wahr ? :) bye kosmo
Du kannst beim Atmega128 nicht ein enzelnes Byte im Flash überschreiben. Du mußt immer eine komplette Speicherseite von 256 Bytes erst löschen und dann neu beschreiben. Warum benutzt du nicht den EEPROM?
hallo, ist doch kein problem. jede halbwegs intelligente schreibroutine liest bei fehlenden daten für den flash den entsprechenden inhalt aus eben diesem. bye kosmo
>Warum benutzt du nicht den EEPROM?
Der Bootloader vergleicht zwei strings.
Char text1;
Char text2;
strncmp(text1, text2,4);
Ich will text1 durch text3 (text3 hat natürlich die gleiche Länge wie
text1) und die 4 durch 3 ersetzen.
Das ganze soll passieren ohne den Bootloader neu zu laden.
kosmonaut_pirx wrote: > ist doch kein problem. jede halbwegs intelligente schreibroutine liest > bei fehlenden daten für den flash den entsprechenden inhalt aus eben > diesem. Warum sollte sie ? Jede halbwegs intelligente Schreibroutine macht nur soviel Arbeit, wie nötig ist. In der Regel geht sie davon aus, daß alles hinter dem letzten Byte unerreichbarer Code ist und damit egal, was dort bis zum Ende der Page steht. Peter
>> Warum benutzt du nicht den EEPROM? > > Der Bootloader vergleicht zwei strings. > Ich will text1 durch text3 (text3 hat natürlich die gleiche Länge wie > text1) und die 4 durch 3 ersetzen. > Das ganze soll passieren ohne den Bootloader neu zu laden. Ich kann irgendwie keinen Zusammenhang zwischen meiner Frage und der Antwort darauf erkennen.
hallo, >Jede halbwegs intelligente Schreibroutine macht nur soviel Arbeit, wie >nötig ist. wie halt jeder die notwendige arbeit definiert. beim OP beinhaltete dies etwas anderes, als andere leute es defineren. >In der Regel geht sie davon aus, daß alles hinter dem letzten Byte >unerreichbarer Code ist und damit egal, was dort bis zum Ende der Page >steht. damit wird die annahme verbunden, dass kein aktueller zustand zu berücksichtigen ist, sondern die routine einen komplett neuen zustand definiert. kann man so sehen, wenn man mag. trotzdem ist es aus meiner sicht fahrlässig, bestehenden inhalt platt zu machen. das ist ähnlich, als wenn eine isr register verändert, und nachher nicht wieder herstellt. sicher kann man argumentieren, dass das beim bootloader nicht der fall ist, da bekanntlich anschliesend alles neu sein soll. spätestens, wenn's aber auch nur ein klein wenig mehr sein soll als nur das simple one-application-szenario, darf man sich dann aber was neues überlegen. es gilt wie so oft abzuschätzen, was und was nicht. bye kosmo
>Ich kann irgendwie keinen Zusammenhang zwischen meiner Frage und der >Antwort darauf erkennen. Der string, den ich austauschen will liegen im Bootloaderbereich und nicht im EEPROM
Tobias wrote: > Der string, den ich austauschen will liegen im Bootloaderbereich und > nicht im EEPROM Das ist schlecht. Ein Bootloader, der auch sich selbst modifizieren kann, ist gelinde gesagt riskant ! Wenn etwas änderbar sein soll, dann ist es im EEPROM wesentlich besser aufgehoben oder zumindest im Applikationsbereich unter dem Bootloader. Ich habe beim Schreiben meines Bootloaders sehr schnell gemerkt, daß die wichtigste Funktion ist, sich selber gegen Überschreiben zu schützen. Peter
> Der string, den ich austauschen will liegen im Bootloaderbereich und > nicht im EEPROM Und meine Frage war, warum du die Daten im Flash statt im EEPROM speicherst.
Ich versuch mal die Problematik genauer zu beschreiben. Nach dem einschalten sucht der Bootloader auf der angeschlossene SD-Karte eine Datei namens WRSTWK01.BIN. Falls die Datei vorhanden ist wird ein Softwareupdate durchgeführt. Das funktioniert auch alles, nur mit einen kleinen Schönheitsfehler. Und zwar, ich hab jetzt keine Möglichkeit die Datei zu unterscheiden z.b. zwischen Versionen. Es wäre doch viel besser wen der Bootloader nach einer Datei sucht die mit WRST beginnt, und alles was danach steht ignoriert. So könnte jetzt der Datei mit der Version 10 den Namen WRST_10 haben, Version 11 den Namen WRST_11 usw. In beiden Fällen wird die Funktion strncmp(WRST, Dateiname,4) true als Ergebnis liefern und ein Update machen. Auf der Karte darf natürlich immer nur eine Datei die mit WRST... beginnt abgelegt werden.
Tobias wrote: > Ich versuch mal die Problematik genauer zu beschreiben. Ja, versuche das mal. Bisher hat ja jedes Deiner Posts in diesem Thread ein völlig anderes Thema. > Es wäre doch viel besser wen der Bootloader nach einer Datei sucht die > mit WRST beginnt, und alles was danach steht ignoriert. Wenn Du es so haben willst, dann mache diese Änderung im Quelltext, compiliere ihn und brenne den Chip neu. Aber wo ist jetzt Deine Frage ? Peter
> Aber wo ist jetzt Deine Frage ? im ersten Thread. > Wenn Du es so haben willst, dann mache diese Änderung im Quelltext, >compiliere ihn und brenne den Chip neu. Ja, das wäre am einfachsten, wenn sich nicht meine Festplatte zusammen mit allen Quelltexten verabschiedet hätte.
Aha, Du willst ein Dir unbekanntes Programm patchen, warum sagst Du das nicht gleich. 1. Wie weißt Du, welche Adressen Du alle patchen mußt ? 2. Argumente werden nicht als Binärzahl auftauchen, sondern je nach Befehl (z.B. LDI) verschlüsselt. 3. Die Applikation kann kein SPM ausführen. 4. Falls der Bootloader einen SPM-Call hat, wird er sich wehren, ihn auf sich selbst anzuwenden. 5. Falls 4. nicht zutrifft, ist der Bootloader danach zerstört. 6. Vergiß es. Peter
>Aha, Du willst ein Dir unbekanntes Programm patchen, warum sagst Du das >nicht gleich. Das Programm ist von mir!!! >1. Wie weißt Du, welche Adressen Du alle patchen mußt ? Ich hab noch den HEX-File, und die Adresse vom WRSTWK01.BIN-String sieht man im Hex-Editor. Die Zahl „4“ (aus der Funktion strncmp(WRST, Dateiname,4)) muss ich noch finden. >4. Falls der Bootloader einen SPM-Call hat, wird er sich wehren, ihn auf >sich selbst anzuwenden. Wieso soll er sich wehren wenn ich im sage das er nach einer anderer Zeichenfolge suchen soll. Ich tausche im Hex-File WRSTWK01.BIN gegen WRST_XXX.BIN und brenne den Bootloader mit dem geänderten File.
Tobias wrote: > Ich hab noch den HEX-File, und die Adresse vom WRSTWK01.BIN-String sieht > man im Hex-Editor. Oben schreibst Du aber: >Hab es mit pgm_read_byte probiert, leider ohne Erfolg. Dann denkt doch jeder, Du willst den Bootloader mit sich selbst direkt im AVR patchen. Wenn Du aber das hex-File hast, dann ist völlig wurscht, was pgm_read_byte macht. Und es ist auch wurscht, ob der Flash sich selbst ändern kann. Du kannst es einfach auf dem PC mit nem HEX-Editor patchen. Also entscheide Dich endlich mal. Peter
Das soll ja nur ein Beispiel sein. Der Bootloader soll sich nicht selber patchen, sondern das Programm was auf dem Chip läuft soll das machen. Nach dem einschalten sucht der Bootloader nach der Updatedatei und wenn er nicht findet, dann startet dann „normale“ Programm. Und dieses Programm soll die Zeichenkette im Bootloader austauschen. Also, das gleiche wie mit dem Hex-Editor.
hallo, zugegeben, ich habe den thread später wenig verfolgt. aber was soll das beharren auf festen positionen? bisher dachte ich, open source funktioniert auch deshalb, weil man etwas macht, gerade weil es möglich ist. wenn wir uns vorschreiben lassen, was in welcher form stets zu erfolgen hat, können wir das alles lassen und zu ms wechseln. mal so in den raum gestellt. bye kosmo
Tobias wrote: > Das soll ja nur ein Beispiel sein. > Der Bootloader soll sich nicht selber patchen, sondern das Programm was > auf dem Chip läuft soll das machen. Nach dem einschalten sucht der > Bootloader nach der Updatedatei und wenn er nicht findet, dann startet > dann „normale“ Programm. Und dieses Programm soll die Zeichenkette im > Bootloader austauschen. Also, das gleiche wie mit dem Hex-Editor. Nochmal, die Applikation kann kein SPM ausführen. Sie braucht Unterstützung vom Bootloader. D.h. der Bootloader muß einen API-Call bereitstellen, den die Applikation aufrufen kann. Und alles, was dieser API-Call benutzt, darf nicht in den Pages stehen, die modifiziert werden. Es führt sich nämlich ziemlich schwer Code von einer zeitweilig gelöschten Page aus. Und dieser API-Call muß in Assembler geschrieben sein, damit er keine Register und SRAM verändert, sondern nur auf dem Stack arbeitet. Daher meine Zweifel, daß Du den Bootloader selber geschrieben haben willst, wenn Du nicht mal die Grundlagen weißt. Ohne den Bootloader neu zu schreiben, geht das also nicht. Und wenn Du ihn neu schreibst, kannst Du besser gleich die variablen Daten im EEPROM ablegen. Peter
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.