嵌入式C文件结构建议

Question

在C中的典型嵌入式软件中，我找不到关于文件结构的好建议。这里有许多这样的问题和答案，但没有一个涉及到我所关心的问题，或者似乎适合于C中的嵌入式系统。

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

1.层

我看到了按层组织的源代码，每个层都有自己的目录：

• 应用程序
• 传输层
• 硬件抽象层

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

2.目录中的模块，$ROOT中的h文件/包括/

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

• 模块目录中的所有源代码(所有C文件和所有仅在模块内使用的头文件)
• 将API头文件发布到模块目录之外的$PROJ_ROOT/includes中。

这样，我就可以在我的编译器命令中有-I$PROJ_ROOT/includes (或等效的)，而在我的#include语句中没有搜索路径。

一个问题是API位于模块目录之外，从而破坏了封装。例如，在VCS中维护一个独立的模块就更困难了。

3.目录中带有API的模块

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

4.目录中有API的模块，子dir中的私有结构。

只将API头文件直接放在模块目录中，将所有其他文件放在一个子目录或多个目录中。这是可行的，但我觉得这个结构越来越复杂，我不太喜欢。

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

链接到成功的开源软件SW的这种大小也可能是不错的。也欢迎文献咨询。

Answer 1

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

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

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

这大概是大多数大型项目的工作方式。如果它对大型项目有效，那么对于较小的项目也应该是好的。但是，如果源文件的数量是十几个或二十个，我认为完全没有必要分割它--也许是一个"src“和”include“，如果您想确保API是干净的，也可能是一个”include/私有“。保持简单有很大的优势！

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

您还应该有一组关于如何公开和公开哪些内容的规则，以及在代码评审期间检查是否遵循这些规则。