Hallo,
ich schreibe mir gerade eine Library für AVR in C. Diese soll nicht
unbedingt als Source in ein Projekt eingebunden werden müssen, sondern
eher als lib Datei (.lib, .dll, .so, ihr wisst was ich meine) mit den
Headern zur Verfügung stehen.
Jetzt ist für mich die große Frage:
Wie kann ich so ein Library haben im AtmelStudio und trotzdem die
Pin-Belegungen etc. in dem Projekt festlegen, das die Lib benutzt?
Also:
* Ich möchte ganz explizit nicht Implementierungen in das
"Anwenderprojekt" schleppen.
* Ich möchte aber die Definitionen im "Anwenderprojekt" ändern können.
Ist so etwas mit dem Atmelstudio einfach möglich? Makefiles kann ich
nicht besonders leiden. Ich möchte aber auch nicht alle Library Sourcen
in ein kleines Projekt importieren müssen.
Ich weiss nicht ob ich das Problem richtig verstanden habe aber ich
würde das so machen:
In der Lib sind generische GPIO Funktionen wie diese:
GPIO_INIT(Port, Pin, Mode)
(Port: GPIO-Port, Pin 0..7, Mode: Input, Output, OpenDrain,...)
GPIO_PIN_SET(Port,Pin)
GPIO_PIN_CLR(Port,Pin)
...
In einem Header File zur Lib hast du dann Defines für jeden Pin des
Controllers, die du an die Funktion übergeben kannst.
In der Anwendung definierst du dnan z.B:
#define LED_Pin GPIO_Pin_3
#define LED_Port GPIO_Port_A
und rufst GPIO_PIN_SET(LED_Port, LED_Pin) auf.
Man kann beim AVR die Ports auch memory-mapped ansprechen.
Dann braucht man aber für jeden Pin die Adresse und die Pinmaske, macht
also 3 Byte an Parametern je Pin.
Und der Zugriff ist auch nicht mehr atomar, muß also mit Interruptsperre
gekapselt werden.
Der SRAM-, Flash- und Zeitverbrauch ist also deutlich höher.
Nein, es geht hier einfach um Best Practices. Ich möchte den gleichen
Quelltext und die gleichen Ansteuerungsroutinen nicht immer in jedes
Projekt kopieren müssen.
Coder schrieb:> Ich möchte den gleichen> Quelltext und die gleichen Ansteuerungsroutinen nicht immer in jedes> Projekt kopieren müssen.
Da hast du doch schneller ne Headerdatei mit eingefügt als eine Lib zu
erstellen und diese jedes mal einzufügen.
Ich würde das sauber in eine Headerdatei schreiben und fertig. Die
ganzen Schnittstellen wie ADC, DAC, USART,.... könnte ich mir eher in
einer Lib vorstellen.
Coder schrieb:> nicht immer in jedes Projekt kopieren müssen
Es gibt auch noch eine Welt außerhalb des kopierens ;-)
SCM bietet da faszinierende Möglichkeiten, die meisten IDEs könnne auch
aus "fremden" Projekten Code nutzen (wie würde eigentlich deine dll ins
Projekt kommen... kopieren?).
Das Problem sind vor allem ggf. die Prozessorspezifischen Eigenheiten,
du müsstest also im blödstem Fall die Lib für jeden Prozessortyp einmal
übersetzen.
Ja das stimmt, das ist eigentlich eine gute Idee. Problem ist dann aber,
dass man wohl die Header abändern muss und die dürfen dann nicht wieder
eingecheckt werden bzw. werden auch leicht bei Updates überschrieben.
Außerdem landen die Sources ja im Endeffekt wieder in der gleichen
Working Copy, was mir ehrlich gesagt nicht gefällt. Ich hätte gerne ein
Konfigurationsmanagement mit den Vorteilen, dass ich PIN-Belegungen
einfach spezifieren kann, aber den implementierenden Code nicht in ein
AtmelStudio Projekt einbinden muss. Der kann ja im Hintergrund da sein
oder von einem Build-System automatisch geholt werden, aber das würde
ich zumindest gerne verstecken, es interessiert ja im Projekt nicht und
ist nur Noise.
Das einzige was ich im Projekt wirklich sehen möchte, ist die
Pinbelegungs-Konfiguration.
Coder schrieb:> Ja das stimmt, das ist eigentlich eine gute Idee. Problem ist dann aber,> dass man wohl die Header abändern muss und die dürfen dann nicht wieder> eingecheckt werden bzw. werden auch leicht bei Updates überschrieben.
Du musst in deiner Projektumgebung eine 2-teilung erreichen.
Der eigentliche Source Code bleibt ein für alle mal auf seinem
Verzeichnis. Den gibt es nur einmal.
In die Projektsteuerung kommt lediglich ein Verweis auf diesen immer
gleichen Code rein.
Die Konfigurationsdaten, also das Header-File hingegen, das hast du auf
deinem Projektverzeichnis.
Die Schwierigkeit besteht jetzt darin, den 'Lib'-Source Code dazu zu
bringen, dass er sich das Konfigurationsheaderfile von deinem
Projektverzeichnis holt. Normalerweise bedeutet das, dass man bei den
Compiler-Einstellungen mit den Include-Verzeichnissen etwas rumspielen
muss.
> Außerdem landen die Sources ja im Endeffekt wieder in der gleichen> Working Copy, was mir ehrlich gesagt nicht gefällt.
Das kommt drauf an.
Denn auf der anderen Seite kann es auch ganz sinnvoll sein, dass man
dokumentiert hat, mit welcher Version der 'Library' das Programm
gelaufen ist. Denn auch Libaries entwickeln sich ja weiter. Auch
Source-Code Libraries.
> Konfigurationsmanagement mit den Vorteilen, dass ich PIN-Belegungen> einfach spezifieren kann, aber den implementierenden Code nicht in ein> AtmelStudio Projekt einbinden muss.
Einbinden musst du es.
Aber einbinden bedeutet nicht, dass du den Source Code auf das
Projekt-Verzeichnis kopieren musst. Dem Atmel Studio ist es prinzipiell
egal, auf welchen Verzeichnissen die Source Code Files liegen, die du in
einem Projekt hast.
Karl Heinz Buchegger schrieb:> Denn auf der anderen Seite kann es auch ganz sinnvoll sein, dass man> dokumentiert hat, mit welcher Version der 'Library' das Programm> gelaufen ist.
Mit SVN externals kann man sich sogar einen definierten Stand in "sein"
Projekt holen, sodass selbst ein Weiterentwickeln und Upgrade kein
Problem sein muss.
