G.I.P: automatisch schaduwstation zonder wissels

[Sattrickske]

Een tweede opmerking is: gebruik defines om je hardware aan te spreken, als je dan later je hardware wil wijzigen, hoef je enkel maar deze defines aan te passen ipv. van je hele code te moeten doorlopen.

Dit begrijp ik niet helemaal, bedoel je dat ik toch <htc.h> vervang door die van de controller?

Neen, ik bedoel iets anders.  Her en der in je code gebruik je PORTC = 0x01 -wat je dient te vervangen door een bit set-, maar deze instructie wijst eigenlijk op een stukje van jouw hardware (een spoel van de stappenmotor activeren bv.).  Dit vervang je beter door zoiets:

Code Selecteer Uitklappen


#define STEP_COIL1_ACTIVATE PORTC |= 0x01

En in je code gebruik dan je gewoon STEP_COIL1_ACTIVATE ipv. de PORTC |= 0x01.  Het voordeel is dat je alle defines bij elkaar plaatst in een header file of bovenaan je applicatie, als je dan later je hardware wijzigt, hoef je niet overal in je code naar dat pinnetje te zoeken.  Gewoon effe de define aanpassen en het is gepiept...

En nog een vierde opmerking (en dan laat ik je gerust ): ik vermoed dat je telkens maar één bit van PORTC wil aansturen; maar je zet telkens wel de volledige PORTC.

Code Selecteer Uitklappen


PORTC = 0x01;

Dit zet alle bits op 0 behalve de eerste.

Betere versie:

Code Selecteer Uitklappen


PORTC |= (1<<bit);

Bovenstaande zet enkel bit 'bit' aan van PORTC en blijft van de andere bitjes af.  Idem voor het clearen van een bit:

Code Selecteer Uitklappen


PORTC &= ~(1<<bit);


't Zijn maar details, maar op langere termijn kunnen ze bepalend zijn voor de goede werking van heel je software.

Heeft dit dezelfde werking als PORTC|=0x01 (bitje set) & PORTC&=~0x01; (bitje clear)? Ja toch? Dat kende ik toch al

Ja inderdaad, je hebt het alleen niet toegepast in je code...
De '<<' is een left-shift, deze verplaatsen de bitjes met x posities naar links bv. 1<<3 komt overeen met 0x80.  Dat is gewoon een trucje om eenvoudig de waarde van een bit binnen een byte te bepalen.  De compiler vertaalt deze operatie automatisch naar de correcte waarde.

[conducteur]

Kan zo'n define dan ook bv 4 lijntjes code vervangen?

[Sattrickske]

Kan zo'n define dan ook bv 4 lijntjes code vervangen?

Ja en nee...
Technisch kan het wel, een define is eigenlijk een macro die tijdens de compilatie vervangen wordt door de code die gedefinieerd werd; maar in de praktijk vervang je dit echter beter door een subroutine.

[conducteur]

De code wordt dus korter, maar het vreet nog evenveel geheugen...
En ga ik dus nu eens google raadplegen hoe dat in elkaar zit, zo'n routine...

[Sattrickske]

Helemaal niet moeilijk:

Code Selecteer Uitklappen


int myRoutine(int param2) {
    return param2 +1;
}

void main() {
    int myVar;
    myVar = myRoutine(2);
    myVar = myRoutine(5);
}


[MickeyMouse]

En ik kan Patrick voor alle raadgevingen alleen maar bijtreden.
Overzicht en onderhoudbaarheid van de code zijn zeker even belangrijk als de werking er van!!
Naarmate je meer zal programmeren wordt dit uiteindelijk een automatisme.

Geert

[PeterC]

Code Selecteer Uitklappen


int myRoutine(int param2) {
    return param2 +1;
}

void main() {
    int myVar;
    myVar = myRoutine(2);
    myVar = myRoutine(5);
}


Ik weet het, ik ben een zagevent, maar voor mij is dit toch veel duidelijker (plaatsing van de haakjes):

Code Selecteer Uitklappen


int myRoutine(int param2)
{
    return param2 +1;
}

void main()
{
    int myVar;
    myVar = myRoutine(2);
    myVar = myRoutine(5);
}


En volgens mij niet alleen, cfr een artikel in de laatste Elektor...

Anderhalve decennia geleden heb ik vaarwel gezegd tegen C/C++ en ben me gaan bezighouden met (in mijn ogen) betere talen voor RAD (Rapid application development).  Zo ben ik voor PC programma's bij Delphi terecht gekomen (laat zowel high-level als low-level programmering toe) en voor µC's bij JAL (een op Pascal gebaseerde taal die ook ASM toe laat).

Voor mij primeert de 'leesbaarheid' van de code.  Als ik vandaag in een inspirerende bui ben en hopen code produceer, wil ik binnen drie jaar nog weten wat ik toen geschreven heb (ook al staat er weinig of geen commentaar in de code).  Het inspringen en codeblokken aan elkaar hangen vind ik daarbij een minimum moeite.

Een voorbeeldje in Object Pascal zonder commentaar in de procedure:



Daar is toch duidelijk te zien welke code bij welke sprong hoort?

[Edit] Niet dat ik iemand wil bekeren tot een andere taal, maar houd de regels van andere talen ook in C/C++ aan en je hebt duidelijk leesbare code.

[conducteur]

Code Selecteer Uitklappen


int stappen(int param2) {
//hier subroutine code//   
return param2 +1;
}

void main() {


//hier programma//

    int myVar;
    stappen= stappen(2); // ga naar subroutine
//hier rest porgramma//
   
}

Zo dus?

[Sattrickske]

Code styling conventies zijn geen wetten, enkel richtlijnen, dus eenieder doet in feite zijn goesting.  De huidige voor C en C++ kan je hier vinden: http://gcc.gnu.org/codingconventions.html en http://www.possibility.com/Cpp/CppCodingStandard.html
Wat betreft braces (accolades), beiden zijn toegelaten en maken niks uit.  Alleen dient eenieder binnen hetzelfde team dezelfde formatting te gebruiken, zoniet wordt het moeilijk om 2- of 3-way compares te gaan uitvoeren.  De keuze van de braces op dezelfde lijn of de lijn eronder is puur psychologisch.  Ik verkies ze op dezelfde lijn omdat ik dan op m'n scherm veel meer code kan lezen en minder hoef te scrollen.  Een if/else comibinatie kost bij mij 5 lijntjes, in jouw geval 8...
Als de indents juist staan maakt het geen bal uit waar de braces staan, een moderne editor geeft trouwens meteen de matching brace als je het broertje of zusje aankilkt.

Waar ik nu werk, wordt alle opgeleverde code automatisch gecontroleerd op deze conventies (en ja, de braces staan hier op dezelfde lijn).  De meeste developers hebben een automatische formatter in hun editor die ervoor zorgt dat de code altijd juist geformatteerd is.  Zoniet kost het hun punten...

By the way, de code formatter van MPLAB X (UI voor PICs) gebruikt dezelfde regels als die van mij.

Maar nogmaals, ieder z'n goesting, zolang je maar hetzelfde doet als de rest van je team.

[Sattrickske]

Zo dus?

Ja, maar opgelet, je gebruikt dezelfde naam voor je variabele en functie.  Kan verwarrend zijn, maar in theorie kan het wel.

[PeterC]

...Maar nogmaals, ieder z'n goesting, zolang je maar hetzelfde doet als de rest van je team...

Ik speel meestal 'solo-slim' 

[Sattrickske]

Ik speel meestal 'solo-slim' 

Dan hebde gij meer chance dan ik, bij kleurenwiezen heb ik dat nog maar één keer gehaald

[MickeyMouse]

Ik verkies ook om meer lijnen code ineens op een scherm te kunnen zien, dus haakjes op dezelfde lijn.
main () {
    codelijn1;
    codelijn2;}

De indents maken duidelijk wat de blokken zijn. Let wel, toen ik pas in C begon deed ik dit ook niet. Maar na een tijd begin je de voorkeur te geven om gemakkelijk een overzicht te zien in de talloze lijnen code.

Geert

[PeterC]

Ik verkies ook om meer lijnen code ineens op een scherm te kunnen zien, dus haakjes op dezelfde lijn.

Ik 'speel' dus Solo of Solo-Slim... 

[conducteur]

Ik probeer ook zelf de structuur aan te houden ( { en } op dezelfde tab onder elkaar, extra insprong voor dei blok code) maar dat loopt dan in de knoei door die blok in bv een while lus te gaan steken edm en wijzigingen en loopt het in het 100...


In de editor die ik gebruik voor html zit er een automatische formatter, zit zoiets ook in MPLAB?


En nu terug naar de routines en subroutines aub [size=78%] [/size]