c - 嵌入式 C 文件结构建议

Question

我在 C 中的典型嵌入式软件中找不到关于文件结构的好建议。SO 上有很多这样的问题和答案，但没有一个涵盖我提出的问题，或者似乎适用于 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，但会非常感谢洞察力。如何解决我描述的相关缺点？其他选择？

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

score 3 · Accepted Answer

在如此有限的内存量下，应用程序 + 操作系统将相当小。我从事的项目有数 GB 的源代码、数千个模块的数量，以及构建“千兆字节”范围内的可安装二进制文件。当您达到该大小时，您肯定需要将头文件等放在正确的位置。

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

每个模块的源文件。模块可以通过“使用”（例如“基本/操作系统”、“图形”、“音频”、“网络”、“UI”、“应用程序”等）分成更大的组。
每个模块都有一个“导出的包含”列表（从零到相当大），在构建模块时将其复制到一般的“${ROOT}/includes”类型目录。这提供了 EXTERNAL 接口，但作为模块本身生成的目标文件也可以使用“${module}/includes”，其中有私有声明和定义，而不是对 API 用户“公开”的。

这大致是大多数大型项目的工作方式。如果它适用于大型项目，那么它也适用于小型项目。但是，如果源文件的数量是十几个或两个，我真的认为拆分它没有多大意义 - 可能是“src”和“includes”，如果你愿意，也可能是“include/private”以确保 API 是干净的。保持简单有很大的好处！

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

您还应该有一套关于您公开的方式和内容的规则，并在代码审查期间检查是否遵循这些规则。