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
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
@ 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.
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
@ 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
...nö, beim flashen wird FAT auf dem mega8 angelegt und die .hex kopiert! Klaus.
>> ...nö, beim flashen wird FAT auf dem mega8 angelegt und die .hex kopiert!
DOS ist auch dabei.
Das funktioniert aber nur mit Flush-Rom, also nicht das Spülen vergessen!
ü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
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 ^^
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.