应用错误收集

我在C中的典型嵌入式软件中找不到关于文件结构的好建议。这里有很多这样的问题和答案，但没有一个涵盖我提出的问题，或者似乎适用于C中的嵌入式系统。

我知道没有银弹。如果这有助于缩小建议，我的典型应用程序必须适合具有8到32 kB闪存和几KB RAM的目标。时钟频率范围为4至20 MHz。

1。层

我见过以层为单位组织的源代码，每个层都有自己的目录：

问题是模块通常在所有这些层中都有文件，因此在目录中分离层意味着单个模块的文件遍布整个地方。封装不良。

每个模块一个目录。好事是真正的封装。我不知道如何做得好是如何发布模块的API。开源PC应用程序SW似乎：

这样我可以在编译器命令中使用-I$PROJ_ROOT/includes（或等价物），而在我的#include语句中没有搜索路径。

问题是API在模块目录之外，从而破坏了封装。例如，在VCS中将模块维护为独立模块更加困难。

与上面相同，但使用模块目录中的API头文件。适当的封装和更容易的版本控制模块，但API头文件与其他模块头文件处于同一级别，这些文件是私有的。在模块之外包含这样一个“私有”头文件的诱惑对于未来的开发人员来说可能太大了，并且不知道哪个h文件是公开的，哪些不是。

将API头文件直接放在模块目录中，将子目录中的所有其他文件放在几个目录中。这可能有效，但我觉得结构变得越来越复杂，我不太喜欢。

我觉得我应该选择2或4，但我会非常感激洞察力。如何解决我描述的相关缺点？其他选择？

这种大小的成功开源SW的链接也可能很好。文学建议也很受欢迎。

由于内存量有限，应用程序+操作系统将相当小。我参与了几千兆字节的源代码项目，数千个模块的数量，以及构建“千兆字节”范围内的可安装二进制文件。当你达到那个大小时，你肯定需要在正确的地方有你的头文件等。

我认为以下是一个相当不错的概念，但是：

每个模块的源文件。模块可以通过“使用”（例如“Base / OS”，“Graphics”，“Audio”，“Network”，“UI”，“Apps”等）分成更大的组。
每个模块都有一个“导出包含”列表（从零到相当大），当构建模块时，它会被复制到一般的“$ {ROOT} / includes”类型目录。这提供了EXTERNAL接口，但作为模块本身生成的目标文件也可以使用“$ {module} / includes”，其中有私有声明和定义，而不是API的用户“公开”。

这大致是大多数大型项目的工作方式。如果它适用于大型项目，对于小型项目也应该没问题。但是，如果源文件的数量是十几个或两个，我根本没有看到分裂它的重点 - 也许是“src”和“includes”，如果你想要的话，也许也是“包含/私有”确保API干净。保持简单有很大的优势！

请注意，“export”部分需要在编译实际模块之前构建，或者您必须确保模块之间绝对没有交叉通信[或者至少确保没有“早期”模块需要任何“后来的”模块头文件 - 如果系统变得越来越大就变得非常困难。

您还应该有一套关于如何以及如何公开的规则，并且在代码审查期间检查是否遵循了这些规则。