Vorgehensweise für Programmaufbau?

[squelver]

Hi ihr \/

Wenn ich mal dazu komme, dann probier ich hier und da mal n Programmschnipsel oder eine Funktion aus.

Nu mache ich mir aber schon Gedanken, wie man "richtig" eine Struktur ins Programm bekommt bzw. wie man der Reihe nach "richtig" sein Programm auf- und ausbaut.

Womit gehts los? (ausser mit dem Grundgerüst)

Gruß copi

[askazo]

Eine wirkliche Richtlinie gibt es da glaube ich nicht.
Da hat halt jeder seinen eigenen Stil.

Ich unterteile meine Programme normalerweise in Hardware- und Software-Funktionsgruppen.

Wenn ich z.B. einen externen DAC verwende, kommen alle Funktionen, die diesen Baustein betreffen (Initialisierung, Ansteuerung), in eine eigene C-Datei, die nach dem Baustein benannt wird. Die Prototypen und defines dafür landen in der passenden Header-Datei. Das wäre dann ein Beispiel für eine Hardware-Funktionsgruppe.

Da ein Controllerprojekt in der Regel nicht nur eine Aufgabe erfüllt, unterteile ich auch noch in Softwarefunktionsgruppen. Bei einem Roboter könnte das z.B. eine Gruppe für Fahrfunktionen, eine für Sensorikfunktionen, eine für Schnittstellenfunktionen usw. sein.

Im das Hauptprogramm fängt dann - nach der eventuellen Deklaration von lokalen Variablen - mit den Initialisierungsfunktionen der einzelnen Funktionsgruppen an. Danach kommt dann die Hauptschleife, in der die Verknüpfung der einzelnen Funktionsgruppen stattfindet. In der main.c steht bei mir außer der main() keine weitere Funktion.

Für die Benennung von Variablen halte ich mich zumindest halbwegs an die ungarische Notation. Ist zwar Anfangs ein wenig lästig, wird aber schnell zur Gewohnheit und erleichtert ein späteres lesen des Programms - auch für andere - ungemein.

Dokumentation des ganzen Codes - z.B. mit Doxygen - halte ich auch für sehr sinnvoll.

Gruß,
askazo

[Ceos]

meine (zugegeben eher selten verwendete) optimale herangehensweise ist:

erstmal die initialisierung in eine methoden fassen, dann überlegen welche schnittstellen man brauch und dafür die notwendigen kommandos in methoden fassen, inklusive initialisierung

dann die prozedurprototypen zwischen variablen deklaration und main-methode einsetzen, die methoden kommen ans ende der datei

dann die ISRs zwischen prototypen und mein methode (wenn ich wüsste dass man ISRs auch auber als prototypen deklariern kann würd ich sie auch ans ende der datei verbannen)

und dann in der main das programm schreiben


generell ist das schreiben des programms an sich (bei mir zumindest) problembezogen, ich zerlege mein problem in teilbereiche und schreibe mir kleine programme um die funktionen zu testen und zu optimineren, achte dabei aber immer darauf, dass die programme sich untereinander später nicht behindern

dann füge ich sie stück für stück in einem programm zusammen, optimiere das zusammenspiel und lege eventuell doppelt verwendete funktionen (timer z.B.) zusammen

abschliessend wird noch ein wenig "inline" verteilt wo es hilft und dann nochmal alles aufgeräumt und bei bedarf alphabetisch sortiert und sauber durchkommentiert (obwohl ich letztere 2 aktionen gern auslasse ^^)

ich hoffe das beantwortet deine frage zumindest teilweise

EDIT: ich muss dem vorposter zustimmen, am besten wäre es natürlich einzelne sachen auszulagern und mit headerfile zu arbeiten statt mit prototypen ... ist halt nur so ne gewohnheit von mir beim proggen mitm atmel, das AVR studio lädt leider nciht so richtig ein mit zig files gleichzeitig zu hantieren

[squelver]

Vielen Dank für die ausführlichen Antworten, dass ist eine sehr große Hilfe \/

Also generell ist es also besser, Programmteile in eine separate Datei zu packen und die dann über den Header zu laden.

Dabei würde mich interessieren, ob es zeitlich Nachteile gibt, wenn etwas aus einer externen Datei reingeladen wird?
Wird bei Programmstart alles geladen (was im Header angegeben ist) und bleibt solange im Hintergrund, bis es Verwendung hat oder nur auf Anfrage?

[Hubert.G]

Wenn es nicht nur eine Kleinigkeit ist mach ich mir auf einem Blatt Papier ein Ablaufdiagramm mit den grundsätzlichen Funktionen.
Wenn ein Programmteil eventuell in anderen Programmen wieder verwendet werden kann, ist eine separate Datei mit Header günstig.
Ob du Funktionen in eine eigene Datei packst oder alles in einer Datei lässt, ist vollkommen egal. Nach dem Compilieren packt der Linker ohnehin alles zusammen. Der Programmablauf steht dann im Flash und wird von dort aus abgearbeitet.

[askazo]

@Ceos: Ich habe eigentlich keine Probleme, mit dem AVR-Studio mit vielen Dateien zu hantieren. Im "AVR GCC"-Fenster sehe ich alle Dateien des Projektes auf einen Blick und kann diese per Doppelklick öffnen. Die Tab-Leiste unter dem Editor-Fenster ist allerdings wirklich schlecht gemacht, aber da kann man auch drauf verzichten.

@copious: Nachteile gibt es bei der verwendung externer Dateien nicht. Der Linker bastelt ja alle Dateien zu einem Hex-File zusammen. Der Prozessor bekommt nachher nicht mehr mit, ob eine Funktion in der Main-Datei oder in einer externen Datei stand.

Der große Vorteil dieser Aufteilung ist die modularität. Ich habe mir z.B. mal eine Datei mit Funktionen für die SPI-Schnittstelle programmiert (Initialisierung, Senden, Empfangen). Wenn ich nun SPI brauche, muss ich nur die spi.c und die spi.h in mein Projektverzeichnis aufnehmen und kann die Schnittstelle verwenden.

askazo

[squelver]

Hi

Da fehlte mir wohl etwas Wissen bzw. war mir das nicht klar, dass der Maschinencode aus den einzelnen Dateien was komplettes macht. War immer der Meinung, es würde so aufm Controller abgelegt, wie ich es in meinem Verzeichnis habe

Dann werd ich das ebenfalls so machen, dass ich die einzelnen Programmteile extrahiere.

Bei meinem Board brauchte ich bisher nur auf Compilieren klicken und dann hab ich mein Programm aufm Controller \/

[Besserwessi]

Zu sehr sollte man den Code aber nicht auf verschiedene Files aufteilen. Sinnvoll ist das vor allem wenn man so Teile Wiederverwenden kann. Man kann so schon getesteten Code wiederverweden, und wenn man dann später doch noch mal einen Fehler findet, kann man ihn besser in allen betroffenen Projekten korrigieren.

Der Compiler kann etwas besser optimieren wenn der Code aus eine File kommt. So groß ist der Unterschied aber nicht.

Je nach Umfang des Programms sollte man auch vorher auf Papier (oder als text file) planen was man an Daten und Unterprogrammen braucht. Auch bei den doch eher kurzen Programmen für µCs kann das helfen.

[squelver]

Klingt einleuchtend, gewisse Vorstellungen von den einzelnen Aufgaben und Funktionen hab ich mittlerweile, werd mir diese erstmal notieren \/

[squelver]

Hi ihr

Ich hab hier meine Vorstellungen, was ich für die Programmierung benötige.

- 4x Spannung messen -> Winkelbestimmung der Gelenke
- 1x Zustand messen -> Bodenkontakt

- Routine Datenerfassung und Vergleich -> bestimmte Winkel und Zustand Bodenkontakt / Ist & soll
- Datenauswertung und Anzeige -> Anzeige über LCD
- Richtungsbestimmung bzw. Ausführung von Anweisungen -> Bewegungsabläufe
- Verarbeitung von Ereignissen -> Kollision / nichterreichte Zustände

- allgemeine Spannungsüberwachung -> Betriebsspannung
- ...

Gibt es was, was noch wichtig ist? Gehe ich manchmal falsch an die Sache ran?