mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Aufblasbarer Flash im Atmega8?


Autor: Harald (Gast)
Datum:

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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich ist dein Hex-File codiert als Intel-Hex. Und das ist 
nicht binär, sondern ASCII-Codiert mit Prüfsummen etc.

Grüße
Michael

Autor: Falk Brunner (falk)
Datum:

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

Autor: hans (Gast)
Datum:

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

Autor: A. F. (artur-f) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ein Compilierversuch mit den alten Sourcen
> lieferte dann die Felhermeldung "region text is full".

Bei der Fehlermeldung gehe davon aus, dass dein Makefile nicht 
automatisch erzeugt wurde. Probier es mit einem STD Makefile und -Os.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

warum verlangt AVR-Studio dann als Eingabe ein Hex-File? Wird dieses 
Hexfile von AVR-Studio nochmals in ein Binärformat gewandelt?

Gruß,
Harald

Autor: Falk Brunner (falk)
Datum:

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

Autor: Klaus2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...nö, beim flashen wird FAT auf dem mega8 angelegt und die .hex 
kopiert!

Klaus.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Klaus2: Ey, bring unseren Namen nicht in verruf! ;)

Autor: ARM für Arme (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> ...nö, beim flashen wird FAT auf dem mega8 angelegt und die .hex kopiert!
DOS ist auch dabei.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... Und das Flashenpfand nicht vergessen!


Peter

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das funktioniert aber nur mit Flush-Rom, also nicht das Spülen 
vergessen!

Autor: Michael H* (Gast)
Datum:

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

Autor: Johannes M. (johnny-m)
Datum:

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

Autor: Michael H* (Gast)
Datum:

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

Autor: Michael H* (Gast)
Datum:

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

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

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

Autor: Michael H* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...
AVR095: Migrating between ATmega48, ATmega88 and ATmega168
http://www.atmel.com/dyn/resources/prod_documents/...
vllt hab ich ja damit doch was sinnvolles von mir gegeben ^^

Autor: Peter Dannegger (peda)
Datum:

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

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.