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