Får du någon MAP fil så att man kan se vad som faktiskt har länkats in?
D.v.s så att det faktiskt är debug moduler och inte något helt annat?
Ah, "-Map=Starfollower2.map"...
Den ger ingen vägledning?
Koden växte vid compilerbyte, argh.
Re: Koden växte vid compilerbyte, argh.
Man får någon logg så att man ser hur make har expanderat $(CC) raden?
Får du någon MAP fil så att man kan se vad som faktiskt har länkats in?
D.v.s så att det faktiskt är debug moduler och inte något helt annat?
Ah, "-Map=Starfollower2.map"...
Den ger ingen vägledning?
Får du någon MAP fil så att man kan se vad som faktiskt har länkats in?
D.v.s så att det faktiskt är debug moduler och inte något helt annat?
Ah, "-Map=Starfollower2.map"...
Den ger ingen vägledning?
Re: Koden växte vid compilerbyte, argh.
Kikade lite i map filerna och det verkade skilja något gällande mattefunktionerna.
Hittar då MATH_LIB = -lm i den gamla makefilen. Kommenterar jag bort den raden så växer koden brutalt och mapfilerna blir nästan identiska. Hm...
Provar att lägga till optionen -lm till länkaren i avr studios makefil, men det ger inget resultat.
Hittar då MATH_LIB = -lm i den gamla makefilen. Kommenterar jag bort den raden så växer koden brutalt och mapfilerna blir nästan identiska. Hm...
Provar att lägga till optionen -lm till länkaren i avr studios makefil, men det ger inget resultat.
Re: Koden växte vid compilerbyte, argh.
Den kan vara kinkig med ordningen på flaggorna, du får kanske experimentera lite.
Kanske skall man skriva t.ex.
LDFLAGS += -Wl,-lm
Och se upp med mellanslagen.
Bara gissningar dock!
Kanske skall man skriva t.ex.
LDFLAGS += -Wl,-lm
Och se upp med mellanslagen.
Bara gissningar dock!
Re: Koden växte vid compilerbyte, argh.
Den här tråden känns lite oroande. Har inte själv varit med om något liknande, men så har jag bara hållit mig till AVR Studio 4, 5 och 6. Jag kanske *alltid* fått dubbelt så stor kod jämfört med om jag hade använt winavr?
Jag har uppdaterat - först till Studio 5, sedan till Studio 6. Har för mig att det initialt var lite krångel med 5:an som jag senare inte upplevt med 6:an. Däremot är det inte säkert att 6:an godkänner kod som funkade i 4:an, då den har lite strängare regler för vad som är tillåtet att skriva. (man kunde t.ex. tidigare skriva char PROGMEM blabla[] = "Hej"; men nu måste man skriva const char PROGMEM blabla[] = "Hej"; Men det kan ju ha att göra med att de ändrat nåt i default-inställningarna. Jag vet inte om det är nya versioner av GCC eller om det är beskrivningsfilerna av AVR minnes-map (?) som har ändrats och hur de i så fall skulle skilja sig...Gimbal skrev:Jag använder avr studio 4.18, vill minnas att det var någon nackdel med att uppgradera till nyare version senast jag kollade upp det, men det kanske inte stämmer..?
Re: Koden växte vid compilerbyte, argh.
-lm säger till länkaren att länka in ett bibliotek som heter "libm.a" om jag förstått manualen rätt men kommandot sätts i variabeln MATH_LIB som i sin tur petas in i anropssträngen någonstans senare?Gimbal skrev:Kikade lite i map filerna och det verkade skilja något gällande mattefunktionerna.
Hittar då MATH_LIB = -lm i den gamla makefilen. Kommenterar jag bort den raden så växer koden brutalt och mapfilerna blir nästan identiska. Hm...
Provar att lägga till optionen -lm till länkaren i avr studios makefil, men det ger inget resultat.
"-l library
Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)
It makes a difference where in the command you write this option" https://gcc.gnu.org/onlinedocs/gcc-4.6. ... tions.html
Jag missade att du använde 4.x, den gillade jag aldrig, kändes mest som uppvärmda rester från 90-talet
Re: Koden växte vid compilerbyte, argh.
Ok nu hände det saker.
Flyttade först runt switcharnas ordningsföljd, men antingen så blev det som innan, eller så gick det inte alls.
Började sedan med att manuellt byta ut alla compiler switchar från den gamla filen till den nya, -ingen märkbar skillnad.
Sedan alla assembler switchar, utan resultat.
Samt all länk switchar, ej heller det gav något.
Såg sedan swesysmgr kommentar "-lm säger till länkaren att länka in ett bibliotek som heter "libm.a""
Hittade då i AVR studio en flik där man kunde välja lib att länka med, så libm.a väljs in och tjohej, filstorleken halveras.
Vad jag inte begriper är varför jag inte behöver välja in det lib'et manuellt när jag använder den gamla makefilen, då räcker det med att -lm switchen är med.
I nya makefilen gör -lm inte ett skvatt, men om jag plockar in libbet manuellt (utan att ha angett någon -lm switch) så fungerar det.
Tack alla för ideer och tips. Jag begriper inte riktigt varför, men nu fungerar i alla fall avr studios egna makefil och jag har återigen gott om utrymme i Attiny45'an. I morgon kanske jag kan programmera istället för att leta verktygsfel.
Flyttade först runt switcharnas ordningsföljd, men antingen så blev det som innan, eller så gick det inte alls.
Började sedan med att manuellt byta ut alla compiler switchar från den gamla filen till den nya, -ingen märkbar skillnad.
Sedan alla assembler switchar, utan resultat.
Samt all länk switchar, ej heller det gav något.
Såg sedan swesysmgr kommentar "-lm säger till länkaren att länka in ett bibliotek som heter "libm.a""
Hittade då i AVR studio en flik där man kunde välja lib att länka med, så libm.a väljs in och tjohej, filstorleken halveras.
Vad jag inte begriper är varför jag inte behöver välja in det lib'et manuellt när jag använder den gamla makefilen, då räcker det med att -lm switchen är med.
I nya makefilen gör -lm inte ett skvatt, men om jag plockar in libbet manuellt (utan att ha angett någon -lm switch) så fungerar det.
Tack alla för ideer och tips. Jag begriper inte riktigt varför, men nu fungerar i alla fall avr studios egna makefil och jag har återigen gott om utrymme i Attiny45'an. I morgon kanske jag kan programmera istället för att leta verktygsfel.
Re: Koden växte vid compilerbyte, argh.
Det har inget med att AVR studio skapar make filen dynamiskt
och att man bör (måste?) gör ändringarna i IDE't?
En sak är jag inte riktigt med på, vad menar du med "när jag
använder den gamla make filen"? Kör du en manuell make
separat (utanför) AVR Studio med en "gammal" make fil?
Eller säger du till AVR Studio att du har en egen make fil
och att den inte ska köra sin egen?
och att man bör (måste?) gör ändringarna i IDE't?
En sak är jag inte riktigt med på, vad menar du med "när jag
använder den gamla make filen"? Kör du en manuell make
separat (utanför) AVR Studio med en "gammal" make fil?
Eller säger du till AVR Studio att du har en egen make fil
och att den inte ska köra sin egen?
Re: Koden växte vid compilerbyte, argh.
Jag kan ange i avr studio att den ska använda en extern makefil istället för sin egna.
Så när jag experimenterar med studios egna makefil så tar jag först en kopia av den och anger att studio ska använda den kopian. Då kan jag editera kopian och klippa in både det ena och det andra utan att studio ändrar tillbaka.
Men nu funkar det som sagt med studios egna makefil som skrivs om vid varje kompilering baserat på de inställningar man gjort i menyerna.
Det var alltså en dubbelfint som strulade till det.
Först var filstorleken halverad med hjälp av ett bättre(?) mattelib, och sedan dubblerad igen pga debuginfo var inbakat. Resultat blev då ungefär lika stort som studios resultat utan debug fast med större mattefunktioner. Åtminstone är det vad jag tror nu.
Så när jag experimenterar med studios egna makefil så tar jag först en kopia av den och anger att studio ska använda den kopian. Då kan jag editera kopian och klippa in både det ena och det andra utan att studio ändrar tillbaka.
Men nu funkar det som sagt med studios egna makefil som skrivs om vid varje kompilering baserat på de inställningar man gjort i menyerna.
Det var alltså en dubbelfint som strulade till det.
Först var filstorleken halverad med hjälp av ett bättre(?) mattelib, och sedan dubblerad igen pga debuginfo var inbakat. Resultat blev då ungefär lika stort som studios resultat utan debug fast med större mattefunktioner. Åtminstone är det vad jag tror nu.
Re: Koden växte vid compilerbyte, argh.
Du skulle med andra ord ha kollat MAP-filen tidigare:)
