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 !
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
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).
Gast
#3410191
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.