mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bootloader Grundkenntnisse


Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: 2918 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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)"

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: 2918 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 2918 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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")

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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ß

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: 2918 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Dominik (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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ß

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nachtrag:

oder werden hier wieder die words addressiert ??

ist wohl doch schon ein paar semester her das ich mit damit beschäftigt 
habe!

gruß

Autor: DD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: DD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Dominik (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>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ß

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist übrigens sehr nett..

und sorry für die .o .hex und .elf hab wohl mal wieder gehandelt ohne zu 
denken.

gruß

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dominik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: DD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Rudi D. (rulixa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.