Svenska ElektronikForumet

Så du vill t.ex göra LATA.B3=1 och LATB.B5=1 som ett macro?
Jag vet inte om man kan definiera flerrads macron. Kanske...

Ett annat sätt som det kan lösas på en en funktion som är "inline",
d.v.s att koden i funktionen läggs in direkt i programmet istället för
att det blir ett CALL med RETURN o.s.v.

Jag vet inte om det går eller hur man gör i MikroC, men i XC8 kan man göra: Anropen ersätts enbart av innehållet i funktionerna, inga CALL eller RETURN.

Men herregud, mitt största projekt är 500-600 rader och jag har gått in i väggen tre gånger redan.
Mitt nuvarande projekt är 200 rader och jag känner svettpärlor. Det här med programmering är inte min grej. Det är tyvärr så många projekt som gått i graven pga att jag inte får ihop koden.

@sodjan: Återkommer till dig. Vi postade samtidigt.

Uppdelning av kod i flera filer är en sak. Det är mer en praktiskt fråga
för att man t.ex. använder samma rutiner i flera applikationer o.s.v.

Viktigare är hur man strukturerar koden. Kanske inte har en 2000
rader lång main() t.ex. Om sen main() och allt annat ligger i samma
fil spelar inte lika stor roll, enligt mig.

Ytterligare en parameter är att med normala make verktyg, så behöver
så klart bara den/de senast ändrade filerna kompileras om, de andra
länkas in från den tidigare objektkoden, så en "build" går ofta snabbare
med uppdelning i flera filer.

Angående flerradig definering av macron. Har inte jag frågat det förrut? Jag frågar så mycket...
Det du skriver är ju precis det jag önskar göra men när jag söker på "inline" i MikroC:s hjälpmeny så handlar det bara om hur man klämmer inte lite assemblykod.

Ska söka lite på nätet och MikroC:s forum.

Njaäää, dom suger lite på det...

Ja, manualen till MikroC talade bara om att vissa biblioteksfunktioner
var definierade som "inline" av de själva. Inget om hur man gör
det med egna funktioner...

Aha: http://forum.mikroe.com/viewtopic.php?f=103&t=24038

EDIT: samma träff...

Hehe ja.
Nej jag får köra på så länge. 2018, när jag börjar runda av det här projektet, så kanske dom har implementerat "inline" möjligheten...

Eller så byter du till XC8, jag minns inte varför du kör MikroC.
Kanske för det relativt stora antalet färdiga funktioner?

Jaaa, eller jooo tror det var så.
Har varit och känt lite på XC8 men det är så svårt att sätta sig in i något nytt när man ändå programmerar så lite som jag gör.
Har för mig SeniroLemuren kände lite på XC8 för ett tag sedan och jag kände igen mig själv väldigt mycket i det han skrev.

Självklart borde Microchips egna produkter vara det man använder för man får med en hel del på köpet, som tex debugger med PICkit:arna och annat men ja, jag pillar runt lite med MikroC och Arduino.

Egentligen är det inte så mycket miljöerna som är svårigheten för mig utan det är just vad du var inne på innan, att strukturera. Alla mina program börjar så bra med lite skisser på papper och sen ett låååångt kommenterat fält i början men funktioner, I/O-listor med mera men det slutar alltid i hundskit.
Jag har inte heller lust att posta 200 rader kod här och önska att någon ska reda ut min röra, för det har varken jag eller någon annan tålamod med.

sodjan skrev:Så du vill t.ex göra LATA.B3=1 och LATB.B5=1 som ett macro?
Jag vet inte om man kan definiera flerrads macron. Kanske...

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

sodjan skrev:Ett annat sätt som det kan lösas på en en funktion som är "inline",
d.v.s att koden i funktionen läggs in direkt i programmet istället för
att det blir ett CALL med RETURN o.s.v.
...
Anropen ersätts enbart av innehållet i funktionerna, inga CALL eller RETURN.

Inline är ett sätt att be kompilatorn göra ett sånt utbyte, men den kan även låta bli.
Resultatet beror av kompilatorval, optimeringsflaggor, var inline-funktionen definerats, och hur koden ser ut.
I värsta fall kan en kompilering ge det ena resultatet, och nästa kompilering det andra. Klassikern "Men jag har inte ändrat nåt i DEN modulen".
Plus en hel massa skoj som kan inträffa när man vill separatkompilera filer i större projekt. Googla.
Och använd sedan inline med försiktighet.

Magnus_K: MÅNGA projekt börjar som "undrar om det går?" för att sedan byggas på eftersom, been there, done that!

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.

Jag har - av exakt samma orsak - ställd upp regler för min programmering och jag har börjat bli mindre usel på att följa dom numera!
* Kommentarer! Inte per rad (om inte raden gör något väldigt specifikt) men definitivt per funktionsblock.
* En uträkning/funktion som utförs fler ställen/av fler olika funktioner ska vara en egen funktion. Detta gör underverk vid debugging. Och man kan säkerställa att t.ex. timingen vid hårdvara-funktioner är korrekt och då vet man att det gäller för alla funktioner som använder den hårdvara.
* Vettiga namn! Jag lägger ofta variabler i en struct-block så att alla som t.ex. har med EEPROM-kommunikation har ett eget block, UART-kommunikation i ett anat block osv. Vid läsning av programmet är det underbart tydligt - men vid skrivning är det lite mer jobb.
* När jag påbörjar ett projekt skriver jag kortfattat i början (som kommentar) vad projektet ska göra. Gärna en övergripande beskrivning följd av en mer detaljerat beskrivning. ("Ska läsa knappsatsen och via en n-key rollover skicka ut på serieporten").
* ALDRIG definiera värden som kan ändras under vägen som hårda värden! Varenda gång jag t.ex. har en buffer av en given storlek vet jag att den kan riskera att ändra storlek varför jag definierar antal element mha. #define xxx. ALLA funktioner som beror på xxx refererar sedan till detta värde även om det är xxx - 1 eller liknande. Jag använder även mycket ofta sizeof() som ersättning för detta om det är säkert att det fungerar.
* Definiera hårdvara-pinnar med vettiga namn och aldrig använda annat än dessa namn! Då är det extremt enkelt att byta pinne om man måste.

Det finns såklart fler regler men det viktiga är att det fungerar för mig! Efter att jag har slutat att hårdkoda storlekar och istället refererar till den definition som finns har "Unexpected Features" minskat en hel del, struktureringen som visar var variabler hör hemma har hjälpt mycket också - men viktigast är nog min beskrivning av vad projektet ska göra.

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

OK, fast inga ; (semikolon) efter #define !

Det ska väl vara med semikolon om man vill att det ska vara semikolon i resultatet?
Som t.ex i Wedge exempel. Eller menade du att det var något fel där?

oops, jag tänkte fel i hastigheten. Det är ju instruktioner.

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?

Magnus_K skrev: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!