guten abend zusammen. Da meine USB Firmware jetzt endlich funktioniert möchte ich zum nächsten Thema übergeh. Dem schreiben eines Bootloaders! Da mir leider noch jegliche Theorie fehlt und im Forum zwar viele Beiträge zu spezifischen problemen sind meine frage ob es vielleicht so etwas wie ein gutes buch oder ein tutorial oder eine gute internet seite dazu gibt. prinzipiell hab ich das schon verstanden wie ein bootloader funktioniert, jedoch hört mein wissen auch schon wieder auf wenn es darum geht den bootloader in die NRWW Section meines AT90USB162 zu platzieren. Nur um mal ein Beispiel zu nennen. wäre nett wenn ihr mir etwas infomaterial oder links posten könntet.. danke gruß
An sich geben die Datenblätter der Controller genügend Auskunft zum Schreiben eines Bootloaders unter Assembler. Zumindest ist dies bei den Tinys und ATMEGA AVRs der Fall.
da taucht auch schon ein problem auf ich will C benutzen dachte da an die boot.h jedenfalls sah die recht vernünftig aus.. und leider hab ich im datenblatt nichts im bezug darauf gefunden wie ich zb. den Bootloader in der NRWW ablege.
In Assembler geht das mittels der .org Direktive, die den Code an die angegebene Adresse verschiebt, an die der Code beim Flashen dann geladen wird. Das .org ist auch in C als Inline-Assembler einzubinden.
Hallo Dominik Ich kann dir leider auch nicht weiter helfen, denn ich dachte eher dass du mir vielleicht helfen kannst? Überall trifft man diesen Ausdruck bootloader an, nur ich habe bis jetzt nicht herausgefunden wozu das dient? was ist ein bootloader, welche Funktionen erfüllt dieser?
Ein Bootloader programmiert die firmware ins flash. Er kann den Code projektspezifisch irgendwo her nehmen, von der seriellen Leitung, von einer SD Karte, vom Ethernet, und das muss man ihm beibringen. Ich kann eigentlich nur ASM empfehlen. Das andere ist zuwenig kompakt. Man hat teilweise nur 1000 ASM Befehle, zB bei den Mega16.
@ 2918 >Ich kann eigentlich nur ASM empfehlen. Bullshit ;) Das geht locker in C: Beitrag "MMC/SD Bootloader füt ATMega16" Beitrag "SD/MMC Card Bootloader (passt in 2kb bootsection)"
Also normallerweise programmiert man den Mikrocontroller ja über die ISP-Schnittstelle! Wenn man jetzt einen Bootloader hat, so ist man nicht mehr an diese gebunden, verstehe ich das richtig?
Hallo, ich habe mir auch einen Bootloader in C geschrieben. ASM wäre zwar von der Codegröße kleiner, aber C ist wartbarer und portierbarer. Bei ASM kann man den in 512 bytes quetschen, bei C braucht man halt 1k. Das ist eigentlich wurscht, da ich meine CPU's immer so auslege,das ich immer genügend Reserven im Speicher habe. Ist bei den geringen Preise auch kein Problem. Ein Bootloader kann den ISP zum Programmieren ersetzen. Da man oft sowiso eine z.B. USB Schnittstelle dran hat, nutzt man einfach diese. Der Bootloader muß allerdings immer zuerst per ISP auf die CPU drauf. Außerdem müssen die FUSE Bit's entsprechen gesetzt werden. Da der Bootloader in den für ihm bestimmten Speicherbereich soll, wird schon im Makefile die entsprechende Adresse gesetzt. Die ist je nach CPU und Bootloadergröße anders. Das steht im Datenblatt. Jogibär
Dominik wrote: > da taucht auch schon ein problem auf ich will C benutzen dachte da an > die boot.h jedenfalls sah die recht vernünftig aus.. Dein Problem ist also nicht der Bootloader, sondern C. Ein Bootloader ist in Assembler nämlich ne ganz einfache Sache, immer stur der Beschreibung im Datenblatt nach, fertig. Und da auch nirgends komplizierte Arrays, Structuren, Berechnungen usw. benötigt werden, kann ein Bootloader in keinster Weise von C profitieren. Und da die Bootfunktionen in den verschiedenen MC-Typen unterschiedlich sind, sind sie auch unter C nicht portierbar. Einen Bootloader in C zu schreiben ist nur sinnvoll, wenn man Filesysteme oder TCP/IP implementieren will, um die Daten zu lesen (ab ATmega64 aufwärts). Dann hat man aber wieder das Problem, das selbst die größte Bootsize nicht ausreicht und Programmteile unter den Bootloader umgelinkt werden müssen. Man kann es sich also einfach machen und nen Bootloader in Assembler schreiben. Oder man geht den steinigen Weg in C. Dann viel Vergnügen beim Lesen der Beiträge hier und im AVRFreaks. Irgendwo steht schon alles, was man dazu braucht (englisch lesen sollte man aber können). Im AVRfreaks gibts kilometerlange Beiträge, wie man unter C überhaupt erstmal in die Bootsektion plaziert und wie man unnützes wegoptimiert, Registernutzung erzwingt, damit er noch in 512 Worte paßt. Es ist auch unter Assembler wesentlich einfacher die verschiedenen AVRs zu supporten. Ich habe für ATtiny13 bis ATmega2561 nur 3 verschiedene Schreibroutinen implementiert (Attiny, ATmega, ATmega >64kB). Peter
>Einen Bootloader in C zu schreiben ist nur sinnvoll, wenn man >Filesysteme oder TCP/IP implementieren will, um die Daten zu lesen (ab >ATmega64 aufwärts). Das ist ja wohl der größte Schwachsinn den ich je gelesen habe.
Hallo, ich weiß natürlich, das Peter nicht irgendwer ist. Aber da muß ich Dir wirklich beipflichten. Ich sehe da auch keinen Zusammenhang. Wenn das Hauptprogramm läuft, ist der Bootloader komplett aus dem Spiel. Mir ist es auch zu hoch, was diese Aussage soll. Jogibär
Ich muss dem Peter beipflichten. Es gibt keine C-library, die dir hilft. Der Bootloader ist irgend ein Protokol auf irgendwas, viel IO ansprechen, Register laden, timing beachten und portabel auf eine andere Familie isses eh nicht. Keine Stringbearbeitung, Keine Mathlibrary, kein floatingpoint. Das Hex_to_bin konnt ich noch selbst. Das war's.
Hallo, schau mal folgende LIB an : #include <avr/boot.h> Funktioniert super, jedenfalls bei mir. Ohne irgendwelche Verrenkungen. Die einzigste "ASM Anweisung ", die ich benutze ist NOP. Jogibär PS: ZITAT: Keine Stringbearbeitung, Keine Mathlibrary, kein floatingpoint. Ich dachte, hier geht es um einen Bootloader. ( Immer diese "Gast Poster")
>Keine Stringbearbeitung, Keine Mathlibrary, kein >floatingpoint. Ein C Compiler zieht sich nicht automatisch die kompletten Funktionen für Stringbearbeitung oder ne komplette Floatingpoint Lib rein solange man es nicht von ihm verlangt.
holger wrote: >>Keine Stringbearbeitung, Keine Mathlibrary, kein >>floatingpoint. > > Ein C Compiler zieht sich nicht automatisch > die kompletten Funktionen für Stringbearbeitung > oder ne komplette Floatingpoint Lib rein solange > man es nicht von ihm verlangt. Hallo, ist ja richtig. Blos wozu brauche ich das in einem Bootloader ? Man braucht werde Math noch float noch String ?!? Jogibär
holger wrote: >>Keine Stringbearbeitung, Keine Mathlibrary, kein >>floatingpoint. > > Ein C Compiler zieht sich nicht automatisch > die kompletten Funktionen für Stringbearbeitung > oder ne komplette Floatingpoint Lib rein solange > man es nicht von ihm verlangt. Damit war gemeint, daß C Vorteile hat, weil diese Funktionen in C mit drin sind. In Assembler müßte man sie zu Fuß erledigen. Aber wenn man die alle nicht braucht, hat C keine Vorteile mehr gegenüber Assembler. Ich hatte ganz kurz überlegt es in C zu machen. Ich mußte es aber schnell aufgeben, da Autobauding mit Timeout, 1-Draht UART und RJMP-Remapping in C nicht zu machen war. Hier ist Assembler ganz eindeutig im Vorteil. Ich mußte auch nicht lange überlegen, wie ich die 24Bit Adresse beim ATmega2561 realisiere (nimm einfach ein Register mehr). Die weitaus größere Zeit habe ich für das PC-Frontend gebraucht. In Assembler ist auch schön, daß die ganzen Adressen (Secondbootstart) und Device-Kodes im h-File mit drin sind. Für nen anderen AVR muß man nur das Include ändern, fertig. Peter
ok irgendwie hilft mir das nicht wirklich weiter.. ich denke schon das das in C machbar sein sollte, wenn ich mir die boot.h so anschau dann besteht die ja auch nur aus inline assembler und macros dann schreib ich mir das mit meinem nichtwissen vorgestellt habe 1.Schreiben der Application (eigenständiges projekt hat nichts mit bootloader zu tun) 2.schreiben des Bootloaders und platzieren in der NRWW Section des Flashes 3. Resetvektor = anfangsadresse Bootloader Den Bootloader hätte ich dann so aufgebaut: 1. initialisieren der USB Schnittstelle (enumeration und Endpointaktivierung) 2. lesen eines Befehls den ich über USB schicke -> daraufhin wird entschieden ob ich mit einem Jump zur Application oder weiterhin im bootloader bleibe. 3. Page Erase durchführen 4. temporären buffer mit den Daten(Hexfile der Application) die ich über USB empfange füllen 5. page_write durchführen 6. danach muss ich wahrscheinlich noch eine überprüfung der geschriebenen daten durchführen. 7. springen zur Application so jetzt hoffe ich das ich nicht in der Luft zerrissen werde. ach ja die Bootlockbits sollten natürlich dem entsprechend gesetzt sein das zb der Inhalt des RWW auch verändert werden kann. gruß
Also vorab mal kurz zu Peter Dannegger und 2918: C hat schon seine Vorteile auch für Bootloader wenn man sehr gut Assembler programmiert kann man sicherlich etwas weniger Codegrösse rausschlagen aber wenn man bei C ein wenig überlegt und sich ab und zu mal den resultierenden Code anschaut kommt man meisst auf die selben grössen wie beim Assembler. Außerdem kann man den resultierenden Bootloader auch auf anderen Controllern einsetzen ich hab z.b. ein Projekt wo Atmega8, 88 und 168 eingesetzt werden kann da möcht ich nicht nen Bootloader 3x schreiben. Zumal usb beim Bootloader sicherlich nicht so abwegig ist wie Filesysteme und TCP/IP und das möchte aber sicher auch niemand mehr in Assembler machen. So nun zu deiner Frage Dominik das man in c .org als innline Assembler verwenden soll ist natürlich totaler Schwachsinn da der Linker sich sicherlich nicht an das org halten wird. Richtiger ist das du dem Linker einen Parameter mitübergeben musst wohin die .text Section soll. Das machst du mit -Wl,--section-start=.text=ADRESSE beachten musst du hier auch noch das die Adresse in Hex angegeben wird und im Datenblatt glaub ich Wortweise angegeben wird also z.b. Atmega168 Datenblatt = 1C00 -Wl,--section-start=.text=3800 Im AVRStudio kannst du die Option z.b. unter Custom Options->Linker Options einfügen wenn du mit Makefiles arbeitest natürlich direkt dem Linker mitübergeben
@ Christian Danke für die antwort.. allerdings muss ich sagen bin ich mir nicht sicher ob das funktioniert.. ich hab das mal so wie oben geschrieben im arv in den linkereinstellungen mit eingebunden als startadresse habich 0x3800 angegeben das ist auch die adresse die mir das Datenblatt sagt und die mir das AVRstudio bei den fuses anzeigt. mein problem ist das es immer den code ausführt selbst wenn ich mittels der BOOTRST Fuse die startadresse auf 0x0000 lege.. versteh ich da was falsch? wenn doch der Bootloader an adresse 0x3800 liegt und ich keine application habe dürfte doch der Controller nicht los laufen da an adresse 0x0000 nichts ist. gruß
>versteh ich da was falsch? wenn doch der Bootloader an adresse 0x3800 >liegt und ich keine application habe dürfte doch der Controller nicht >los laufen da an adresse 0x0000 nichts ist. Ja, das verstehst Du falsch, ist aber nicht schlimm. Wenn der Controller auf Adresse $0000 mit seiner Arbeit beginnen soll und dort $FF vorfindet, läuft er automatisch weiter. Dies geschieht so lange, bis er auf einen gültigen Befehl (oder eine Kette von gültigen Befehlen) trifft. Ist der erste gültige Befehl Dein Bootloader, so wird dieser auch ausgeführt.
Es sind alles gueltige Befehle. Ob sie was Gescheites machen ist eine andere Frage. Der Bootloader muss nach 0x0000 springen, wasauchimmer dort ist. Ausser der Bootloader testet, ob dort eine Applikation ist. Was soll er denn machen, wenn keine Applikation dort ist ? Heulen ?
Angehängte Dateien:
-
fuses2.JPG
510 KB
ah das ist schon mal gut zu wissen.. das nächste problem auf das ich treffe ist das wenn ich ins Datenblatt vom AT90USB162 schaue (siehe Anhang Bild2) und das dann mit den Fuses die ich im AVRstudio einstellen kann vergleiche (siehe Bild1) kann da doch was nicht stimmen. die nächste frage ist: wenn ich den bootloader bei $3800 ablege und mir im AVRstudio den Code vom Disassembler anschaue geht der nur bis $1FFF wie kann ich dann den bootloader an $3800 verschieben .. thx gruß
>das nächste problem auf das ich treffe ist das wenn ich ins Datenblatt >vom AT90USB162 schaue (siehe Anhang Bild2) und das dann mit den Fuses >die ich im AVRstudio einstellen kann vergleiche (siehe Bild1) kann da >doch was nicht stimmen. Anzahl BYTES = 0.5x Anzahl WORDS, passt schon
@ Travel Rec. recht hast du wer lesen kann ist klar im vorteil.. ich sitz heute aber auch wieder auf der leitung .. aber die zweite Frage versteh ich immer noch nicht: ich hab doch 16KB Flash (0x0000 - 0x3FFF) davon will ich 4KB für den Bootloader (0x3000 - 0x3FFF) das heißt der Bootloader beginnt nach 12KB -- damit ist doch meine Startadresse des Bootloaders bei 0x3000 warum zeigt mir jetzt das AVRstudio um Debugger nur Adressen bis 0x1FFF(8KB) an. den richtigen uC hab ich aber ausgewählt. gruß
nachtrag: oder werden hier wieder die words addressiert ?? ist wohl doch schon ein paar semester her das ich mit damit beschäftigt habe! gruß
ich hätte da noch eine frage.. da ich nur 4KB für den Bootloader samt usbfirmware habe: gibt es eine möglichkeit die USB Frimware zwar im RWW zu platzieren so das ich im bootloader in der NRWW Section die Usb nutzen kann. beim flashen mittels bootloader dürfte der Bereich an dem die usbfirmware liegt halt nicht verändert werden.. also so in etwa |---------------| | main |<--| | RWW | | |---------------| | | RWW | | | | |update mittel Bootloader |---------------| | | usb firmware | | | RWW | | |---------------| | | Bootloader |---- | NRWW | |---------------| Ich brauch die USB Schnittstelle ebenfalls in der main. gruß
Zum Thema USB-Bootloader vom mir mal eine grundsätzliche Frage: Der AT90USB1287 wird von Atmel ja mit einem Bootloader ausgeliefert, der dann von Atmels Tool "Flip" (oder unter Linux mit dfu-programmer) angesprochen werden kann. Von Atmel gibt es dazu auch einige Infos. Sollte man versuchen, einen eigenen Bootloader kompatibel zu Atmels Bootloader zu machen, so dass man ihn auch mit "Flip" benutzen kann? (Wenn man darauf verzichtet, wird es wohl deutlich einfacher -- dann kann man ja verfügbare UART-Bootloader so anpassen, dass die Daten eben über USB eingelesen werden.)
Naja also grundsätzlich gehts mir ja darum mal sowas selber gemacht zu haben. das das ding dann vielleicht kein voll kompatibler bootloader wird ist mir erstmal egal.. ich hab mir mal das DFU Bootloader pdf angeschaut und so wie ich das sehe nutzen die von atmel zur übertragung der daten Control Transfers und die Befehle werde dann einfach mit Class Requests bearbeitet. leider hab ich die sourcen zum bootloader für die AT90USB reihe nirgends gefunden. Und das größte Problem ist auch das ich meine USB Frimware auch wenn ich nur die nötigsten Standart Requests behandle nicht in die Bootsection bekomme das mag jetzt an meiner unfähigkeit liegen oder weil das einfach ne gewisse größe braucht. ich wollte die Datenübertragung dann auch mit einem Bulk Endpoint mach und die Steuerbefehle über den normalen Control Endpoint. gruß
>leider hab ich die sourcen zum bootloader für die AT90USB reihe nirgends >gefunden. Auch das Hex-File ist ja erst seit einigen Monaten frei verfügbar. Als ich mir vor einem Jahr bei einem Chip versehentlich den Bootloader überschrieben hatte, musste ich Atmel bitten, mir das File zu schicken -- was sie auch gemacht haben. >Naja also grundsätzlich gehts mir ja darum mal sowas selber gemacht zu >haben. das das ding dann vielleicht kein voll kompatibler bootloader >wird ist mir erstmal egal.. Naja, ich denke man sollte sich schon entscheiden. Irgendwann will ich meine GPL USB-Firmware auch mal um einen Bootloader erweitern, dann muss ich mich auch entscheiden. >Und das größte Problem ist auch das ich meine USB Frimware auch wenn ich >nur die nötigsten Standart Requests behandle nicht in die Bootsection >bekomme Wie groß ist die Bootsection bei deinem Chip? Bei meinem AT90USB1287 soweit ich mich erinnere 2,4,8, evtl auch 16kByte. Ich denke mit 4kByte kommt man in C gut aus (Meine komplette Demoanwendung ist ohne Debugging-Code auch nur ca. 4kByte groß.) Aber in 2kByte wird man das zumindest mit C nicht hineinquetchen können, jedenfalls ich nicht. Aber was solls, der AT90USB1287 hat 128 kByte Flash, wenn da vier kByte weg gehen ist das nicht tragisch. Gruß Stefan Salewski
naja mit dem AT90USB162 bin ich mitlerweile nicht mehr so zufrieden der hat nur 16KB und was echt blöd ist nur 512Byte sram mir geht so langsam der sram aus.. der ist mitlerweile schon nur für die Firmware zu 66% voll. >Wie groß ist die Bootsection bei deinem Chip? Bei meinem AT90USB1287 >soweit ich mich erinnere 2,4,8, evtl auch 16kByte. Ich denke mit 4kByte >kommt man in C gut aus (Meine komplette Demoanwendung ist ohne >Debugging-Code auch nur ca. 4kByte groß.) Aber in 2kByte wird man das >zumindest mit C nicht hineinquetchen können, jedenfalls ich nicht. Aber >was solls, der AT90USB1287 hat 128 kByte Flash, wenn da vier kByte weg >gehen ist das nicht tragisch. Bootloader kann ich maximal 4KB reservieren. Ich brauche mitlerweile allerdings nur für die firmware ca 6KB irgendwas mach ich scheinbar falsch den es geht ja auch kleiner wie man sieht.. nur hab ich leider keine ahnung wie ich das noch groß reduzieren kann.
>naja mit dem AT90USB162 bin ich mitlerweile nicht mehr so zufrieden der >hat nur 16KB und was echt blöd ist nur 512Byte sram mir geht so langsam >der sram aus.. Ich hätte den AT90USB162 auch nur für Massenauslieferung, wo es wirklich extrem auf die Stückkosten ankommt, eingesetzt. Außer den Paar Euro Preisvorteil gegenüber dem AT90USB1287 hat er doch keine Vorteile, Gehäuse gibt es ja auch nur in SMD. >Bootloader kann ich maximal 4KB reservieren. Ich brauche mitlerweile >allerdings nur für die firmware ca 6KB irgendwas mach ich scheinbar >falsch den es geht ja auch kleiner wie man sieht.. nur hab ich leider >keine ahnung wie ich das noch groß reduzieren kann. Na dann vergleiche doch mal mit meiner Firmware. Oder sieh Dir das Assemblerlisting des Compilers an. Da Du Deinen Code nicht zeigen magst, wird Dir diese Arbeit keiner abnehmen können.
>Ich hätte den AT90USB162 auch nur für Massenauslieferung, wo es wirklich >extrem auf die Stückkosten ankommt, eingesetzt. Außer den Paar Euro >Preisvorteil gegenüber dem AT90USB1287 hat er doch keine Vorteile, >Gehäuse gibt es ja auch nur in SMD. Die Entscheidung kann ich leider nicht mehr rückgängig machen jetzt muss ich mit dem AT90USB162 leben :-( >Na dann vergleiche doch mal mit meiner Firmware. Oder sieh Dir das >Assemblerlisting des Compilers an. Da Du Deinen Code nicht zeigen magst, >wird Dir diese Arbeit keiner abnehmen können. so ist das gar nicht ich hatte da schlicht und einfach nicht drann gedacht.. werde den Code morgen mal posten da ich ihn grad nicht da habe.
>Die Entscheidung kann ich leider nicht mehr rückgängig machen jetzt muss >ich mit dem AT90USB162 leben :-( Verstehe ich nicht ganz. Die Firmware sollte für 162 bzw. 1287 doch fast identisch sein. Zumindest sehr ähnlich. Ich hatte euch ja schon im August gefragt, warum ihr nicht den 1287 nehmt: Beitrag "AT90USB162 initalisierung" Oder war das ein anderer Dominik? >werde den Code morgen mal posten da ich ihn grad nicht da habe. Gut. Bei größeren Projekten ist es aber noch besser, wenn man die Sachen irgendwo zum Download ablegt. Gruß Stefan Salewski
>Verstehe ich nicht ganz. Die Firmware sollte für 162 bzw. 1287 doch fast >identisch sein. Zumindest sehr ähnlich. >Ich hatte euch ja schon im August gefragt, warum ihr nicht den 1287 >nehmt: >Beitrag "AT90USB162 initalisierung" >Oder war das ein anderer Dominik? nein ich bin schon der selbe nur parallel dazu hat jemand anderst bereits ein layout und ein platine entworfen (der AT90USB162 dient lediglich als USB - SPI Bridge) das müsste sonst alles nochmals geändert werden. Zudem hat der 1287 doch noch ein paar Register die es im 162 nicht gibt. >Gut. Bei größeren Projekten ist es aber noch besser, wenn man die Sachen >irgendwo zum Download ablegt. So ich hab das mal gepackt angehängt hoffe das funktioniert. gruß
Ok, runtergeladen und entpackt habe ich es. Aber warum hast Du denn die .o .hex und .elf Dateien mit ins Archiv gepackt? Ohne die wäre es deutlich kleiner und zudem übersichtlicher. Ich werde in den nächsten Tagen mal einen Blick in die Quelltexte werfen und mal sehen, wie man die Binärcodegröße verkleiner kann.
das ist übrigens sehr nett.. und sorry für die .o .hex und .elf hab wohl mal wieder gehandelt ohne zu denken. gruß
Hallo Dominik, ich habe deinen Quellcode mal kurz überflogen. Der Code ist ja noch recht überschaubar und weite Teile sind meiner Firmware sehr ähnlich. Bisher sehe ich nichts, was übermäßig viel Binärcode erzeugen sollte. Hast Du eventuell ganz ohne Optimierung compiliert? Mit avr-gcc nutze ich -Os, mit -O0 bekomme ich für mein Demoprogramm auch 6kByte statt 4kByte. Die Zeilen ## Compile options common for all C compilation units. CFLAGS = $(COMMON) CFLAGS += -Wall -gdwarf-2 -O0 CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d in Deinem Makefile deuten darauf hin -- allerdings weiß ich nicht ob WINAVR das Makefile überhaupt beachtet oder die Optionen anderweitig bezieht. Überprüfe das bitte zunächst mal. Gruß Stefan
das ging aber schnell vielen dank! und so einfach gehts G man muss einfach nur Os einstellen und schon bin ich bei 3KB Jetzt kann ich mich wieder der implementierung des Bootloaders widmen. was mich dann mehr oder weniger wieder zu der frage bringt. |---------------| | main |<--| | RWW | | |---------------| | | RWW | | | | |update mittel Bootloader | | | | | | | | | |---------------| | | Bootloader |---- | usb firmware | | NRWW | |---------------| theoretisch müsste das so gehen da der Komplette USB - Datenaustausch (IN Interrupt und OUT Bulk) ja in der Interruptroutine abgehandelt wird. wahrscheinlich muss ich die Vectortabelle in den Bootloaderbereich verschieben da ich mir diese sonst beim flashen überschreiben würde. seh ich das richtig? gruß
soo eine erste zwar noch sehr rudimentäre version des Bootloaders läuft allerdings noch UART im moment. Sobald das ganze mit USB implementiert ist werde ich den code mal posten danke für die hilfen gruß
Ich brauche bitte auch etwas Nachhilfe. Ich verwende das Lernpaket uC von Franzis mit tiny13 und der Bootloader der da dabei ist liegt von 0x17e bis 0x1fd ist also sehr winzig. Bei 0x17E steht ein rjmp auf das Anwenderprogramm bei 0x10 (nach den Int. Vektors). Der übliche Verlauf ist nun so, dass man mit dem AVR Assembler ein Programm schreibt, das am Resetvektor den Rjmp auf das Anwenderprogramm hat. Wenn man es mit dem beschriebenen Bootloader lädt, wird der Resetvektor in der .hex file auf auf 0x180 verbogen und man gelangt über 0x017E dann endlich ins Anwenderprogramm. Da dieses Windowsprogramm, das den Restvektor verbiegt nicht als Source vorliegt, hätte ich gerne gewußt, wenn ich z.B. Ponyprog für den tiny2313 verwenden will, wie ich am Resetvektor rjmp 0x180 eintrage, wenn das Anwenderprogramm viel kürzer ist. Sonst überschreibt es ja den Bootloader. Mir fällt nur ein, diesen Rjmp als databytes einzutragen. Oder gibts eine Assembleranweisung, die auch auf außerhalb des Programmes liegende Adressen springen kann? LG aRudi
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.