Hur ska man strukturera ett projekt? (arduino, C)

[xarvox]

Hej alla!
Jag försöker lära mig programmera C för Arduino och har hamnat lite vilse på vägen..

Jag har jobbat på ett projekt i ca 4 år, vars huvudsakliga syfte är att lära mig programmera och jag försöker få in en del "avancerade" saker i projektet just för att det SKA vara svårt och lärorikt.
Specifikt rör det sig om en controller-enhet för el-cykel, i2c-bus för display/LED-lampor/knappar/tempsensorer/batteri-övervakning samt hastighet/trip-mätare och "intelligent" styrning av elmotor-controllern.
Jag har gått lite överstyr med projektet, beställt egen-designade kretskort och en hel hög med komponenter, men som sagt; detta är till för att lära mig programmering/elektronik och inte för att lösa uppgiften så enkelt som möjligt..



Men nu inser jag att jag inte har en susning om hur jag egentligen bör strukturera ett stort projekt som en helhet och hoppas därför få lite synpunkter, tips och tricks från er som kan mer än mig.


Jag har en viss koll på hur jag ska göra de enskilda delarna av projektet, läsa knappar, skriva till 16x2 LED-display, i2c hantering, temperatur/batteri-övervakning osv osv, men jag kan inte riktigt greppa hur helheten ska utformas..


Primärt frågar jag alltså efter en programvaru-struktur eller tankesätt att applicera vid lite mer "avancerade" projekt.



Jag använder Eclipse IDE med arduino plugin om det spelar roll för någon..
...och innan någon frågar efter kod-snuttar; projektet är inte där än, jag har ett 50-tal varianter och utkast, men inget som tydligt visar vad jag håller på med...



#edit#
Off-topic-fråga;
vet någon om nån programmerings-kurs på distans (i sverige) som lämpar sig för arduino och C?
Bör jag gå en nybörjarkurs trots att jag har flera års "erfarenhet", eller bör jag gå en "avancerad" kurs, trots att jag inte kan alla grunderna?
#/edit#

[TomasL]

Börja med din egen favorit-ordbehandlare.
Skriv en krav-specifikation.
Beskriv vilka funktioner som skall finnas.
Beskriv hur dessa funktioner skall fungera.
Beskriv vilka funktioner som skall påverka vilka och vad de är beroende av.
Beskriv detaljerat hur hårdvaran är konstruerad, och hur den fungerar.
Därefter betar du av funktion efter funktion programmatiskt.

Kommentera ordentligt och mycket i koden.
För mycket kommentarer skadar inte, för lite skapar problem i framtiden.
Beskriv i koden vad samtliga variabler skall användas till, dess maximala och minimala värde.
För varje funktion gör du sedan en kommentars-header som beskriver vad funktionen gör, vilka variabler den använder osv.

Använd helst Doxygen format på alla kommentarer, för då kan du med hjälp av doxygen får en riktigt snygg dokumentation på projektet.

[HUGGBÄVERN]

ThomasL har sagt ALLT. Den viktigaste meningen är Därefter betar du av funktion efter funktion programmatiskt.; på programmerarspråk top-down. Börjar du pilla programrader och jobbar dig uppåt söger man bottom-up och är bästa vägen till oregerlig spaghettikod.

[arvidb]

Mycket bra tips från TomasL där! Jag vill betona kravspecen lite extra. Räkna med att 1/3 av projekttiden går åt till att ta reda på vad det faktiskt är du vill ha gjort.

Sen har jag lite andra åsikter om kommentarer i programkod:
* Jättebra att skapa en kommentar-header för varje funktion (och gärna i Doxygen-format som sagt). Beskriv övergripande vad funktionen gör och dess parametrar och returvärde. Gå inte in på implementationsdetaljer här (som vilken algoritm som används).
* Själva koden bör dock vara självbeskrivande så långt det är möjligt. Använd bra variabelnamn, gör inte för mycket i varje funktion o.s.v., så att koden blir övergriplig och lättförstådd. Massor av kommentarer (t.ex. av varje rad) krånglar bara till det och blir snabbt ett h-ete att underhålla. Det finns ingen anledning att skriva en kodrad och sedan en kommentar som talar om vad raden gör - det syns ju genom att läsa raden! Och gör det inte det så bör du skriva koden på något annat sätt. Kommentarer som kan vara användbara i själva implementationen är t.ex. övergripande kommentarer om val av/beskrivning av algoritm, varför du valt att göra på ett visst sätt etc.

[arvidb]

Och använd ett versionshanteringssystem för koden! git är väl det som är mest populärt nu. Lite meckigt att lära sig men oumbärligt när man väl lärt sig att använda det!

Typ:
$ git init # Skapa tomt repo
$ git add <namnet på de filer som ingår i projektet>
$ git commit # Spara filerna i dess nuvarande skick

<jobba jobba jobba>
"Hmm, vad har jag gjort för nåt egentligen?"

$ git diff # Visa vilka ändringar som har gjorts sedan senaste commit

"Ja det där ser bra ut"

$ git commit -a

[TomasL]

Eller SVN, som jag använder själv.
Fördelen med svn är att man har full kontroll på var källkoden lagras, dvs din egen server/dator.
Med GIT har man ingen som helst koll på detta, och i princip vem som helst kan komma åt koden.

[sodjan]

Det där med att jobba "uppifrån" eller "nerifrån" är alltid en diskussion.

Jag anser att det övergripande designarbetet nog måste ske utifrån en
helhetssyn, så att man har de stora dragen klara för sig, vart man vill
komma, så att säga. Eller att se på det "uppifrån", om man vill.

Sen så är det ofta detaljer som man är osäker på, eller som man inte
tidigare har gjort i andra projekt. Där behövs ofta att man kör några
PoC'ar (Proof of Concept) så att man vet att man har lösningar på det
också. En snygg övergripande design kan annars falla ihop p.g.a. av
någon detalj som man inte hade helt klart om det fungerar eller inte.
Här är det alltså ett uppenbart nerifrån perspektiv som behövs.

Och visst är det bra med git, SVN o.s.v. Om man inte har ett OS som
sparar tidigare versioner av filer automatiskt. Det är ju inte riktigt
samma sak, men det räcker ofta väldigt långt.

[TomasL]

Fördelen med ett versionshanteringssystem är att man på ett enkelt sätt kan gå tillbaka till tidigare versioner, köra parallella versioner och senare gifta ihop dem, få koden versionsstämplad, jämföra versioner osv.

[sodjan]

Självklart är det bra, men inte alltid helt nödvändigt och det kan kosta
med än det smakar att konfigurera det hela korrekt. Om man däremot ser
ett mervärde i att lära sig just den tekniken ("versionshanterare") så är det
så klart helt OK.

[TomasL]

Ja naturligtvis, småprojekt, då klarar man sig utan, men om det växer, så är snart ett system för versionshantering oumbärligt.

[Jan Almqvist]

Med GIT har man ingen som helst koll på detta, och i princip vem som helst kan komma åt koden.

Öh, nej. ThomasL menar kanske GitHub. Det är inte samma sak som Git.
https://stackoverflow.com/questions/133 ... b#13321586

[arvidb]

Eller SVN, som jag använder själv.
Fördelen med svn är att man har full kontroll på var källkoden lagras, dvs din egen server/dator.
Med GIT har man ingen som helst koll på detta, och i princip vem som helst kan komma åt koden.

Som sagt, git är inte GitHub. Till skillnad mot svn som kräver att man arbetar mot en server så är git ett distribuerat system där en fullständig databas lagras lokalt (i .git-mappen i det lokala filträdet). Sen kan man jobba mot en server om man vill genom att göra push, men det är inte nödvändigt.

TomasL: Jag har jobbat en hel del med svn (även hjälpt till att konfigurera det för ganska komplexa arbetsgrupper) och kan absolut tipsa om att ta en titt på git också och göra en bedömning om det kan vara idé att byta. git är mycket mer kraftfullt och har t.ex. möjlighet för rebase innan push till central server, vilket gör att man slipper en massa merging och får en mycket tydligare kodhistorik.

[TomasL]

Ok, jo, jag antog att det var Github som avsågs.
Man behöver inte använda en "Server" med SVN, repon kan mycket väl ligga på en lokal disk i den lokala datorn.

[arvidb]

Sant. Skillnaden är att med Subversion så måste man om jag inte minns alldeles galet konfigurera upp en separat "lagringsplats", som man jobbar mot. Med git är det så att säga inbyggt. Det låter kanske inte som någon större skillnad men det ger en mycket större flexibilitet.

Men nu är detta rätt off topic inser jag. Sorry.

[arvidb]

Tillbaka till ämnet:

Jag har en viss koll på hur jag ska göra de enskilda delarna av projektet, läsa knappar, skriva till 16x2 LED-display, i2c hantering, temperatur/batteri-övervakning osv osv, men jag kan inte riktigt greppa hur helheten ska utformas..

Primärt frågar jag alltså efter en programvaru-struktur eller tankesätt att applicera vid lite mer "avancerade" projekt.

Det är lite svårt att komma med råd eftersom vi inte vet hur du har lagt upp saker idag och hur långt du har kommit med att integrera dessa olika delar. Men generellt kan man väl säga att det är en bra idé att följa objektorienterings-tänket: kapsla in data och låt varje del få en egen fil: en fil för koden som hanterar displayen, en för i2c, en för batteriövervakningen etc.

Varje del får då också en egen headerfil där du deklarerar ett "objekt" för delen samt de funktioner som ska användas för att arbeta med den:

Kod: Markera allt

#ifndef BATTERY_H
#define BATTERY_H

struct battery;

struct battery *battery_create(float low_voltage_cutoff);
float battery_get_voltage(struct battery* battery);
...

#endif /* BATTERY_H */

I motsvarande .c-fil har du implementeringen:

Kod: Markera allt

#include "battery.h"

struct battery {
	float voltage;
	float lvc;
	...
};

struct battery *battery_create(float low_voltage_cutoff)
{
	struct battery *b;

	b = calloc(1, sizeof(*b));
	b->lvc = low_voltage_cutoff;
	...

	return b;
}

Sen har du en huvudfil där du knyter ihop allt genom att skapa objekt och anropa funktioner på dessa. Och undvik globala variabler, se till att all data som en funktion behöver skickas med som parametrar.