AtmelStudio 6 - varning vid kompilering.

[jesse]

Har uppgraderat till AtmelStudio 6 och fick plötsligt en hop med nya varningar som jag aldrig haft innan. En varning ser ut så här:

Warning 1 ... uninitialized variable 'tpscan' put into program memory area [-Wuninitialized] F:\dok\Dropbox\Avrstudio\bms6\bms6\main.h 379 25 bms6

Jag kan inte tolka om det innebär att innehållet i den variabeln kan bli förstört eller på fel plats eftersom den än oinitierad och då vet väl inte kompilatorn hur stort utrymme den ska ta upp, Så hur stor plats reserveras egentligen?

Problemet uppstår då jag i main.h deklarerar:

extern uint8_t PROGMEM tpscan[];

sedan i main.c definieras den:

uint8_t PROGMEM tpscan[] = "scannar NTC sensorer\n";

Men variabeln används senare på flera ställen i programmet, både i main.c och i en annan fil - bms.c:

print(tpscan);

main.h innehåller #include bms.h
bms.h innehåller #include main.h
bms.c innehåller #include bms.h

Jag har flera texter i programminnet som är deklarerade på samma sätt (som extern i main.h och definerade senare i main.c) och de fungerar utan varning att använda i just main.c senare. Problemet med just tpscan[] är att den används även i filen bms.c. Det är ju därför variablerna är deklarerade som externa - att de ska kunna användas i alla filer i projektet.

Hur ska jag göra för att inte få den här varningen? Och innebär den att något kan gå fel med variabeln, eller är det en "ofarlig" varning? Det funkade ju uppenbarligen i AVR Studio 5...

[jesse]

Kan tillägga att jag även gjort ett ful-hack i en av avr-libs filer för att inte få error vid kompileringen. Detta var också något som uppstod efter uppgradering till AtmelStudio 6. (Har inget att göra med varningarna ovan).

Normalt skriver jag:

uint8_t PROGMEM foo[] = "text";

vilket fungerat utmärkt i AVR Studio 5. Men i 6:an blir det error:

Error 1 ... variable 'melody1' must be const in order to be put into read-only section by means of '__attribute__((progmem))' F:\dok\Dropbox\Avrstudio\bms6\bms6\main.h 375 25 bms6

Istället för att lägga till ordet const i alla filer i alla mina projekt så valde jag att lägga till const i PROGMEM-makrot istället:

iFilen pgmspace.h:

original:
#define PROGMEM __ATTR_PROGMEM__

fulhack:
#define PROGMEM const __ATTR_PROGMEM__

[dangraf]

Fundering, "sträng" lägger sig i flash-minnet medan uint8_t säger att man vill lägga variabeln i ramminnet. om du ändrar till const uint8_t PROGMEM... läser man direkt från flash, ändrar detta på varningen?

[stekern]

Du kan nog skippa PROGMEM helt när du deklarerar den i main.h, dvs extern uint8_t tpscan[],
var den hamnar någonstans är ju bara intressant för definitionen.

Jag brukar ha attribute inlagda efter variabelnamnet eller allra först, jag kan inte minnas om
det har någon praktisk betydelse (och beror säkert på gcc version), men du
kan ju kika här om du hittar nåt spännande om det: http://gcc.gnu.org/onlinedocs/gcc/Attri ... ute-Syntax

Dvs
uint8_t foo[] PROGMEM = "text";
eller
PROGMEM uint8_t foo[] = "text";

[Icecap]

Det är väldigt dumt att fulhacka lib-filar! Vid nästa uppdatering kanske samma fil uppdateras, då uppkommer felet igen och vad fasen var det man gjorde månne för att det skulle fungera?

Lite som att jag aldrig uppdaterar de lib-filer som finns i mitt CAD-program från starten. Ska jag ändra något har jag egna filer till detta, dom kommer inte att uppdateras av en generell uppdatering av CAD-programmet och då fungerar det.

Är det så att dina program behöver skrivas lite om är det bättre att göra det ordentligt från början istället för att ställa till en massa problem senare, antingen för att man glömmar vad man hade ful-hackat, för att det uppdateras eller för att man skickar källkod till någon annan dator - eller såklart en kombination av dessa faktorer.

Hade det varit möjligt att ange detta parameter innan är det dåligt skrivit kod som inte innehåller det från starten! Och ja, jag gillar också att konstanter hämtas från flash-minnet, jag ser ingen nytta av att de ligger i RAM så jag gör på samma sätt - fast då med en annan processor.

[jesse]

>Det är väldigt dumt att fulhacka lib-filar!

Varför tror du jag kallar det för ful-hack?

Jo, jag begriper det - det var tillfälligt, eftersom jag hade lite bråttom att få igång det. Nu ska jag t.ex. installera Atmel Studio 6 på ytterligare en dator - då ska det moddas även där.... det kan ju bli jobbigt till slut...

Man kan ju t.ex. skapa ett nytt macro i sina egna bibliotek som man kan använda istället:
#define PROGM const PROGMEM

så har man ju ordning på det sedan.

[Icecap]

Bra då, då är vi på samma linje. Och tro mig: det är inte för att vara korrekt jag skrev det, snarare är det baserat på tråkiga erfarenheter...

[jesse]

Ja, det är bra att du säger ifrån!