在为大型项目编写固件时应该遵守的注意事项
我的问题可能看起来如此普遍，但我真的需要你的帮助。我是新手嵌入式软件工程师，我用TI DSC和STM微控制器完成了一些小型项目，包括C和C++编程语言。但现在我要开始为一个大型项目编写固件，我正在寻找一种方法来模拟我的固件，然后再实施它。实际上，我有两个问题：在为大型项目编写固件时应该遵守的注意事项
1.我想知道专业嵌入式软件工程师在开始编写固件之前要做什么？（对于固件建模，使用的是适合固件的理性玫瑰或企业架构，我认为这两个适合于IT和软件应用而非固件）
2.什么重要规则在写固件的时候我必须观察一下？ 例如我考虑一下：
a.Never曾经投入了大量的代码放到中断服务例程
湾千万不要忙着等着回圈 我还有什么其他的事情要考虑？
这些类型的问题是题外话上如此，但无论如何，我会回答，因为这些非常重要的考虑因素的任何地方，不是一个真正的论坛。通常情况如下：
编写规范和要求。花一些时间在此，关注产品，而不是技术细节。 UML“用例”可以很方便，但常识也可以很好地工作。确保规范是一个活的文件，可以在必要时进行修改。
然后做方案设计，面向对象模型（称之为类/代码模块/翻译单元或者你会）。写下程序需要的代码模块，确保它们符合规范 - 理想情况下，每个要求导致特定的代码（稍后会导致对该代码的特定测试）。然后关注不同模块之间的依赖关系：这应该是一个“从上到下”的依赖关系树，驱动程序不依赖于HAL，而不依赖于调用者等等。用笔和纸画出这棵树。花式UML是好的，但没有必要。
你需要尽早考虑便携性。代码是否应该在项目之间移植？ （很常见）编译器之间？ （相当普遍）平台之间？根据所需的可移植性级别，您可以使用设计作弊并跳过一些HAL。但是，将驱动程序与应用程序分开几乎总是一个好主意。
关于“重要规则”，这些都没有关系的方案设计阶段。相反，这些应该在你的编码标准文件中。最好是用于每个项目的公司标准。它应该关注于禁止所有不良做法，并且还应包含风格指南。对于嵌入式系统，我强烈建议将这个文档建立在MISRA-C上，然后根据需要添加自定义规则（例如“保持ISR代码最小化”），然后在其上添加样式指南。请注意，编写这个编码标准是它自己的一个项目。
我觉得关于模块性的一点是这个答案中最重要的一点。其他的错误，比如缺乏可移植性和错误风格，更容易修复（尽管它们不应该在第一次被忽略），而当代码库并不是可怕的意大利面和遍布各处的依赖关系时。 – user694733
@ user694733确实。来自小规模项目的嵌入式程序员几乎没有或几乎没有程序设计，但往往无法认识到为什么这是必要的。所以他们写的东西没有模块化，结果紧密耦合：程序中的所有内容都取决于其他所有内容。全球范围内有数百个布尔“标志”和隐藏状态变量，以及意大利面全局数据。它变得越来越难以维持，直到它达到临界质量并且永久地出错。还没有真正的方法来恢复这些程序，它们必须从头开始重新编写。 – Lundin
@Lundin非常好的一点。但是这个金属的另一面。如果编码人员完全不关心它，那么关注模块化和抽象有时会产生与您完全相同的效果。 MISRA-C是一个很好的起点，因为这个标准是在真正的固件问题上发展和发展的。我在这里经常受到批评，因为我更喜欢函数中的一个返回点，因为它使代码清除并且对人类更具可读性，而没有或者很小的开销。 –
单从正对固件的另一端，它是否将有一个API，别人必须以确保你问他们，你把它写之前，他们需要的东西互动的亲身经历。 – Robinson
第一件事：收集要求！进行用例研究！找出需要的东西！然后根据您的信息进行分析。继续从分析中进行设计。然后继续制作测试用例。然后你实现这个设计，并确保它通过测试用例。根据需要迭代任何步骤或多个步骤。 –
感谢您的回答，您是否在工作中使用过基于UML的任何建模设计工具，或者固件没有必要？（比如企业架构师） –