Problem med länkning Atmel Studio 6

[bearing]

Varje gång du bygger kommer o-filerna för alla filer som inte ändrats användas. De som ändrats kompileras, och sedan används o-filerna för dem också. Tur det, för om det tar t.ex. 20 sekunder (för att inte säga 20 minuter!) att kompilera alla filer vinner man en hel del på att bara länka ihop o-filerna för alla filer som inte ändrats.

[Swech]

Jag skulle vara försiktig med att ha gemensamma filer för flera projekt
för du kan ju pilla med en fil för ett projekt som gör att något av dina andra projekt
plötsligt inte får plats i processorn eller får någon bugg i sig.

Eller åtminstonde se till att ha bra backup på de gemensamma filerna
så man kan hitta tillbaks

Swech

[sodjan]

Ja, "drivrutiner" är nog ett lite dumt begrepp här.
Det handlat helt enkelt om gemensamma subrutiner som används av flera projekt.

Problemet med att enbart länka in dom i dina andra "riktiga" projekt är
att du måste köra en build av ett av *dessa* projekt för att kontrollera
eventuella kodändringar i den gemensamma koden.

Med ett eget projekt för subrutinerna kan det ändras och byggas om
helt fristående från något annat projekt. Det kanske inte ens finns
något projekt som använder subrutinerna då man utvecklar dom!

Sen så kanske inte de gemensamma rutinerna alls ska ändras så snart
de har börjat använda i andra projekt. I så fall får man göra en version
2 som en helt separat subrutin för att inte spräcka gamla projekt (om
man inte vill använda de nya funktionerna, så klart).

Notera att man oftast ställer mycket högre krav på gemensam kod än
vad som kanske är normalt. Det måste vara betydligt mer genomtänkt
och stabilt, speciellt när det gäller API't mot rutinerna.

[toffie]

Tack för inläggen!

"Drivrutinerna" i detta sammanhang är ex. USART.c/.h. Dessa används i dagsläget, eftersom jag precis fått det att fungera, just mellan två "underprojekt" i ett och samma "huvudprojekt". Jag håller på och skriver ihop ett litet nätverk med tempsensorer som ska sitta runt om i lägenheten och de två underprojekten är, en "server" som efterfrågar och tar emot data från, "noderna" som svarar med information när det efterfrågas.

Så, ja om man använder ex. olika uCs så kanske minnet inte räcker till, men de gemensamma filerna, som USART exvis. ska inte bli "så stora" och givetvis ställer jag själv högre krav på dessa av flera anledningar. Har jobbat som programmerare inom webb runt 15 år nu, så just att sära på kod och bygga upp bibliotek för större funktioner och för ofta använd kod är ju något som redan finns inom mig. Så högre krav, absolut! Nu är det ju dessutom hårdvara och sådant inblandat, så det blir väl som ett ytterligare lager av "krav" att ställa på en själv att det helt enkelt bara ska fungera

Fast om allt bara fungerar så kanske det inte är så roligt heller, lite strul och fel måste man ju ha!

Om jag sedan startar "huvudprojekt 2" så kommer jag givetvis kopiera ex. USART.c/.h till en "drivrutins"-mapp för just det projektet. Det är just att jag gärna vill dela på filerna mellan underprojekt som hör till samma projekt, så att säga.


Fråga
O-filer, jag förmodar då jag inte kollat på det än, men ni menar med dessa alltså Library filer? Tänkte mest på vad man ska söka på för att forska lite mer i hur man skapar och använder dessa.

[bearing]

Alltså, som jag skrev ovan. Det som kommer ut ur kompilatorn är objekt-filer.

http://courses.cms.caltech.edu/cs11/mat ... ing_c.html

[ie]

Tack för tråden. Jag har exakt samma "problem" och jag fick inte till det då.

Just det här sättet passar mig att jobba, då jag kommer att ha ett antal olika moduler, där vissa programblock, såsom kommunikationsprotokollet, ska vara detsamma. Dvs jag vill kunna ändra i valfritt underprojekt och sedan vara säker på att jag använder samma kodversion i nästa modul.

Att skapa "externa" projekt för att ta fram rutinerna skulle bli för omständigt, då jag jobbar väldigt iterativt.

[sodjan]

> O-filer, jag förmodar då jag inte kollat på det än, men ni menar med dessa alltså Library filer?

Nej (och lite ja).

C-fil => C-Kompilator => Objektfil (.O eller .OBJ)
Flera C-filer => "Ett library verktyg" => LIB fil.
Objektfil/filer + LIB fil/filer => Länkare => EXE eller HEX fil.

En LIB fil är helt enkelt flera objektfiler som ligger i samma fil.
Principielt är det ingen skillnad på en objektfil och en "member"
i LIB filen. Man kan även kopirera objektfiler in till och ut från
LIB filen utan att det ändrar funktionen.

För länkaren spelar det ingen som helst roll om objekt-koden
kommer från en fristående objektfil eller från en member i en LIB!

En LIB är enbart en metod att administrera sina objektfiler, det är
helt enkelt enklare att distribuera *en* .LIB än 100 .O filer...

I många vanliga utvecklingsmiljöer ser man kanske inte vad som
sker "under the hood", men i princip fungerar det alltid så här.

Men OK, det du talar om är "bara" gemensamma filer inom en och
samma applikation. Då spelar det kanske inte så stor roll, om du i
alla fall ska kopiera dom till nästa applikation.