嵌入式C文件结构建议

Question

我在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这种大小的链接也可能很好.也欢迎文学建议.

Answer 1

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

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

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

大多数大型项目大致都是这样运作的。如果它适用于大型项目，那么它也应该适用于较小的项目。但是，如果源文件的数量是一打或两个，我真的看不出将其拆分有什么意义 - 也许是“src”和“includes”，如果您愿意，也许还有“include/private”确保 API 是干净的。保持简单有很大的优势！

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

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