Modularisierung C-Code

[Walter S. (walters)]

Hallo,

ich habe unter ATMEL Studio 6.1 ein Projekt gestartet und "mit Leben" 
gefüllt
(d.h. die Anwendung läuft auf einem ATmega32U4 breakout-board).
Wie muß ich vorgehen, um das Projekt zu modularisieren ? (d.h. einzelne 
functions in getrennte Quelldateien zu verlagern, alle Quelldateien zu 
übersetzen und die einzelnen Objekt-Module wieder zusammenzubinden)

Für Hinweise bin ich sehr dankbar !

[Karl H. (kbuchegg)]

Walter Schmidt schrieb:

> (d.h. die Anwendung läuft auf einem ATmega32U4 breakout-board).
> Wie muß ich vorgehen, um das Projekt zu modularisieren ? (d.h. einzelne
> functions in getrennte Quelldateien zu verlagern

Nicht: Functions!

Sondern Module.
Alle zb LCD Funktionen gehören zusammen und kommen in eine LCD-Datei. 
Alle UART Funktionen gehören zusammen. Alle ADC Funktionen. Alle 
Funktionen die sich mit, was weiß ich, Bewegungssteuerung von Servos 
beschäftigen.

Eben Module.

> Für Hinweise bin ich sehr dankbar !

FAQ: Header File - wie geht das

[Falk S. (falkschilling)]

Hallo Walter,

generell ist es sinnvoll, nach Gemeinsamkeiten semantisch zu ordnen. Das 
natürlich unter der Voraussetzung, dass dein Code nicht zu stark 
funktional gekoppelt ist. Für die AVRs könntest zu z.B. Ansteuerungen 
von einzelnen Komponenten, die eine definierte Aufgabe erledigen, in ein 
extra Modul packen. Entsteht so eine Menge von .c-Dateien, die wieder 
eine Schnittmenge von gemeinsamen Funktionen haben, könnte man diese 
auch wieder in ein extra Modul packen. Usw. usf. als iterativer Prozess.

Beispiel: Ansteuerung ADC mit zwei Kanälen, ein Kanal für 
Temperaturerfassung, ein anderer z.B. für eine Spannungsüberwachung.

Dann entstünden als Beispiel zwei Module (nach Aufgabe sortiert):
• temperature.c
• voltage.c

Nutzt du für die Ansteuerung des ADCs in beiden dieser .c-Dateien die 
gleichen Funktionen für den ADC, könntest du diese auch noch in eine

• ADC.c

packen. Daher, wenn du deinen Code refactoren musst/willst, solltest du 
dir mal das SOLID-Prinzip 
[http://de.wikipedia.org/wiki/Prinzipien_objektorientierten_Designs] 
anschauen.

Funktioniert auch nicht-objektorientiert mit ANSI-C, siehe James 
Grenning: Test-Driven-Development with Embedded-C (ISBN 978-1934356623).

[W.S. (Gast)]

Karl Heinz schrieb:
> Alle UART Funktionen gehören zusammen.

Ja.
Der Knackpunkt ist, was in die Header-Datei wirklich kommen muß.

Walter Schmidt schrieb:
> Für Hinweise bin ich sehr dankbar !

Beispiel:
Ich hab z.B. mehrere inhaltlich ziemlich unterschiedliche Module (ich 
sag dazu lieber 'units') für nen Virtuellen COM-Port per USB geschrieben 
- für unterschiedliche µC mit unterschiedlichen Usb-Cores. ABER: die 
Headerdatei ist für alle gleich. Obendein sind die Schnittstellen 
dieser virtuellen COM-Ports ganz genau so wie die von richtigen UARTS in 
den Controllern. Das heißt, die aufrufenden Programme können in diesem 
Punkte hardwareunabhängig geschrieben werden. Diese Units sind also 
quasi ne HAL. SOWAS sind die richtigen Kandidaten für die 
Modularisierung.

Also: nicht blind und nicht bloß formal vorgehen, sondern sich zuvor was 
dabei denken.

W.S.