Ich kann keine guten Vorschläge zu Dateistrukturen in typischer eingebetteter Software in C finden. Es gibt eine Reihe solcher Fragen und Antworten hier auf SO, aber keine, die die von mir präsentierten Probleme abdecken oder die an eingebettete Systeme in C angepasst scheinen.
Ich verstehe, dass es keine Silberkugel gibt. Wenn dies zu engen Vorschlägen führt, muss meine typische Anwendung auf Ziele mit 8 bis 32 kB Flash und einigen kB RAM passen. Uhren im Bereich von 4 bis 20 MHz.
Ich habe Quellcode in Schichten organisiert gesehen, jede Schicht hat ihr eigenes Verzeichnis:
Das Problem besteht darin, dass Module oft Dateien in all diesen Layern haben, so dass das Trennen von Layern in Verzeichnissen bedeutet, dass die Dateien eines einzelnen Moduls überall verstreut sind. Schlechte Kapselung.
Ein Verzeichnis pro Modul. Das Gute ist eine echte Kapselung. Was ich nicht genau weiß, ist, wie man die API eines Moduls veröffentlicht. Open-Source-PC-Anwendung scheint zu:
$PROJ_ROOT/includes . So kann ich -I$PROJ_ROOT/includes (oder gleichwertig) in meinem Compiler-Befehl haben und keine Suchpfade in meinen #include -Anweisungen.
Ein Problem besteht darin, dass die API sich außerhalb des Modulverzeichnisses befindet, wodurch die Kapselung unterbrochen wird. In einem VCS ist es beispielsweise schwieriger, ein Modul eigenständig zu verwalten.
Wie oben, aber mit der API-Header-Datei im Modulverzeichnis. Korrekte Kapselung und einfachere Versionssteuerungsmodule, aber die API-Header-Datei befindet sich auf derselben Ebene wie die anderen Modul-Header-Dateien, die privat sein sollten. Die Versuchung, eine solche "private" Header-Datei außerhalb des Moduls einzubauen, kann für einen zukünftigen Entwickler zu groß sein, und es ist nicht sichtbar, welche h-Datei öffentlich sein sollte und welche nicht.
Fügen Sie nur die API-Headerdatei direkt in das Modulverzeichnis und alle anderen Dateien in ein Unterverzeichnis oder mehrere. Das könnte funktionieren, aber ich fühle, dass die Struktur immer komplexer wird, was ich nicht wirklich mag.
Ich fühle, dass ich für 2 oder 4 gehen sollte, würde aber Einsicht sehr schätzen. Wie gehe ich auf die damit verbundenen Nachteile ein? Andere Alternativen?
Links zu einer erfolgreichen Open-Source-Software dieser Größe könnten ebenfalls gut sein. Literaturberatung ist ebenfalls willkommen.
Mit solch einer begrenzten Menge an Speicher wird die Anwendung + OS ziemlich klein sein. Ich habe an Projekten gearbeitet, die mehrere Gigabyte Quellcode enthalten, und die Anzahl der Module zu Tausenden, und installierbare Binärdateien, die im "Gigabyte" -Bereich liegen. Wenn Sie zu dieser Größe kommen, müssen Sie unbedingt Ihre Header-Dateien usw. an der richtigen Stelle haben.
Ich denke, das Folgende ist jedoch ein ziemlich anständiges Konzept:
Das ist grob gesagt, wie die meisten großen Projekte funktionieren. Wenn es für große Projekte funktioniert, sollte es auch für kleinere Projekte in Ordnung sein. Wenn die Anzahl der Quelldateien jedoch ein oder zwei Dutzend ist, sehe ich nicht viel daran, sie überhaupt aufzuteilen - vielleicht ein "src" und "includes", vielleicht auch ein "include / private", wenn Sie wollen um sicherzustellen, dass APIs sauber sind. Es einfach zu halten hat große Vorteile!
Beachten Sie, dass der Teil "exports" erstellt werden muss, bevor die eigentlichen Module kompiliert werden, oder Sie müssen sicherstellen, dass keine Kommunikation zwischen den Modulen stattfindet [oder zumindest sicherstellen, dass keine "frühen" Module benötigt werden jede der Header-Dateien der "späteren" Module - das wird ziemlich hart, wenn das System wird groß].
Sie sollten auch eine Reihe von Regeln darüber haben, wie und was Sie verfügbar machen und während der Code-Überprüfung prüfen, ob diese Regeln befolgt werden.
Tags und Links c architecture embedded project-management