Förstår inte vad som är "invalid expression" i C

[datajompa]

Om du gör fleradsmakron med \ på slutet av raderna, se upp så att du inte råkar få med ett mellanslag. Vissa kompilatorer ger absurda felmeddelanden då.

Du vet hur \n och \t escapear n och t? \ på slutet av en rad escapar det osynliga newline-tecknet till ett ingenting. Om du istället har ett mellanslag innan newline så escapear du mellanslaget. Nu tror jag att de flesta kompilatorer förstår detta men jag har aldrig använt MicroC och förr var detta ofta ett problem som ledde till slitet hår.

Några varningens ord också. När man väl har börjat med flerradsmakron och stora H-filer med #define och komplicerade enum som bakar ihop #define och så vidare, då har man verkligen tagit ett par steg ner i det träsk som är C! Men det hör naturligtvis till, särskilt om du vill lära dig att förstå existerande kod i andras projekt, som ofta består till största delen av ett nytt språk implementerat i form av preprocessormakron!

[hummel]

Vad gäller filernas storlek brukar jag tycka att en funktion som inte får plats skärmen är för komplicerad och den bryter jag ner i mindre funktioner.
Hade tidigare en chef son skrev ett program där en funktion var 14000 (!) rader lång, ha försökte oftast dölja den filen för mig...
Det stora funktionen hade så många if else if else så det var omöjligt att följ flödet eller testa/verifiera koden.

[TomasL]

ner i det träsk som är C!

Därför skall man i möjligaste mån undvika makron och #define.
#define skall enbart användas om man vill ha villkorad kompilering, enligt min mening, aldrig till nått annat.

[lillahuset]

Anmäler avvikande åsikt.

#define TOMASL 33 har definitivt en plats i program som hanterar ditt riktnummer.

Sedan finns det en gammal klassisk (föråldrad) regel att en funktion ska rymmas på en skärmbild. Dvs 25x80 tecken. Lite väl skitnödigt men en bra tanke.

[TomasL]

Ja, vi kan ha olika åsikter, trotsallt-
Jag anser att man skall använda pre-processorn så lite som möjligt.
Främst för att den inte ger vare sig varningar eller fel.
Det är dålig programmeringstil att använda makron mm.

[lillahuset]

Som sagt.

[Magnus_K]

#define setpins {\
LATA.B3=1;\
LATB.B5=1;\
}

Ja, det där ser ut att stämma. Ska testa det i mitt andra projekt som ligger på is just nu men också där jag skulle behöva det här. Tack Wedge.

...
Om du har minst ett 200-raders projekt som kör är det inte programmeringen som felar, det är din struktur av upplägget som felar.
...

Många bra tips där Icecap men det just den citerade texten ovan som jag vet att jag suger på. Förhoppningsvis blir strukturen bättre och bättre med tiden men tror att jag måste sitta mer och knåpa.

Finns det någon anledning att göra det som ett makro istället för en funktion? Funktioner leder, precis som någon skrev, ofta till kod som är lättare att debugga.

Jag får av din beskrivning för mig att du ha ett antal pinnar som hänger ihop som ett funktionellt block, men som inte samtliga sitter på samma hårdvarupinnar, och att du vill kunna skriva typ i pseudokod:

relay[0] = PORTB.B2;
relay[1] = PORTA.B7;
etc....

for(int i=0;i<3;i++) {
relay = 1;
}

Är det ungefär så du tänkt?

Men herregud, mitt största projekt är 600 rader och jag har gått in i väggen tre gånger redan.

Det är helt normalt. Välkommen till C!

Inte riktigt så som du skriver.
I dom flesta fallen, om jag ska styra tex 5 lysdioder från en µC så försöker jag lägga dom på samma hårdvaruport för då kan jag bara AND:a/OR:a in alla 5 bitar i ett svep, typ så här: PORTC &= 0b00011111; och så tänder jag alla dioder med bara en kodrad.

I mitt andra projekt så har jag blivit tvungen att sprida ut det lite mer så jag kanske har en LED på PORTC.B3, PORTB.B1 och en på PORTA.B7.
Det hade då varit riktigt smidigt att ha ett macro där jag tex kan LED_ON; och då sätts alla nämna utgångar höga, Alternativt LEDS = 1;, vilket ser riktigt snyggt ut.

Jag har nog inte förstått att ni menat en en vanlig funktion tidigare men efter lite fundering så skulle ju faktiskt det fungera bra också.

Tackar också för tipsen om mellanslagen. Tror faktiskt jag har provet det någon gång

Slutligen, jag har förstått att jag inte ska använda macron och annat men jag tycker jag ser det precis överallt när jag söker runt efter hjälp på nätet så det kan ju knappast vara förbjudet.
Jag låter det gå till den dagen jag själv får problem med det. Då får det bli en funderare.

[lillahuset]

Klart du ska använda MACRON men du måste inse hur de fungerar. De som anser att man inte ska använda MACRON hör till samma kategori som anser att man inte ska använda sammansatta ord (samskrivning). Sedan finns det naturligtvis tillfällen när MACRON inte är så lyckat.

I min värld finns det bara en RIKTIGT VIKTIG REGEL när man programmerar. KISS. Keep It Simple Stupid. Den har tjänat mig väl i drygt 30 år. Bara för att man tror man är smart är det inte säkert att man är det. Troligen tvärt om.

[Micke_s]

En annan sak kan vara att undvika globala variabler. Ställer snabbt till problem eftersom de kan ändras på flera ställen...

600 rader är inget. Kommer jag lätt upp i varje drivrutinskod till SAM L21 jag har skrivit..innan jag gick på semester så var nog embedded koden på jobbet 15000-20000 rader ungefär...

Kommentarer är vettigt per funktion..

Dela gärna upp långa funktioner i mindre vettiga bitar. Ha även inte mer än 2 nästlade for/if/while i samma funktion, splittra upp i en funktion till...

[SvenW]

De som anser att man inte ska använda MACRON hör till samma kategori som anser att man inte ska använda sammansatta ord (samskrivning).

Hur är kopplingen här?? Åldersgrupp?
Personligen tycker jag att man SKA samskriva ord eftersom det är norm i svenska språket, men tycker samtidigt att TomasL har helt rätt här; MAKRON skall användas sparsamt och bara om det inte finns bättre alternativ. En const kan t.ex.vara ett bättre alternativ och ger oftast ingen extra objektkod.

[lillahuset]

OK, kanske lite väl kategoriskt uttryckt. Och långsökt.
Men jag tycker inte man ska avfärda macron, de kan vara väldigt användbara. Men man ska, precis som med det mesta i livet, vara lite försiktig med dem. På vilket sätt är en const ett bättre alternativ?

[datajompa]

Vi är många här som kastar in lösryckta "goda råd", själv skyldig.

För att vara mer specifik, om du skapar en funktion

void set_pins(void) {
PORTA.B1 = 1;
PORTB.B2 = 1;
PORTC.B3 = 1;
}

och sedan anropar den i programmet, så kan du sätta breakpoints i debuggern på varje rad och stega igenom och se steg för steg vad som händer, och på så vis hitta svårupptäckta fel. I detta extremt enkla exempel så är det svårt att se vitsen med det, men i mer komplicerade funktioner och anropskedjor så är det livsnödvändigt att kunna debugga så.

Med ett makro så får du istället bara en rad att sätta breakpoint på, och då är det sällan man orkar bryta upp det i mindre bitar, utan istället så stångar man pannan blodig mot väggen och försöker tänka ut lösningen. Sedan efter fem timmar så visar det sig att man råkat skriva en false istället för true någonstans som hade tagit tio sekunder att hitta med debuggern.

Dessutom blir det som sagt ofta konstiga fel i makron på grund av hur de funkar, och mer komplexa makron kan bli oerhört svåra att förstå. Men då pratar vi ofta om makron som består av hundratals rader.

Självklart måste man använda och förstå makron eftersom det är en mycket använd del av C. Var bara medveten om att C är just ett träsk av frustration och mörbultad panna, så du behöver inte känna dig dum.

[lillahuset]

Jag tror aldrig jag har skrivit ett macro längre än en rad.

[SvenW]

På vilket sätt är en const ett bättre alternativ?

Med const alt. static const kan kompilatorn kan göra typkontroll.
Man undviker också vissa fundamentala missar som t.ex. denna:

Kod: Markera allt

#define X  5 + 13
y = X * 7;

[lillahuset]

Jomen parenteser är ju en dygd i macron. Det trodde jag alla visste.