Hallo, ist es möglich den Bereich, in dem sich der Bootloader befindet, bei einem Flash Vorgang (Daten in den Applicationsbereich schreiben) NICHT zu überschreiben/löschen? Ich habe mir für mein ATmega 644 Projekt einen Bootloader geschrieben. Wenn ich nun aber an der Applikation weiter entwickle, fliegt der immer wieder raus und die Platine ist dann wieder ohne Bootloader. Das möchte ich vermeiden, ist das möglich? Nutze: - Atmel Studio 7 - JTAG MKII - ATmega 644 Danke Euch! Gruß AVRli...
Deine App wird nachher NUR NOCH vom Bootloader in den Käfer beschrieben. Alles paletti?
Horst S. schrieb: > Deine App wird nachher NUR NOCH vom Bootloader in den Käfer beschrieben. > Alles paletti? Ist für die Entwicklungszeit nicht ganz zufriedenstellend. Ja du kannst das unter den Projekteinstellungen ändern, also in den deines Programms nicht beim Bootloader. Da müsstest du sagen, nur den Flash Bereich des Prog. löschen. Dann nutzt er den Offset den du angegeben hast und lässt dein Bootloaderbereich unangetastet. edit: Bin grad nicht am PC sonst würd ich dir nen Screenshot machen.
:
Bearbeitet durch User
AVRli schrieb: > ist es möglich den Bereich, in dem sich der Bootloader befindet, bei > einem Flash Vorgang (Daten in den Applicationsbereich schreiben) NICHT > zu überschreiben/löschen? Nicht beim Programmieren von "aussen" bzw. höchstens in dem seltenen Ausnahmefall, dass kein Bit im Applikationsbereich von 0 auf 1 modifiziert werden muss. Im Normalfall ist das aber nötig, weswegen vor dem Programmieren von außen der Flash gelöscht (also komplett auf Einsen gesetzt) werden muss, was unwiderruflich auch den Bootloader entsorgt. Ein Bootloader hat diese Beschränkung nicht, denn er ist nicht darauf angewiesen, den gesamten Flash zu löschen, sondern kann das (Lösch-)seitenweise tun. Da stellt sich dann die Frage: Wenn du einen Bootloader hast, dessen Aufgabe ja vor allem ein Update der Applikation(en) ist, warum benutzt du ihn dann nicht auch für genau den Zweck, für den er gedacht ist? Das würde doch dein Problem ganz unmittelbar und vollständig lösen...
Adam P. schrieb: > Ja du kannst das unter den Projekteinstellungen ändern, also in den > deines Programms nicht beim Bootloader. Das wäre wohl genau das, was ich suche. Wenn Du die Zeit findet, wäre es toll mal ein Beisepiel zu zeigen. Danke! :-) c-hater schrieb: > Da stellt sich dann die Frage: Wenn du einen Bootloader hast, dessen > Aufgabe ja vor allem ein Update der Applikation(en) ist, warum benutzt > du ihn dann nicht auch für genau den Zweck, für den er gedacht ist? Ja es ist schon ein wenig die "Eier-Huhn-Frage" da muss ich Dir Recht geben. Klar im fertigen Projekt ist das natürlich keine Frage WIE der µC programmiert wird. Ausschließlich über den Bootloader! Nun zur Entwicklungszeit fänd ich es schon angenehm, wenn der Bereich beim einspielen der Application via JTAG eben nicht angefasst werden würde. Gruß AVRli...
AVRli schrieb: > Ja es ist schon ein wenig die "Eier-Huhn-Frage" da muss ich Dir Recht > geben. Eigentlich nicht. Entweder, es ist schon ein Bootloader verfügbar, dann benutzt man einfach den zum Update der Applikation. Oder es ist keiner verfügbar, dann flasht man ihn halt von "aussen" (und ggf. im selben Rutsch die aktuelle Anwendung). Es läuft eigentlich nur darauf hinaus, in der IDE den korrekten Weg für das aktuelle Erfordernis zu wählen (und natürlich vorher entsprechend einzurichten). > Nun zur Entwicklungszeit fänd ich es schon angenehm, wenn der Bereich > beim einspielen der Application via JTAG eben nicht angefasst werden > würde. Das ist einfach der falsche Grundansatz. Wenn du nur die Applikation einspielen willst, darfst du das halt einfach nicht via JTAG tun, sondern musst es über den Bootloader tun. Das ist schon alles. Wo ist das Problem?
AVRli schrieb: > Ja es ist schon ein wenig die "Eier-Huhn-Frage" da muss ich Dir Recht > geben. > > Klar im fertigen Projekt ist das natürlich keine Frage WIE der µC > programmiert wird. Ausschließlich über den Bootloader! Der Bootloader ist gerade während der Entwicklung der Applikation interessant. Dann kannst du die App bequem per bootloader updaten ohne den controller via JTAG zu flashen. Wenn die Applikation fertig entwickelt ist und es keine Updates mehr geben soll, kannst du den Bootlaoder in die Tonne treten. Denn du musst jeden neuen Chip den du bekommst sowieso per JTAG flashen, dann kannst du auch gleich die ganze applikation flashen.
MeineZweiCent schrieb: > Der Bootloader ist gerade während der Entwicklung der Applikation > interessant. Dann kannst du die App bequem per bootloader updaten ohne > den controller via JTAG zu flashen. Der Bootloader ist gerade während der Entwicklung der Applikation weniger interessant denn dort kann man die App bequem per JTAG updaten und debuggen. Erst in der Produktion oder für ein späteres Firmware-Update erweist sich ein Bootloader als nützlich.
Bernd K. schrieb: > Der Bootloader ist gerade während der Entwicklung der Applikation > weniger interessant denn dort kann man die App bequem per JTAG updaten > und debuggen. Erst in der Produktion oder für ein späteres > Firmware-Update erweist sich ein Bootloader als nützlich. Ja, klingt irgendwie logisch. Aber: wenn er während der Entwicklung nicht benötigt wird, dann schadet es doch auch nicht, wenn er garnicht vorhanden ist, oder? Wo also ist das Problem?
Bernd K. schrieb: > Der Bootloader ist gerade während der Entwicklung der Applikation > weniger interessant denn dort kann man die App bequem per JTAG updaten > und debuggen. Kommt auf die Applikation an. Ich glaube nicht dass der TE mit seinem AVR Projekt in die große Produktion geht oder wahnsinnig viele Software updates on the fly via Bootloader aufspielen muss :D
Idealer Weise sollte der Bootloader für die Applikation als nicht vorhanden erscheinen, d.h. in der Entwicklung per JTAG kann man den Bootloader ganz einfach weglassen. Der Code rauscht dann durch die 0xFFFF durch, die quasi wie NOPs wirken, bis er auf Adresse 0x0000 überläuft und die Applikation startet. Will man aber testen, ob der Bootloader sich negativ auf die Applikation auswirkt, dann erzeugt man einfach ein HEX des Bootloaders, entfernt die letzte Zeile (Enderecord) und fügt ihn per Batch vor die Applikation ein.
Ich möchte das meine Freunde ihre Hardware nicht immer zu mir schicken müssen, wenn ich etwas an der Applikation geändert habe. Peter D. schrieb: > Will man aber testen, ob der Bootloader sich negativ auf die Applikation > auswirkt, dann erzeugt man einfach ein HEX des Bootloaders, entfernt die > letzte Zeile (Enderecord) und fügt ihn per Batch vor die Applikation > ein. Genau das möchte ich überprüfen! Ich könnte den den Bootloader so zu sagen auch jedes mal unten dran hängen, wenn ich die Applikation neu einschreibe? Gruß AVRli...
Habe es hin bekommen, kann nun meine Applikation Testweise mit Bootloader flashen. Habe noch ein Problem mit dem Bootloader aber dazu mache ich lieber ein neues Thema auf... Vielen Dank und schöne Grüße! AVRli...
Bitte 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.