Hallo ich habe mal ne simple (doofe) Frage zu einem Bootloader bei den Atmegas. Klar der Bootloader erlaubt es ein Programm über die serielle Schnittstelle zu flashen. Falls man aber zwischendurch mit dem AVRISP ein Programm drauf flasht (Ohne Bootloader) geht dann der Bootloader verloren oder ist der geschützt? Oder muß man den Bootloader mit jedem AVRISP flashen den Bootloader mit draufladen? MfG Rainer Ps: Ich frage aus Unsicherheit, da ich einen Modul mit Bootloader habe, von dem ich aber keine SOURCE habe. Ich kann aber derzeit nur mit dem AVRISP flashen ------also Entschuldigung für die Frage----------
Du kannst im Programmiermodul des AVR-Studio einstellen ob vor dem flashen ein "erase device" durchgeführt wird oder nicht. Bei einem erase wird der Loader gelöscht, ohne nicht, es sei denn Dein Programm ist so groß, dass es bis in den Loaderbereich hinein schreibt, dann wird dieser überschrieben. ---- wer nicht fragt bleibt dumm :o))) -------------
>Ps: Ich frage aus Unsicherheit, da ich einen Modul mit Bootloader habe, >von dem ich aber keine SOURCE habe. Ich kann aber derzeit nur mit dem >AVRISP flashen Na, dann flashst du halt mit dem Bootloader. Dazu ist der da. Oder du nimmst den Chip mit Bootloader raus und ersetzt den durch einen neuen Chip ohne Bootloader.
Fhutdhb Ufzjjuz schrieb: > Du kannst im Programmiermodul des AVR-Studio einstellen ob vor dem > flashen ein "erase device" durchgeführt wird oder nicht. Blödsinn! Sicher kann man das einstellen. Aber wenn ein Programm drin ist, muß das vorher gelöscht werden. Flash kann man nicht überschreiben! Wenn zudem noch die Lockbits gesetzt sind, geht ohne Löschen gar nichts. Sind diese jedoch nicht gesetzt, kann man den Flash auslesen und den Bootloader sichern. Ansonsten: siehe holger. mfg.
Thomas Eckmann schrieb: > Blödsinn! > > Sicher kann man das einstellen. Aber wenn ein Programm drin ist, muß das > vorher gelöscht werden. > > Flash kann man nicht überschreiben! Seit wann ? Ich habe den Haken bei Erase Device fast nie gesetzt und überschreibe den Flash einfach. Geht. Grüsse
Hallo, mmmmhhhh ...meine Verunsicherung wird größer..... Warum: - Ich bin der Meinung (d.h. ich weiß es nicht), dass man vor dem flashen löschen muß, da sonst nur additiv geschrieben werden kann. Gelöscht ist ja alles FF Hex und wenn mal ein Bit auf 0 geflasht ist kann es durchs flaschen nicht gelöscht werden...Bisheriger Kenntnisstand es muß deshalb vorher gelöscht werden wenn man nicht hinter das vorherige Programm schreibt. Ist das FALSCH? - Wenn man vorher löschen angklickt hat wird der Bootloader gelöscht oder kann man den schützen? >>Oder du nimmst den Chip mit Bootloader raus und ersetzt >>den durch einen neuen Chip ohne Bootloader. das ist bei einem gelöteten AU Gehäuse nicht so einfach...sonst hätte ich das natürlich gemacht? Kann jemand zu Klärung beitragen? Frage: Kann man ein Programm mit AVRISP flashen ohne den Bootloader zu löschen, so dass dieser auch immer wieder geflaht werden muß? MfG Rainer
Jürgen W. schrieb: > Seit wann ? Ich habe den Haken bei Erase Device fast nie gesetzt und > überschreibe den Flash einfach. Geht. Na dann viel Glück......
>Frage: Kann man ein Programm mit AVRISP flashen ohne den Bootloader zu >löschen, so dass dieser auch immer wieder geflaht werden muß? Ja, solange du kein Chip Erase benutzt. Wie bereits oben gesagt kannst du flashen ohne den Booloader zu löschen wenn die Lockbits nicht gesetzt sind. Wenn die Lockbits gesetzt sind hast du ein Problem. So, und nochmal: Wieso benutzt du den Bootloader nicht. Du brauchst kein ISP wenn der Bootloader drin ist.
Jürgen W. schrieb: > Seit wann ? Ich habe den Haken bei Erase Device fast nie gesetzt und > überschreibe den Flash einfach. Geht. Ja ja. Aber nur wenn auch das "Verify"-Häkchen nicht gesetzt ist. Sonst gibt es nämlich einen Fehlermeldung. Eine Frage an die Knobler und Statistiker: Wie oft muß man durchschnittlich, ohne vorher zu löschen, flashen, bis alle Speicherstellen 0x00 enthalten? mfg.
Skript Kiddy schrieb: > Na dann viel Glück...... Ich sagte ja, fast nie. Bei der Programmentwicklung ist es schneller und außerdem schonender für den MC. Wenn man den Controller X-mal flasht, wieso sollte man da jedesmal alle Bytes auf $ff setzen ? Ausserdem wird bei einem Chip Erase das Eeprom mitgelöscht wenn die EESAVE Fuse nicht gesetzt ist. Meiner Meinung reicht einmal Chip Erase & Verify. Wenn die Software fertig ist.
Flashs werden Sektorweise gelöscht. Der Bootloader belegt je nach größe einen oder mehere Sektoren. Die größe des Bootloader wird vor dem flashen eingestellt und muss mit der größe des Bootloaders harmonieren. Beim Löschen des Flashes werden die Sektoren für den Bootloader nicht gelöscht. das ganze hängt auch noch vom dem Device ab.
BootloaderHeini schrieb: > Klar der Bootloader erlaubt es ein Programm über die serielle > Schnittstelle zu flashen. Nein. Ein Bootloader dient dazu, Programmcode in den Flash zu schreiben, so dass dieser ausgeführt werden kann. - Ob dafür die serielle oder eine andere Schnittstelle benutzt wird, hängt vom jeweiligen Bootloader ab. - Das Protokoll, mit dem der Programmcode an den Bootloader übertragen werden muss, ist nicht festgelegt. - Die Methode, wie vom Anwendungsprogramm in den Bootloader gesprungen wird, um neuen Programmcode hochzuladen, ist nicht festgelegt. - Die Bedingung, die bestimmt, ob und wann der Bootloader das neu geflashte Anwendungsprogramm aufruft, ist nicht festgelegt. - Wo genau der Bootloader im Flash liegt, ist nicht festgelegt, auch wenn die meisten Bootloader am Ende des Flashspeichers liegen: Zwingend notwendig ist das nicht. Es ist auch möglich, dass der Bootloader zwar am Ende des Flashspeichers liegt, wegen seines Umfangs aber zusätzlich Bereiche im Flash belegt, die normalerweise für das Anwendungsprogramm vorgesehen sind. Wie Du siehtst: Wenn Du keine detaillierten Informationen über die Funktionsweise des Bootloaders in Deinem Chip hast, ist er für Dich ohnehin nutzlos. In dem Fall kannst Du hin getrost überschreiben, bzw. Durch einen eigenen Bootloader ersetzen.
Jürgen W. schrieb: > Meiner Meinung reicht einmal Chip Erase & Verify. Wenn die Software > fertig ist. Also nie. Weil auf diese Weise wirst du deine Software nie testen können. Jürgen W. schrieb: > wieso sollte man da jedesmal alle Bytes auf $ff setzen ? Damit sie man wieder auf null setzen oder so lassen kann. Wie soll denn sonst eine "1" an eine Speicherstelle kommen, die eine "0" beinhaltet? Beim Brennen eines Flash werden nur "Nullen" geschrieben. Die "Einsen" werden so gelassen, wie sie sind. Das funktioniert aber nur dann, wenn vorher überall "Einsen" stehen. Kein Wunder, daß deine Programme nie laufen. mfg.
i kann das auch bestaetigen, Flash muss vor dem neuproggen geloescht werden denn man kann nur bits auf 0 proggen, daher werden beim loeschen alle auf 1 gesetzt @B-Heini: ist der Chip 'gelockt' oder nicht ? @Andreas: genau richtig, und noch vieles mehr ist moeglich.... (i arbeite z.B. mit einem Bootloader ueber 1Wire) vlG Charly
Andreas schrieb: >> Klar der Bootloader erlaubt es ein Programm über die serielle >> Schnittstelle zu flashen. > > Nein. Hmm??? Andreas schrieb: > Ein Bootloader dient dazu, Programmcode in den Flash zu schreiben, so > dass dieser ausgeführt werden kann. Aha! Und was macht ein ISP? Der schreibt also keinen Programmcode in den Flash, den man nachher ausführen kann. Man lernt ja nie aus. mfg.
Thomas Eckmann schrieb: > Man lernt ja nie aus. Wenn Du einen Satz weiter gelesen hättest, hättest Du tatsächlich etwas lernen können: Nämlich, dass sich das "Nein" auf die Worte "serielle Schnittstelle" bezog. ;)
Thomas Eckmann schrieb: > Beim Brennen eines Flash werden nur "Nullen" geschrieben. Die "Einsen" > werden so gelassen, wie sie sind. Das funktioniert aber nur dann, wenn > vorher überall "Einsen" stehen. Und genau das macht meine Brennsoftware im AVR-Studio. Nur anstatt den kompletten Flash vorher mit FFs zu beschreiben, wird nur die benötigte Page vor dem neu-beschreiben gelöscht. Thomas Eckmann schrieb: > Kein Wunder, daß deine Programme nie laufen. Sag mal muss das wirklich sein ? Reagierst du immer so, wenn jemand anders arbeitet als du ? Erst behauptest du der Flash lässt sich nicht überschreiben. Dann sagst du es geht doch ohne Verify. Dann wirst du beleidigend. Was kommt als nächstes ? Naja, ich bin dann mal weg.
Hallo nochmal zum Löschen vor dem flashen. Im UseresGuide steht: Device A full chip erase is performed by pressing the Erase Device button. The check boxes specifies options for subsequent programming: a chip-erase can be performed before memory programing operations, and memory programming can be automatically verified. ..muß man jetzt zwingend vorher löschen oder nicht? Also ich habe bisher immer vorher gelöscht. >dass sich das "Nein" auf die Worte "serielle >Schnittstelle" bezog. ;) ..zwei Pins die Softwaremäßig wie ne serielle Schnittstelle bedient werden ist zwar kein Hardware-Uart aber doch seriell. Oder ist das falsch? ....okok.. 1-Wire oder sowas....SD-Card..Netzwerk...etc..naja man lernt halt dazu....
Jürgen W. schrieb: > Und genau das macht meine Brennsoftware im AVR-Studio. Nur anstatt den > kompletten Flash vorher mit FFs zu beschreiben, wird nur die benötigte > Page vor dem neu-beschreiben gelöscht. Jetzt musst du uns nur noch mitteilen, welchen AVR-Controller du benutzt. Ich kenne nämlich keinen, bei dem über die Programmier-Schnittstelle ein Löschen einzelner Pages möglich wäre, aber ich würde mich gerne eines besseren belehren lassen.
>..muß man jetzt zwingend vorher löschen oder nicht? Das kommt auf die Lockbits an. Sind die jetzt bei deinem scheiss Controller gesetzt oder nicht? Wenn die gesetzt sind wirst du den löschen müssen wenn du ISP programmieren möchtest. Was ist das überhaupt für ein Board? Und nochmal: WARUM BENUTZT DU DEN BOOTLOADER NICHT? Watum gibts du darauf kein Antwort? Wenn du nur mal ein bisschen ISP ausprobieren möchtest dann klopp dein Board in die Ecke und kauf dir nen leeren AVR. Da kannst du dann üben.
Jürgen W. schrieb: > Und genau das macht meine Brennsoftware im AVR-Studio. Nur anstatt den > kompletten Flash vorher mit FFs zu beschreiben, wird nur die benötigte > Page vor dem neu-beschreiben gelöscht. Das wäre mir neu.
1 | Before new contents can be written to the Flash Program Memory, the memory |
2 | has to be erased. Without erasing, it is only possible to program bits in |
3 | Flash memory to zero, not selectively setting a bit to one. Erasing the |
4 | memory is performed with the “Chip Erase” command. This command will erase |
5 | all memory contents, both Flash Program Memory and EEPROM. |
(Quelle: AVR910 ) Was für einen AVR verwendest du?
Skript Kiddy schrieb: > Was für einen AVR verwendest du? Im Moment einen m48. Gerade nochmal mit Verify probiert. Meckert nur, wenn der Code kleiner wird als der vorhergehende. Ist ja auch klar, da dann noch Reste vom alten Code dahinter steht. Ich hatte den Chip Erase Haken aber auch schon an anderen AVRs aus. Ging immer ohne Problem. Einfach mal probieren.
Jürgen W. schrieb: > Im Moment einen m48. Aber auch bei dem ist ein Löschen einzelner Pages über die Programmier-Schnittstelle nicht möglich.
Jürgen W. schrieb: > Erst behauptest du der Flash lässt sich nicht überschreiben. > > Dann sagst du es geht doch ohne Verify. Habe ich nie behauptet. Ohne bekommst du keine Fehlermeldung, daß das schief gegangen ist. > Dann wirst du beleidigend. Wenn man ohne zu löschen ein Programm überbrennt, kann das nicht laufen. Und wenn doch, dann glaubst du das nur. Was ist daran beleidigend? > Was kommt als nächstes ? Jürgen W. schrieb: > Und genau das macht meine Brennsoftware im AVR-Studio. Nur anstatt den > kompletten Flash vorher mit FFs zu beschreiben, wird nur die benötigte > Page vor dem neu-beschreiben gelöscht. Was ist denn das für eine Software? Und wo kommt die plötzlich her? Weiter oben hast du noch behauptet, daß du einfach überbrennst und nur, wenn alles fertig ist, wird vorher gelöscht. Und wieseo löscht diese Software, obwohl das Häkchen zum vorher Löschen nicht gesetzt ist? Ich denke mal, du befindest dich in einem riesengroßen Irrtum. Jürgen W. schrieb: > Im Moment einen m48. > Gerade nochmal mit Verify probiert. Meckert nur, wenn der Code kleiner > wird als der vorhergehende. Ist ja auch klar, da dann noch Reste vom > alten Code dahinter steht. > Ich hatte den Chip Erase Haken aber auch schon an anderen AVRs aus. Ging > immer ohne Problem. > > Einfach mal probieren. Auch wenn du gleich wieder beleidigt bist. DAS IST ABSOLUTER SCHWACHSINN!!! mfg.
Stefan Ernst schrieb: > Aber auch bei dem ist ein Löschen einzelner Pages über die > Programmier-Schnittstelle nicht möglich. Dachte ich bis eben auch. Hab mal ein paar Datenblätter aufgeschlagen. Den hinweis auf ein "Chiperase must be performed before..." hab ich nur bei Flashen über JTAG und Parallel Programming gefunden. Sollte es etwa doch so sein, wie es Jürgen schildert?
Hallo @Holger >Was ist das überhaupt für ein Board? Und nochmal: >WARUM BENUTZT DU DEN BOOTLOADER NICHT? >Watum gibts du darauf kein Antwort? ..derzeit habe ich (noch) keinen Levelconverter 5V To RS232 und deshalb noch mit dem AVRISP Später wird der dann über Bluetooth geflasht. Board ist ein BCA8-BTM-328. Bisher hatte ich nur mit Atmega8 und Atmega32/64 ohne Bootloader gespielt. Die Lockbits sind =0xEF LB=No memory lock features enabled BLBO= No lock on SPM and LPM in Application Section BLB1= SPM prohibited in Boot Section ..was das letzendlich bedeuted ist mir (noch) unklar...ich lern ja noch und versuche das zu erforschen. ...>>>scheiss Controller<<< das ist kein sch... Controller der ist schon OK Aber das hat doch mit der Ausgangsfrage nichts zu tun! Ich hatte gedacht, dass das ne einfache Frage ist. Aber wenn sich da die Experten schon uneinig streiten....
Skript Kiddy schrieb: > Stefan Ernst schrieb: >> Aber auch bei dem ist ein Löschen einzelner Pages über die >> Programmier-Schnittstelle nicht möglich. > > Dachte ich bis eben auch. Hab mal ein paar Datenblätter aufgeschlagen. > Den hinweis auf ein "Chiperase must be performed before..." hab ich nur > bei Flashen über JTAG und Parallel Programming gefunden. Sollte es etwa > doch so sein, wie es Jürgen schildert? Bei den Programmier-Befehlen gibt es aber kein Page-Erase, sondern nur ein Chip-Erase.
BootloaderHeini schrieb: > Ich hatte gedacht, dass das ne einfache Frage ist. Aber wenn sich da die > Experten schon uneinig streiten.... Es ist ja auch eine einfache Frage und von den Experten hast Du auch identische Antworten bekommen. ;)
BootloaderHeini schrieb: > Die Lockbits sind =0xEF > LB=No memory lock features enabled > BLBO= No lock on SPM and LPM in Application Section > BLB1= SPM prohibited in Boot Section dh. der Chip ist 'gelockt' , kein auslesen via isp aber mit einem eigenen Programm koenntest du den Bootloader auslesen, das muss aber zuerst per Bootloader rein. zur einfachen Frage: Andreas hat absolut recht, die Experten sind sich einig, nur sind hier leider auch DUMMSCHWAETZER unterwegs die nur nonsens u./o. beleidigungen von sich geben, wenn du aber laenger hier bist lenrst du die auch kennen & lieben ;) vlG Charly
Hallo, zunächst mal Danke für die Antworten @Charly das kann nicht ganz stimmen. Ich kann mit dem AVRISP den Atmega328P mit den oben gezeigten Fuses auslesen in einen HEX File und da kann ich unten das Programm erkennen: :100000000C94340018950000189500001895000015 :10001000189500001895000018950000189500002C :10002000189500001895000018950000189500001C :10003000189500001895000018950000189500000C ...... und oben den Bootloader: .... :107BD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB5 :107BE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA5 :107BF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF95 :107C00001AB884E08BB94A99ECC01124C1ECD1E0D8 :107C10001FBE8FEF98E09EBF8DBF1092C50089E117 :107C20008093C4001092C00088E18093C10086E078 :107C30008093C20082E40E94F53E83E40E94F53EF8 :107C400081E40E94F53E88E30E94F53E81E10E94B6 :107C5000F53E1092C001EE24FF248701AA24BB2424 ..... Ich konnte für mich (!) aus den Antworten noch nicht ergkennen ob ich den Bootloader irgendwie bei einem ERASE schützen kann vor dem flashen eines Programms im unteren Teil mit dem AVRISP. So dass der Bootloader weiterverwendet werden kann. Die Randbedingungen sind halt, dass ich via AVRIP und über Bluetooth alternative flashen will. Aber das sollte man hinnehmen und nicht diskutieren. Vielen Dank Rainer
BootloaderHeini schrieb: > Die Randbedingungen sind halt, dass ich via AVRIP und über Bluetooth > alternative flashen will. Aber das sollte man hinnehmen und nicht > diskutieren. Wenn du mit ISP programmierst, dann muß der Flash vorher gelöscht werden und der Bootloader ist Geschichte. Darüber muß man nicht diskutieren. Auch wenn einige das meinen. Wenn du den Bootloader erhalten willst, lädts du ihn herunter und sicherst ihn. Sofern das geht (Lockbits). Dann kannst du ihn nach deinen ISP-Experimenten wieder mit ISP draufspielen. Beides zusammen mit fliegendem Wechsel geht nicht. Das mußt du jetzt hinnehmen. Es sei denn, du schreibst dir einen Bootloader, der die Application Section auf Knopfdruck löscht. Dann kannst du diesen Teil des Flash neu beschreiben, ohne vorher per Chip Erase alles zu löschen. Das partielle, alse Page-weise, Löschen geht nur per Bootloader und nicht per ISP. Da geht nur alles oder nichts. mfg.
Weitere Alternative: Im Makefile für die Applikation die HEX-File-Generierung um eine Zeile ergänzen, in der ein weiteres HEX-File erzeugt wird, und zwar eine Kombination von Applikation- und Bootloader-HEX-File. Siehe dazu srec_cat.
BootloaderHeini schrieb: > Hallo, > > zunächst mal Danke für die Antworten > > @Charly das kann nicht ganz stimmen. Ich kann mit dem AVRISP den > Atmega328P mit den oben gezeigten Fuses auslesen in einen HEX File und > da kann ich unten das Programm erkennen: 100000Sorry, mein FEHLER, ich hab das No in LB=No memory lock features enabled uebersehen, dann ist aber alles doch supereinfach, Chip auslesen, Datei sichern und bei bedarf wieder reinproggen, oder den bootloader aus der datei extracten und einzeln o. mit der eigenen Soft zusammen reinproggen. vlG Charly
Stefan Ernst schrieb: > Applikation- und Bootloader-HEX-File. Das könnte man noch weiter ausbauen, indem man aus dem Bootloader-Hexfile die Binärdaten extrahiert, diese als Konstante in ein Headerfile packt und eine entsprechende Section einrichtet. Wenn dann die Headerdatei in die Anwendung gepackt wird, kopiert man den Bootloader automatisch hinein. mfg.
Hallo >Wenn du mit ISP programmierst, dann muß der Flash vorher gelöscht werden >und der Bootloader ist Geschichte. Das deckt sich mit meiner bisher gemachten Einstellung /Erfahrung. Durch die Beiträge oben war ich aber etwas unsicher geworden.... Natürlich habe ich erst mal Alles ausgelesen und gesichert. Das mit dem Bootloder wird mir so langsam klarer, dank der Beiträge. Ich muß aber erstmal auch den Bootloader verstehen. Es handelt sich um den KAVR ( http://sourceforge.net/projects/kavr/files/ ) Sehe jetzt etwas weiter in die Ferne... Vielen Dank Rainer
Thomas Eckmann schrieb: > Das könnte man noch weiter ausbauen, Und was soll der Vorteil dieses "Ausbaus" sein? Das Endergebnis ist das gleiche, nur der Weg ist viel komplizierter. Und bei meinem einfachen Weg hat man den zusätzlichen Vorteil immer beide HEX-Files zu haben, das mit und das ohne enthaltenen Bootloader. Bedenke, dass man das ohne ja auch braucht, nämlich dann, wenn über den Bootloader geflasht werden soll.
BootloaderHeini schrieb: > Ich muß aber erstmal auch den Bootloader verstehen. Zum Allgemeinverständnis: http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung mfg.
Stefan Ernst schrieb: > Und was soll der Vorteil dieses "Ausbaus" sein? Meine Güte, das wäre eine weitere Möglichkeit. Brauchst dich nicht gleich auf den Schlips getreten fühlen. Hat doch keiner gesagt, daß dein Vorschlag nichts taugt. mfg.
Thomas Eckmann schrieb: > Stefan Ernst schrieb: >> Und was soll der Vorteil dieses "Ausbaus" sein? > > Meine Güte, das wäre eine weitere Möglichkeit. > > Brauchst dich nicht gleich auf den Schlips getreten fühlen. Hat doch > keiner gesagt, daß dein Vorschlag nichts taugt. Ich fühle mich nicht auf den Schlips getreten. Ich fragte mich nur, warum man jemanden, der eh schon verwirrt ist, einen weiteren, komplizierteren Vorschlag macht, und ihm über den Terminus "Ausbau" auch noch suggeriert, dass der irgendwie besser wäre, als die bisher gemachten Vorschläge. Mich hat lediglich interessiert, worin dieses "besser" besteht. Kann ja auch sein, dass dein Vorschlag Aspekte hat, die ich nicht sehe.
Stefan Ernst schrieb: > und ihm über den Terminus "Ausbau" auch noch suggeriert, dass der > irgendwie besser wäre, als die bisher gemachten Vorschläge. Irgendwie hast du ein Problem, was. Also, erstmal habe ich keine Wertung meines oder der anderen Vorschläge vorgenommen. Deiner ist natürlich der Beste. Im makefile rumzueditieren ist ja auch ein Klacks. 2 Hexfiles zu mergen ist nicht ganz so elegant aber auch verdammt gut. Meine Scheißidee, entschuldige bitte, daß du mich darauf gebracht hast und ich das somit als Ausbau deiner Idee bezeichnet habe, ist natürlich überhaupt nicht zu gebrauchen. Ich ziehe meinen Vorschlag hiermit zurück. Nachdem man einmal auf dem PC das Bootloader-Hexfile in Binärdaten umgewandelt hat, diese Daten als Konstante in eine Headerdatei gepackt hat und dann mit 2 Schrägstrichen am Anfang seines Codes entscheiden kann, ob der Bootloader mit rein soll oder nicht, bringt man natürlich auch fortgeschrittene Programmierer an den Rand ihrer Fähigkeiten oder womöglich des Wahnsinns. Und der Compiler meckert auch noch rum, wenn der Anwendungscode den Bootloadercode überschreibt. Böser Compiler. Das kann man sich natürlich alles ersparen. mfg. PS: const char bootloaderdaten[] _attribute_ ((section (".bootload"))) = {<Binärdaten des Bootloaders>};
Thomas Eckmann schrieb: > Irgendwie hast du ein Problem, was. Du bist ja echt lustig. Du bist derjenige, der auf die persönliche Ebene geht, unsachlich wird und übertrieben reagiert, weil ich es gewagt habe, leise Kritik an deinem Vorschlag zu üben (unnötig kompliziert, ohne dass das einen Vorteil bringt), und dann soll ich derjenige sein, der sich auf den Schlips getreten fühlt, oder ein Problem hat? Den Rest kommentiere ich mal nicht weiter, sonst eskaliert das nur noch mehr. Nur noch einen kleinen Hinweis an BootloaderHeini: srec_cat meldet natürlich auch einen Fehler, wenn es Überschneidungen bei den beiden HEX-Files gibt.
Hallo na lasst es gut sein! >>jemanden, der eh schon verwirrt ist Ichweiße aber zurück, dass ich "VERWIRRT" bin.....eher der Wahrheit auf der Spur.... @Stefan >>Siehe dazu srec_cat. wo finde ich dafür ne Erklärung/Referenz? Danke Rainer
BootloaderHeini schrieb: >>>jemanden, der eh schon verwirrt ist > > Ichweiße aber zurück, dass ich "VERWIRRT" bin.....eher der Wahrheit auf > der Spur.... Sorry ;-) BootloaderHeini schrieb: >>>Siehe dazu srec_cat. > > wo finde ich dafür ne Erklärung/Referenz? http://linux.die.net/man/1/srec_cat oder wenn du WinAVR installierst hast auch auf deiner Festplatte unter WinAVR-XXXXXX\doc\srecord\srecord-X.XX.pdf In deinem Fall sieht der Aufruf in etwa so aus:
1 | srec_cat app.hex -Intel boot.hex -Intel -Output app_boot.hex -Intel |
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.