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
@ 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
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
> 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.
@ 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
ü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
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.
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 ^^
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.
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
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
