Svenska ElektronikForumet

> Självklart kan man skapa en fil som alltid ska finnas med i alla projekt och alla funktionsfiler kan sedan inkludera denna...

Det borde räcka med att, *OM* ett visst projekt ska använda t.ex "Controller_Unit_200_DS3232_100.c"
från någon gemensam katalog (och det bör man ju veta som programmerare), så ska man även
skapa "Controller_Unit_200_DS3232_100.h" i projektets katalog. Den behövs ju inte i *alla*
projekt, enbart de där man använder just RTC funktionerna. Samma sak för andra rutiner.

> lösningen är att i Build lägga in en "fast" definition. Jag gissar på att det är som
> att lägga in den i starten av make-filen eller liknande.

För *kompilatorn* är det detsamma som en #define i själva koden.
HEW kommer att lägga en -D... flagga i gcc kommandot, det borde
även synas i "output" från kompileringen.

Kan du göra detta för *en* specific .c fil eller kommer den att vara definierad på samma
sätt för hela projektet? Kanske inget problem, så länge man har unika namn...

sodjan: min tanke är att man kan göra så att när man skapar varje projekt kan man skapa en "Project_Setting.h" fil (eller annat lämpligt namn) där man kan definiera alla saker som man vill "trimma" eller helt undviker default-värden och ENBART ställer dom i den fil.

Då kan samtliga funktions-filer i det gemensamma bibliotek inkludera den fil på projektnivå (alltså #include "Project_Setting.h"). Det kommer såklart att vara en del settings som är intensivt likgiltigt för de olika filer och som används av andra men man kan inkludera dom ändå, så länge namnen är unika skadar de ju inte.

På detta vis kan man utföra -D-flaggan utan att behöva stega sig in i inställningarna.

Nerre: jag har inte fler olika funktioner med samma namn! Det är så nära självmord man kan komma. Men om en funktion i ett projekt ska ha en buffer på 10 platser och i ett annat projekt behöver 100 platser ser jag det som samma funktion (fast såklart i olika projekt).

Säg att man - som jag mycket ofta har - har en seriell port igång. Kommunikationsprotokollet i ett projekt kan vara kort och snabbt och kanske 10 bytes räcker fint som tx-buffer så att tx-interrupten kan skicka ett meddelande medan µC'n rullar vidare i programmet.

Ett annat projekt kan ha en helt annan inriktning och det kan vara vitalt att ha en tx-buffer på kanske 1kB.

Vid att kunde ställa in dessa värden projekt för projekt anser jag att det är samma funktion men olika storlekar på buffern - och allt sker med samma funktionsfil som grundlag. Därför kan man lägga en del energi på att skapa en "skottsäker" funktion och sedan är det "bara" att inkludera i de projekt som behöver det.

Man har ju standardbibliotekerna man drar in vid behov, t.ex. "stdio.h", "string.h" osv. alltså vill jag kunde skapa något liknande för den hårdvara som finns på ett kretskort och sedan är det bara att lägga till de nödvändiga filerna i projektet, redigera "Project_Settings.h" till rätt värde och sedan kompilera.

Då kan man lägga energin på att utveckla de delar som är unikt för just det projekt medan man redan har gjort allt grundarbetet med de basala funktioner.

Problemet där är att varken
eller
söker i projeketets bibliotek.

Se https://gcc.gnu.org/onlinedocs/gcc-4.1. ... yntax.html

Hmm, eller det där quoute directory kanske är grejen, man sätter projektets bibliotek i den sökvägen?

https://gcc.gnu.org/onlinedocs/gcc-4.1. ... earch-Path

Annars är ju det där ungefär samma sak som jag skrev först i det här inlägget http://elektronikforumet.com/forum/view ... 2#p1066342

Där skriver jag ju att jag är lite osäker på om den söker på "rätt ställen".

Ja, vad som är mest praktiskt beror ju helt på hur det ser ut i varje enskilt fall.

Du menar att använda -D-flaggan för ett överrida något i "Project_Setting.h"?
Ja, det kan man också kanske göra. Jag skulle nog välja det ena *eller*
det andra så att det inte blir för rörigt. "Project_Setting.h" är ju bara en
vanlig fil och är lika enkel att ändra som någon annan fil i projektet.

Så då blir det alltså:

1. Skapa och anpassa "Project_Setting.h".
2. Lägg till funktions c-filerna till IDE'ts "projekt".

Sen borde det "bygga"...

(Då behövs väl inte -D flaggan !?)

> Problemet där är att varken...söker i projektets bibliotek.

Jo, om filen där #include görs ligger i projektets bibliotek så...
Men visst, det gör den ju inte i detta fall.

Hm, man får studera HEW lite närmare (ingen dokumentation utan registrering!).
Kanske att HEW skickar med projektets katalog som en -D flagga, då skulle
denna kunna appendas direkt i #include directivet (antar jag).

Eller så lägger man till projektets katalog till include-sökvägen med -I flaggan.
Det finns sannolikt någon meny/form funktion i HEW för att fixa det.

Jupp, testat och det fungerar inte! Det verkar klart att #include utförs från samma bibliotek som filen som inkluderar befinner sig i.

Alltså är det enda som är kvar att använda -D funktionen i GCC. Det fungerar ju också men känns inte lika enkelt som att ha definitionerna skrivna i en fil per projekt. Det känns lite som med t.ex. MikroC till PIC där man ska ange CONFIG-funktionerna i en "egen" editorliknande funktion var de alltså inte exporteras med koden.

Man kan göra så - men det är inte rätt!

Jag har länkat till sidor som förklarar var #include letar efter filer. Börja med att läsa dem. Det är t.ex. skillnad på #include "fil.h" och #include <fil.h>.

> Det verkar klart att #include utförs från samma bibliotek som filen som inkluderar befinner sig i.

Ja, det är default. Sen kan man lägga till egna/andra kataloger med -I flaggan.
Om nu inte IDE't (HEW) själv lägger till någon -D med automatik som man kan använda...

Testade lite mer och det fungerar om jag lägger in projektets bibliotek som sökväg. Samtidig är det tillägg till sökvägen projektspecifikt.

Då kan man alltså lösa det vid att göra den projektsdefinitionfil och lägga den i projektbiblioteket, då kan samtliga funktionsfiler inkludera de settings som måste kunde ställas.

Och som sodjan påpekade kan det vara en dum idé att ha default settings, ska man använda detta bör det vara ett måste att man har värdet definierat i projektdefinitionsfilen. Då släpper man dumfelen med stavfel osv.

Men skitbra, tack för alla input, nu ska jag bara fixa läsningen av RTC'n, sedan kan jag komma vidare med ett viktigt projekt.

Det var enbart kul!

Yepp, Icecap, med Project_settings.h tänket är du inne på rätt väg!
Bara att slänga in de olika mapparna var eventuella andra h-filer finns i IDEns "include directorys", "include path" eller vad det månne heter.