Hallo, da ich mich derzeit mit einer autonomen Flugsteuerung befasse, die recht komplex ist frage ich mich wie man große Projekte in einer IDE wie zb EmBlocks anlegt? Ardupilot zb besteht aus CMSIS StdPeripherals NuttX RTOS Middleware Flight Control Es ist ja nicht so, dass man auf einen uC ein RTOS spielt und dann die eigene Software drüber brennt. Das alles wird ja zu einem Hex File kompiliert und auf einmal geflashed. Es geht dabei vor allem um die Makefiles, die ja erstmal von der IDE selbst erzeugt werden, indem sie die Abhängigkeiten analysiert. Jedoch verwendet zb Ardupilot etliche cmake Files, also Unter-Makesfiles im RTOS. Wie das alles genau zusammen hängt weiss ich auch nicht. Die müssen ja auch aufgerufen werden. Nehmen wir einfach mal an, ich möchte ChiBios verwenden, dazu uGFX als eigenes Grafilkomdul und darüber meine Anwendung schreiben, die die Funktionen von uGFX verwendet. Also 4 Ebenen ingesamt. Wie sieht sowas praktisch aus?
Moin, Du nimmst dir ein Beispiel von Chibios. Und siehst dir das Makefile mal an. In dem Hauptmakefile "Makefile" werden diverse sub Makefiles "bla.mk" eingebunden. uGFX hat auch so ein File. Das fügst du dort an. In diesem *.mk Files steht dann z.b. eine Konstante wie UGFX_SRC = .... mit den diversen Sourcedateien von uGFX und vllt UGFX_INC = ... mit den Include-Pfaden des Paketes. Diese Konstanten fügtst du im "Makefile" unter C_SRC bzw. USER_INC hinzu. Fertig. ggf. musst du noch Konstanten Definieren um uGFX einzustellen. Das findest du aber in der Doku von uGFX, oder du versuchst dein Projekt einfach mal zubauen. Dann meckert der Compiler schon an was fehlt. Und das kannst du dann im Code suchen, bzw googlen. Aber mit einer guten IDE wie Eclipse findest du die Konstanten auch ohne google. Gruß Tec
Christian J. schrieb: > Es geht dabei vor allem um die Makefiles, die ja erstmal von der IDE > selbst erzeugt werden, indem sie die Abhängigkeiten analysiert. Das ist meiner Meinung nach gar keine gute Idee: Denn damit machst Du Dein ganzes großes Projekt von einer bestimmten Version einer IDE abhängig. Nur mit dieser Version der IDE und den richtigen Checkboxen an den richtigen Stellen ganz tief unten in irgendwelchen Menüstrukturen bekommst Du hinterher wieder das selbe Ergebnis raus. Wenn Du auf eine neue Version der IDE umsteigst, auf eine ganz andere IDE umsteigst oder Dich irgendwo in den tiefen Menüstrukturen verlierst, kommt hinterher ein anderes Binary raus, weil die neue IDE die Abhängigkeiten irgendwie anders feststellt etc. Du hast hinterher in Deinem Projekt schon genug Abhängigkeiten, eine zusätzliche und unnötige von der IDE will man da möglichst vermeiden. Auch sind IDEs wegen der ganzen GUI-Komponenten meist deutlich schwieriger in ein Versionskontrollsystem einzuchecken und nach vielen Jahren wieder auszuchecken um dann Binaries genau wie damals neu compilieren zu können. Beim Rest der Toolchain, wie z.B. Compiler und Linker, ist das wesentlich leichter zu machen. Daher nimm für die Steuerung des Buildvorgangs direkt Makefiles oder erzeuge diese mit CMake. Gute IDEs können Makefiles oder CMakeLists direkt anpassen. Wenn Deine das nicht kann, dann mach es halt von Hand. Auch die ganzen Compileroptionen müssen unbedingt in Dateien (entweder direkt Makefiles oder deren Includes) und können damit dann problemlos mit eingecheckt und reproduzierbar genutzt werden.
Gerd E. schrieb: > Du hast hinterher in Deinem Projekt schon genug Abhängigkeiten, eine > zusätzliche und unnötige von der IDE will man da möglichst vermeiden. Das mag sein aber ich habe mich vor langem für diesen Weg entschieden, da ich nicht kompatibel sein muss im Hobbybereich und mir die IDE viel Mühen abnimmt. Dafür nehme ich den Preis in Kauf dass die Prjekte daran gebunden sind.
Christian J. schrieb: > Das mag sein aber ich habe mich vor langem für diesen Weg entschieden, > da ich nicht kompatibel sein muss im Hobbybereich und mir die IDE viel > Mühen abnimmt. Dafür nehme ich den Preis in Kauf dass die Prjekte daran > gebunden sind. Nun gut. Aber Du sprachst ja explizit "große" Projekte an. Und da gilt noch was anderes: Großes Projekt -> höhere Komplexität und meistens aus noch mehr externe Abhängigkeiten Die musst Du einmal am Anfang in den Griff bekommen, das geht mit Makefiles meist leichter als mit der IDE. Schau Dir mal z.B. die genannten RTOSse oben an, deren Buildprozess in ner IDE abzubilden und über Versionsgrenzen des RTOS hinweg konstant zu halten wird kein Zuckerschlecken. Außer dem RTOS hast Du noch andere Abhängigkeiten wie z.B. ein HAL, Bibliotheken wie OpenCV, TCP-Stack,... - für die gilt das selbe. Und während das Ganze dann entwickelt wird musst Du die höhere Komplexität im Griff behalten. Es kann z.B. vorkommen, daß Du einen Bug einbaust und das erst mal ne ganze Weile nicht bemerkst. Wenn Du es dann bemerkst, ist es wegen dem großen Projekt und vielem Code nicht so einfach rauszufinden, wo der herkommt und wo er steckt. Er könnte z.B. durch ein Compiler-Update gekommen sein. Hier können einem Dinge wie z.B. ein git bisect sehr helfen. Dafür sollte aber die Toolchain mit in der Versionsverwaltung sein und der Buidprozess soweit wie möglich automatisierbar sein. Und eben da steht Dir die IDE nur im Weg wenn der Buildprozess von ihr abhängig ist.
Gerd E. schrieb: > Wenn Du auf eine neue Version der IDE umsteigst, auf eine ganz andere > IDE umsteigst oder Dich irgendwo in den tiefen Menüstrukturen verlierst, > kommt hinterher ein anderes Binary raus, weil die neue IDE die > Abhängigkeiten irgendwie anders feststellt etc. So schlimm ist es nicht generell. Viele Haken haben ja nichts mit der eigentlichen Compilierung zu tun. Das Problem als solches (Wechsel der Umgebung) hat man nach Jahren generell. Es wäre dann immer wieder ein Problem die alte Umgebung zum Laufen zu bekommen. Wichtig wäre aber generell, die sich am Ende ergebenen Compiler und Linker Kommandozeilen für später zu merken. Sie helfen, wenn man mal das Projekt neu aufsetzen muss. Wichtig wäre auch alle ThirdParty Sourcen als Teil des Projektes zu haben. Dann hat man alles beisammen (für Backup, Versionierung usw.)
Steffen R. schrieb: > So schlimm ist es nicht generell. Viele Haken haben ja nichts mit der > eigentlichen Compilierung zu tun. Oh doch. Ich hab das alles mit diversen IDE's durch. je nach diversen Häkchen an z.T. völlig unterschiedlichen Stellen ändern sich die Kommandozeilenparameter aller beteiligten Tools und es kommt schlußendlich was anderes heraus. Ich bin deshalb ganz strikt dazu übergegangen, die ganzen Toolaufrufe per Skript zu formulieren, bei Windows also als Batchdatei nebst .xcl für Compiler und Linker. Woanders halt ein Shellscript, das ist ja auch recht schnell geschrieben. Ob da jemand nun "Make" ruft oder nicht ist Geschmackssache, ich benutze make gar nicht, weil ich eine ganze Handvoll von "make's" unterschiedlichster Herkunft auf der Platte habe(n) (muß) - und alle sind zueinander völlig inkompatibel. Dem TO rate ich was ganz anderes: nämlich Modularisierung und API's, also auch im Binären festgeschriebene OS-Aufrufe. Genau so kriegt man nämlich eine saubere Trennung zwischen den verschiedenen Schichten hin. Bei kleinen Projekten ist das herzlich egal, bei den angesprochenen größeren Projekten jedoch nicht. W.S.
W.S. schrieb: > Oh doch. > Ich hab das alles mit diversen IDE's durch. je nach diversen Häkchen an > z.T. völlig unterschiedlichen Stellen ändern sich die > Kommandozeilenparameter aller beteiligten Tools und es kommt > schlußendlich was anderes heraus. Ich nutze genauso zig IDEs der verschiedensten Hersteller. Und ich kann aus meiner Erfahrung sagen: Man kommt immer an die Optionen heran, mit denen letztendlich compiliert wird. Und die Häckchen für die Compilierung sind immer auf einen bestimmten Bereich begrenzt. Es gibt mittlerweile viele, viele Optionen, die sich nicht auf die Compilierung beziehen. Extrembeispiel Eclipse. Ich stimme ja zu, dass der beschriebene Weg von W.S. das Risiko sich verändernder Einstellungen reduziert. Und auch die in seinem ersten Post geschriebenen Gefahren könnte man so in den Griff bekommen. Da der TO jedoch keine Erfahrung mit etwas komplexeren Projekten hat (ist ja nicht wirklich ein großes Projekt), bezweifle ich, dass er bei Bedarf sich daraus ergebenden Möglichkeiten nutzt. Und ich bezweifle, dass er alles sichert/zusammenhält, was für das Projekt letztendlich relevant ist (wenn man es mal auf einen älteren Stand zurücksetzen will.)
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.