Tag zusammen, ich habe ein AVR Projekt, dass ich mittels git verwalte. An dem Projekt arbeiten neben mir noch zwei andere Entwickler. Momentan arbeiten wir alle mit einer Testhardware mit "großem" ATmega1284P Controller. Auf dem Board werden alle Controllerpins rausgeführt, außerdem ist ein LCD zum Testen angeschlossen. Die zweite UART wird zum Debuggen benutzt. Nun ssteht bald der Schritt hin zur realen Hardware auf dem Programm.Dabei handelt es sich um eine extra angefertige Platine, auf der ein kleinerer Mega32 sitzt und auf dem nur die wirklich benötigten Pins benutzt werden. Auf einen Quarz wird verzichtet. So, das resultiert natürlich in einer angepassten Software. Registernamen werden sich ändern, Pinbelegungen ändern sich, Konfigurationen ändern sich, manche Module fliegen ganz raus (zweite UART, LCD). Die Frage ist nun, wie ich diesen Vorgang in git (oder generell, in einer Versionsverwaltung) abbilde. Mein erster Gedanke war, vor dem "Cut" alle offenen Branches in den master zurückzuführen, dass die Software erstmal komplett ist. Danach würde ich zwei Branches separat weiterlaufen lassen, einmal für den m128 und einmal für den m32. Hintergrund ist, dass unsre Testhardware weiterhin zum Entwickeln/Bugfixing genutzt werden soll. Allerdings bin ich mir nicht sicher ob das so passt. Ich müsste ja regelmäsig die Branches mergen. Dabei allerdings dann per Hand kontrollieren dass kein Controllerspezifisches Zeugs, wie Registernamen, gemergt wird. Das wird umständlich. Wie würdet ihr das handhaben? Was hat sich da bewährt?
Warum machst du nicht einfach je eine Controller-spezifische Konfigurationsdatei bzw. Config-Funktion? Dann kann du mittels DEFINE (oder im Makefile) festlegen, für welchen Controller du compilieren willst. Mit freundlichen Grüßen Thorsten Ostermann
Ich wuerde per defines zwischen den Versionen umschalten. Es gibt dann Builds fuer beide Targets die die passenden defines setzen.
Karl schrieb: > Die Frage ist nun, wie ich diesen Vorgang in git (oder generell, in > einer Versionsverwaltung) abbilde. Wie wär's mit "gar nicht"? ;-) Sourcecode kann für unterschiedliche Zielhardware übersetzt werden, das ist durchaus üblich so. Für die Verwaltung der Quelltexte an sich hat das keine wirkliche Auswirkung. Vielleicht mal abgesehen von einer Konfig-Datei oder den Makefiles, die man anpassen muss. Diese liegen natürlich auch im Repository.
Das ist eigentlich nicht die schlechteste Idee :-) Allerdings muss ich mir dazu wohl noch Gedanken machen, denn in einer #IFDEF Schlacht soll das Ganze nicht ausarten. Vor allem Funktionsaufrufe zu Test/Debuggfunktionen müssen aber irgendwie geschützt werden.
Karl schrieb: > Allerdings muss ich mir dazu wohl noch Gedanken machen, denn in einer > #IFDEF Schlacht soll das Ganze nicht ausarten. Vor allem > Funktionsaufrufe zu Test/Debuggfunktionen müssen aber irgendwie > geschützt werden. Dafür gibts diverse Möglichkeiten - ich beschränke z.B. die #ifdefs gerne auf die Headerdatei, in der dann je nach Konfiguration entweder die echten Funktionen deklariert oder Dummydefinitionen erzeugt werden. Zusätzlich sorgt das Makefile dafür, dass die zugehörige C-Datei mit den Funktionsdefinitionen nur eingebunden wird wenn die Konfiguration sie benötigt.
1 | #ifdef CONFIG_UART_DEBUG |
2 | |
3 | void uart_init(void); |
4 | void uart_putc(char c); |
5 | |
6 | #else |
7 | |
8 | #define uart_init() do {} while(0) |
9 | #define uart_putc(x) do {} while(0) |
10 | |
11 | #endif |
Statt der Leermakro-Definition könnte man auch "static inline void uart_init(void) {}" im Headerfile verwenden, der Compiler sollte dann den Aufruf der leeren Funktion komplett rausoptimieren. Welche Variante man für weniger böse hält hängt auch von den lokalen Code-Richtlinien ab, wahrscheinlich gibts da auch welche die beide davon verbieten würden.
Du kannst das Define auch einfach leer lassen:
1 | #ifdef CONFIG_UART_DEBUG
|
2 | |
3 | void uart_init(void); |
4 | void uart_putc(char c); |
5 | |
6 | #else
|
7 | |
8 | #define uart_init()
|
9 | #define uart_putc(x)
|
10 | |
11 | #endif
|
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.