Bootloader per ISP

dein Link ist kaputt, ich wunderte mich schon über die Meldung,

hier richtig:
https://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung

Peter F. schrieb:
> Ich hab auch mal gelesen,
> dass es den Bootloader eigentlich egal ist ob jetzt per UART oder ISP
> geflahst wird, nur da fehlt mir ein konkreter Ansatz wie ich den
> Beispielcode aus den o.g. Tutorial anpassen kann.

keine Ahnung, aber warum willst du über ISP gehen? wer soll das regeln? 
Der RFM ist ja nicht unbedingt ein vollständiger µC der das kann.

Meine Idee wäre es einen Code per UART und alten Bootloader in den Flash 
zu laden, der dann ausgführt den neuen Bootloader holt und in die 
Bootloadersection schreibt, aber ist nur Theorie habe das am AVR nie 
versucht, hatte mich früher mehr mit 6502, z80, LH5803 beschäftigt, Code 
relokatibel schreiben verschieben und im EEPROM verankern.

ich fürchte du musst bei 0 anfangen. den bootloader also komplett neu 
aufsetzen.
dein bootloader muss also den rfm12 ansteuern, damit er die übertragenen 
bytes empfangen und in einen puffer schieben kann. wenn eine page 
übermittelt ist, schreibt der bottloader sie in den flash. das ganze 
machst du so lange, bis das komplette programm übertragen ist und im 
flash liegt. dingen wie fehlererkennung solltest du hier auf jedenfall 
vermehrt aufmerksamkeit schenken!

noch etwas: der rfm12 ist abgekündigt. wenn dein projekt auch in 10 
jahren noch nachgebaut werden können soll, welchel besser auf den rfm69, 
den gibt es auch pin-kompatibel zum rfm12.

Joachim B. schrieb:
> keine Ahnung, aber warum willst du über ISP gehen?

Weil der RFM12 daran angeschlossen ist.

Joachim B. schrieb:
> wer soll das regeln?

Ja der Bootloader der auf den Controller ist.

Joachim B. schrieb:
> Meine Idee wäre es einen Code per UART und alten Bootloader in den Flash
> zu laden, der dann ausgführt den neuen Bootloader holt und in die
> Bootloadersection schreibt,

Beim ersten flashen verwende ich ein ISP-Programmer der einen Bootloader 
und den "normale" Code in den Controller lädt. Dann will ich den 
Controller in ein "Flash-Modus" bringen, also springe zu Adresse 0xXYZ. 
Da bekomme ich mit Hilfe des Tutorials hin. Nur jetzt soll er ja den 
eigentlich empfangenen Code ebenfalls ber SPI übertragen und wie wie oft 
beschrieben über UART.

Peter F. schrieb:
> Joachim B. schrieb:
>> keine Ahnung, aber warum willst du über ISP gehen?
>
> Weil der RFM12 daran angeschlossen ist.

Ich bin jetzt mal davon ausgegangen, das du SPI meinst, nicht ISP!
SPI ist eine Serielle schnittstelle. ISP ist ein Programmierprotokoll

Chris L. schrieb:
> dein bootloader muss also den rfm12 ansteuern, damit er die übertragenen
> bytes empfangen und in einen puffer schieben kann.

Mein jetztiger Code macht ja nichts anderes, das ist auch nicht das 
Problem.

Chris L. schrieb:
> wenn eine page
> übermittelt ist, schreibt der bottloader sie in den flash. das ganze
> machst du so lange, bis das komplette programm übertragen ist und im
> flash liegt

Das ist das, wo ich nicht weiterkomme. Sämtliche Beispiele übertragen 
das Ganze über UART.

Hat noch niemand ein sein Controller per Funk und SPI geflasht ? Ich 
muss das Rad doch nicht neu erfinden.

Peter F. schrieb:
> Ich
> muss das Rad doch nicht neu erfinden.

"Erfinden" nicht. Aber implementieren wirst Du es selbst müssen.

Ich habe es schon mal gemacht. läuft bis heute zuverlässig.
im endeffekt, musst du die RFM12-Bibliothek in den Bootloader kopieren 
und die stelle, an der auf ein einkommendes zeichen per uart abgefragt 
wird durch den code ersetzen, der das zeichen vom rfm12 abholt.

aber schau mal, was ich mit google finden konnte: 
https://www.das-labor.org/wiki/Nakkaloader

Chris L. schrieb:
> Ich habe es schon mal gemacht. läuft bis heute zuverlässig.
> im endeffekt, musst du die RFM12-Bibliothek in den Bootloader kopieren
> und die stelle, an der auf ein einkommendes zeichen per uart abgefragt
> wird durch den code ersetzen, der das zeichen vom rfm12 abholt.
>
> aber schau mal, was ich mit google finden konnte:
> https://www.das-labor.org/wiki/Nakkaloader

Ja genau. Ich denke das ist das was ich gesucht habe, danke.

Chris L. schrieb:
> musst du die RFM12-Bibliothek in den Bootloader kopieren
> und die stelle, an der auf ein einkommendes zeichen per uart abgefragt
> wird durch den code ersetzen,

er will aber den Bootloader ersetzen also überschreiben und das geht nun 
mal nicht während der Bootloader Zeichen holt, sich selber das Programm 
zu klauen.

Den Weg hatte ich ja skizziert, der alte Bootloader oder welches PRG 
auch immer empfängt Zeichen (neuen Bootloader) über den SPI vom RF, 
speichert diese zwischen im flash oder sonstwo, der atmega 1284p hat 
sogar 16kB SRAM da passt locker eine ganze Serie von bootloader rein.
Ein Proggi im flash verschiebt nach Prüfung das Empfangene in die 
Bootloadersection und reset.

Joachim B. schrieb:
> Chris L. schrieb:
>> musst du die RFM12-Bibliothek in den Bootloader kopieren
>> und die stelle, an der auf ein einkommendes zeichen per uart abgefragt
>> wird durch den code ersetzen,
>
> er will aber den Bootloader ersetzen also überschreiben und das geht nun
> mal nicht während der Bootloader Zeichen holt, sich selber das Programm
> zu klauen.

Ne ich denke er hat es schon ganz gut getroffen. Der Bootloader bleibt 
drauf und wird nciht überschrieben.

Joachim B. schrieb:
> Chris L. schrieb:
>> musst du die RFM12-Bibliothek in den Bootloader kopieren
>> und die stelle, an der auf ein einkommendes zeichen per uart abgefragt
>> wird durch den code ersetzen,
>
> er will aber den Bootloader ersetzen also überschreiben und das geht nun
> mal nicht während der Bootloader Zeichen holt, sich selber das Programm
> zu klauen.
>
> Den Weg hatte ich ja skizziert, der alte Bootloader oder welches PRG
> auch immer empfängt Zeichen (neuen Bootloader) über den SPI vom RF,
> speichert diese zwischen im flash oder sonstwo, der atmega 1284p hat
> sogar 16kB SRAM da passt locker eine ganze Serie von bootloader rein.
> Ein Proggi im flash verschiebt nach Prüfung das Empfangene in die
> Bootloadersection und reset.

Ist der Schreibzugriff auf die Bottloadersektion bei aktivierter Fuse 
nicht blockiert? Ich habe diesen weg nämlich schonmal versucht und hatte 
keinen erfolg in die bootloadersektion zu schreiben.

Chris L. schrieb:
> Ist der Schreibzugriff auf die Bottloadersektion bei aktivierter Fuse
> nicht blockiert?

muss die Fuse aktiviert sein, ich habe gerade mal geschaut, in meinem 
arduino mighty 1284p ist keine Fuse gesetzt und im Netz habe ich das 
gefunden, vielleicht hilfts:
http://www.lochraster.org/foodloader/

mir ist aber immer noch unklar wo das RFM Programm sitzt im Bootloder 
oder im flash welches die RFM Bytes einsammelt.

Ulrich F. schrieb:
> Und der Bootloader steckt natürlich im Flash.

witzig, ich halte dich für schlau genug zu verstehen was ich meinte.

Ich meinte die NON Bootloader Section, das beides flash ist war mir 
klar, nur mal so als Info ;-)

mir ist immer noch nicht klar wo das PRG sitzt welches die RFM Bytes 
einsammelt, dazu schweigt der TO.

Ist das PRG in der Bootloadersection kann es nicht gleich den Bootloader 
umflashen beim Einsammeln, ist es nicht in der Bootloadersection kann es 
klappen. Allenfalls müsste der alte Bootloader in die normale 
Programmsection "verschoben" oder kopiert werden und könnte von dort den 
Bootloader neu flashen.

Ulrich F. schrieb:
> Wenn der Bootloader den AVR flashen soll, dann sollte sich die ganze
> Funkabhandlung auch im Bootloader befinden.

soll er denn? wenn ja kann er das ja nicht beim Empfang der Daten 
machen, sich selber zu überschreiben.

Als Ergänzung (Auch für Peter F.):
Die Funktionen für die Steuerung des RFM12 MUSS natürlich mit im 
Bootloader sein. Es wäre zwar durchaus möglich, die auch woanders 
abzulegen (In der Applikation beispielsweise), aber woher will/soll man 
während der Programmierung des Bootloaders wissen an welcher Stelle 
später welche Funktion steht! Zumal sich diese Position ja durchaus auch 
während der Applikationsentwicklung noch mehrmals ändern kann.

Ulrich F. schrieb:
> Ich glaube du machst dir zu komplizierte Gedanken....

ich rate nur weil die Aufgabenstellung so diffus ist.

Ulrich F. schrieb:
> Der AVR ist seriell unerreichbar.

da denke ich doch sofort an:
Beitrag "bidirektionale RS232 Funkbrücke mit RFM12"

selber nachgebaut und funktionierte auf Anhieb!

Ulrich F. schrieb:
> Um das Problem zu lösen, möchte er einmalig einen Funk fähigen
> Bootloader aufspielen. Danach ist es ihm möglich den AVR aus der Ferne,
> ohne Kabel zu Flashen.
>
> Also muss er dem Bootloader Funk beibringen.
> Auch die Anwendung benötigt höchstvermutlich Funk.

Genau.

Nochmal zum Verständniss. Es Gibt ein RFM12 der über das SPI mit den 
Atmega88 kommuniziert. Dann gibt es parallel dazu gibt es einen Abriff 
womit ich den Controller über mein ISP-Programmer flashen kann. Der 
Controller Wertet die Daten aus die über Funk empfangen werden. Nun baue 
ich das Teil ein und will das nicht immer wieder ausbauen müssen wenn 
ich am Code etwas anpasse. Deswegen will ich die vorhandene 
Funkverbindung nutzen um den Controller damit upzudaten.

Ulrich F. schrieb:
> Der Einfachheit zur liebe wird man die Funkabhandlung dann 2 mal auf dem
> AVR haben.

So hab ich das jetzt auch verstanden. Eine Routine als Bootloader um den 
zu flashenden Code zwischenzuspeichern und weiterzuleiten und eine 
weitere Routine der die eigentliche Anwendung sein soll.

Ulrich F. schrieb:
> Der Einfachheit zur liebe wird man die Funkabhandlung dann 2 mal auf dem
> AVR haben.

und wie? das Programm vom Benedikt belegt ca. 20k

selbst abgespeckt wird man das nicht in die Bootlodersection bekommen 
und Errorhandling und CRC wird man auch nicht auslassen wollen.