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.
Muß der Code geheim bleiben, oder warum Lib? Ich verwende bei den heutigen Rechnern/Compilern lieber SourceCode mit Konfigurations-Includes.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.