Hallo zusammen, ich weiß das das Thema schon gefühlte 100mal aufgegriffen wurde, trotzdem komme ich gerade nicht weiter. Ich habe ein RFM12 an meinen Attmega88 und will den per Funk flashen. Das Tutorial "https://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung"; funktioniert schon ganz gut, jedoch läuft das Ganze per UART, aber der µC soll mit dem RFM12 per SPI geflasht werden. Im Prinzip will ich nur das Kabel ersetzten, weil die fertige Platine sich 2 Etagen tiefer befindet. Ich habe schon zahlreiche Threads darüber gelesen und jedesmal wird der eigentliche Code per UART übertragen. 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. Gibt es den mittlerweile ein Codebeispiel o.ä. welches mir etwas weiterhilft ??? Gruss
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: > Das ist das, wo ich nicht weiterkomme. Sämtliche Beispiele übertragen > das Ganze über UART. Ja, manchmal ist das so... Dann muss man selber machen!
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Joachim B. schrieb: > mir ist aber immer noch unklar wo das RFM Programm sitzt im Bootloder > oder im flash welches die RFM Bytes einsammelt. Beides! Wenn der Bootloader den AVR flashen soll, dann sollte sich die ganze Funkabhandlung auch im Bootloader befinden. Und der Bootloader steckt natürlich im Flash.
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.
:
Bearbeitet durch User
Ich glaube du machst dir zu komplizierte Gedanken.... Wenn ich den TE richtig verstanden habe, dann hat er einen AVR und ein Funkmodul. Jetzt kann er nicht immer, wenn er ein neues Programm auf den AVR spielen will, mit dem seriellen Adapter durch die geschlossenen Tür. Der AVR ist seriell unerreichbar. 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. Der Einfachheit zur liebe wird man die Funkabhandlung dann 2 mal auf dem AVR haben.
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.
Joachim B. schrieb: > und wie? das Programm vom Benedikt belegt ca. 20k Dann ist es nicht geeignet. Wie wäre es hiermit: https://www.das-labor.org/wiki/Nakkaloader https://github.com/soern/nakkaloader (habe keinen RFN12, kann also nicht testen.)
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.