Aufblasbarer Flash im Atmega8?

Gast #1052388
Hallo,

ich habe hier gerade folgende Geschichte erlebt, auf die ich mir keinen 
Reim machen kann:

Vor einiger Zeit hatte ich mal eine Software für den Atmega8 
geschrieben. Die wurde auch schon auf einigen Geräten der Kleinserie 
aufgespielt und läuft mit zwei kleineren Bugs. Soweit, so gut. Damals 
habe ich AVRStudio nur zum Programmieren der Kontroller benutzt, 
Kompiliert wurde mit WinAVR von der Kommandozeile aus.
Soweit, so gut. Heute wollte ich mich endlich daran machen, eine neue 
Version zu schreiben und die Bugs zu beseitigen. Diesmal von AVRStudio 
aus, mit WinAVR als Plug-In. Ein Compilierversuch mit den alten Sourcen 
lieferte dann die Felhermeldung "region text is full". Aha. Das Programm 
soll also zu groß für den Flash des Atmega8 sein. Kann ja gar nicht 
sein, dachte ich mir, denn früher war diese Felhermeldung nie 
aufgetaucht. Also, nachgeschaut, wie groß der Flash ist -> 8kB. Dann 
nachgeschaut, wie groß das Hex-File ist, mit dem unser Lieferant die 
Geräte im Auftag geflasht hat: -> 10kB.

Warum, zum Geier, ließen die Prozessoren dann bisher problemlos flashen?

Gruß,
Harald
#1052399
@ Harald (Gast)

>aus, mit WinAVR als Plug-In. Ein Compilierversuch mit den alten Sourcen
>lieferte dann die Felhermeldung "region text is full". Aha. Das Programm

Optimierung eingeschaltet? Teilweise erzeugen neuere WinAVR Versionen 
grössere Binärdatein.

>nachgeschaut, wie groß das Hex-File ist, mit dem unser Lieferant die
>Geräte im Auftag geflasht hat: -> 10kB.

Ein Hexfile ist KEIN Binärfile, sondern hat ASCII Format, kann man mit 
jedem beliebigen Texteditor ansehen. Darum ist es reichlich doppelt so 
gross wie das reine Binärfile. Such mal nach Intel Hexfile.

MFG
Falk
Gast #1052400
Hex ist nicht Bin !
In der Hexdatei steht noch mehr drin!

Überprüf mal die Options für den Compiler bzgl. Optimierung,
mit einer anderen Einstellung sollte es wieder passen.

Gruß hans
#1052493
@ Harald (Gast)

>warum verlangt AVR-Studio dann als Eingabe ein Hex-File?

War schon immer so. Der Assembler vom AVR-Studio bzw. der WinAVR 
Compiler erzeugen ein Hexfile, welches dann binär in den AVR 
programmiert wird.

> Wird dieses
>Hexfile von AVR-Studio nochmals in ein Binärformat gewandelt?

Ja.

MFG
Falk
Gast #1052539
übrigens, falls es sich nicht um einen fehler in der optimierung 
handelt: es gibt den mega168. code- und pinkompatibel zum mega8, aber 
mit 16kB flash - und noch weiteren neuen features.

grüße, holli
#1052542
Michael H* wrote:
> es gibt den mega168. code- und pinkompatibel zum mega8,
Pinkompatibel ja, Code-kompatibel NEIN. Allein eben die Tatsache, dass 
der Mega168 mehr als 8 KiB Flash hat (was die magische Grenze für die 
relativen Sprungbefehle darstellt), führt dazu, dass der Assembler-Code 
nicht kompatibel ist! Der Mega168 hat nebenbei schon einen extended 
I/O-Space, der beim Mega8 nicht vorhanden war/ist. Und für den Zugriff 
auf Register in diesem Bereich müssen andere Befehle verwendet werden, 
als für die "normalen" I/O-Register.

Auch auf C-Ebene gibt es eine Reihe Unterschiede, v.a. in Sachen 
Registernamen.
Gast #1052551
okay, okay. nachdem er aber von winavr redet, geh ich von C aus. und da 
sind die definitionen entsprechend gewählt, dass der code für beide 
compiliert werden kann.
dass man nicht einfach ein .hex file für beide flashen kann, hab ich mal 
als grundwissen vorausgesetzt ^^
Gast #1052558
immer diese editierer =)
also man kann definitiv code für den mega8 ohne eine einzige umstellung 
- außer das flag für die mcu =) - für einen mega168 compilieren.
richtig, komplett code-kompatible sind sie nicht. aber der mega168 ist 
code-abwärtskompatibel, solange es um C geht.
#1052574
Michael H* wrote:
> also man kann definitiv code für den mega8 ohne eine einzige umstellung
> - außer das flag für die mcu =) - für einen mega168 compilieren.

Nein!

> richtig, komplett code-kompatible sind sie nicht. aber der mega168 ist
> code-abwärtskompatibel, solange es um C geht.

RTFM! Ich sag nur als Beispiel TIMSK <-> TIMSK0, TIMSK1, TIMSK2
Gast #1052584
holla, tatsächlich... dann entschuldigung.
da hatte ich wohl zwei andre im kopf.

nachtrag: aber pinkompatible bleibt er. und falls er als ersatz in frage 
kommt:
AVR094: Replacing ATmega8 by ATmega88
http://www.atmel.com/dyn/resources/prod_documents/doc2553.pdf
AVR095: Migrating between ATmega48, ATmega88 and ATmega168
http://www.atmel.com/dyn/resources/prod_documents/doc2554.pdf
vllt hab ich ja damit doch was sinnvolles von mir gegeben ^^
#1052596
Harald wrote:

> nachgeschaut, wie groß das Hex-File ist, mit dem unser Lieferant die
> Geräte im Auftag geflasht hat: -> 10kB.

Das ergibt dann etwa 3,5kB Code, paßt also dicke in den ATmega8.

Selbst mit einigen Codevergrößerungen des neuen WINAVR bist Du weit weg 
von den max 8kB.

Versuch mal die Optimierung -Os.
Falls Du float benutzt, muß auch noch der Schalter -lm rein.


Peter

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 17 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.