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...
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.
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...
