如何在嵌入式项目中组织代码？

Question

高度嵌入（有限代码和ram大小）项目对代码组织提出了独特的挑战。

我见过很多没有组织的项目。 （主要是硬件工程师，根据我的经验，他们通常不关心代码的非功能方面。）

但是，我一直在尝试相应地组织我的代码：

1. 特定于硬件（驱动程序，初始化）
2. 特定于应用程序（不太可能重复使用）
3. 可重用，独立于硬件

对于每个模块，我尝试将目的保持为这三种类型中的一种。

由于嵌入式项目的规模有限以及对性能的重视，通常会保留这个组织。

在某些情况下，我目前的项目是MSP430上的有限DSP应用程序，具有8k闪存和256字节RAM。

Answer 1

我已经在各种目标微处理器（包括MSP430）上编写和维护了多个嵌入式产品（30多个和计数）。我最成功的“经验法则”是：

• 尝试尽可能模块化通用概念（例如，从应用程序代码中单独的驱动程序代码）。 - 它使项目的维护和重用/移植更容易在未来的另一个目标微型。
• 首先不要担心优化代码。尝试首先解决域的问题并优化第二个。 - 你的目标微处理器可以处理比你预期的更多“东西”。
• 努力确保可读性。虽然大多数嵌入式项目似乎都有较短的开发周期，但项目的寿命通常比您预期的要长，而另一个开发人员无疑必须使用您的代码。

Answer 2

我曾经研究过具有类似限制的8位PIC处理器。

你没有的一个限制是你做了多少评论或者你选择用什么方法命名你的方法，变量等。利用。速度和尺寸限制确实有时胜过组织，但你总能解释。

另一个提示是将逻辑源文件拆分成比你需要的更多的部分，然后通过#include将它们绑定在编译单元中。这允许您拥有大量可重用的代码（即使每个文件只有一个例程），但可以按照您需要的顺序组合。这很有用，例如在尝试满足编译单元大小限制时，或者选择下一个项目中需要哪些公共子程序。

Answer 3

我尝试组织它，好像我有无限的RAM和ROM，它通常很好。如其他地方所述，在您绝对需要之前不要尝试优化它。

如果你能得到一个具有更多资源的引脚兼容处理器，那么最好让它处理它，专注于良好的结构和布局，然后在你更好地理解代码时优化大小。

Answer 4

除特殊情况（参见注释）外，您的代码的组织对最终产品没有影响。 （代码的内容显然是另一回事）

因此，考虑到这一点，您应该像处理任何其他项目一样组织代码。

话虽如此，以下是相当典型的：

如果这是您之前已经处理过的处理器，或者将来要处理的处理器，您通常会希望保留一个专用的硬件抽象层，以便将来在项目之间共享。通常，此模块将包含用于管理任何uart，计时器等的例程。

通常，维护一组特定于平台的初始化和设置代码是合理的，这些代码执行所有配置和初始化，直到管理人员接管并运行您的应用程序。它还将包括特定于平台的hal例程。

执行/应用程序可能作为单独的模块维护。所有硬件特定代码都应隐藏在hal中（如上所述）。

通过像这样拆分代码，您还可以选择在完全不同的平台上编译和运行应用程序作为模拟，只需用模拟硬件的例程替换硬件特定代码即可。 这可能适用于您可能具有的单元测试和调试以及算法问题。

---

异常编译器限制可能导致的特殊情况。例如。我遇到过一些编译器，它们希望在一个目标文件中编译所有中断服务程序。

Answer 5

我曾经使用像Tmote Sky这样的传感器，我也看到了糟糕的组织，我不得不承认我已经做出了贡献。无论如何，我要说有些混乱，因为加载过多的模块或程序的太多部分也会导致（imho）资源查杀，所以要尽量了解组织和低资源可用性之间的门槛。 / p>

显然这并不意味着让caos开始，但是例如试着看一下tinyOS源代码和应用程​​序的组织，这是我想说的内容。

Answer 6

尽管有点痛苦，但是嵌入式C库中常见的一种组织技术是将每个函数和变量拆分为单独的C源文件，然后将生成的O文件集合聚合到库文件中。

这样做的动机是，对于大多数普通链接器，链接单元是一个对象，对于每个对象，您要么获得整个对象，要么不获取整个对象。由于C文件和目标文件之间存在1-1关系，因此将每个符号放在其自己的C文件中会为每个文件提供自己的对象。这反过来又让链接器仅引入实际使用的函数和变量的子集。

这种类型的游戏根本无法帮助他们乐意留作单个文件。