我的问题可能看起来如此普遍，但我真的需要你的帮助。我是一名新手嵌入式软件工程师，我已经用TI DSC和带有C和C ++编程语言的STM微控制器完成了一些小项目。但现在我将开始为一个大项目编写固件，我正在寻找一种方法来模拟我的固件，然后再实现它。实际上我有两个问题：
1.我想知道专业嵌入式软件工程师在开始编写固件之前做了什么？（对于固件建模，使用的是合理的玫瑰或适用于固件的企业架构，我认为这两者适用于IT和软件应用程序而不是固件）
2.在编写固件时我必须遵守哪些重要规则？ 例如我考虑过：
a。永远不要将大量代码放入中断服务程序
湾永远不要忙着等待wile循环 我还应该考虑其他什么？
答案 0 :(得分：3)
这些问题在SO上是偏离主题的，但无论如何我都会回答，因为对于这些非常重要的考虑，实际上并没有任何论坛。通常它是这样的：
编写规范和要求。花一些时间来关注产品，而不是技术细节。 UML“用例”可以很方便，但常识也可以正常工作。确保规范是一份活文件，必要时可以修改。
然后使用OO模型进行程序设计（将其称为类/代码模块/翻译单元或您将使用的内容）。记下程序需要哪些代码模块，确保这些代码模块符合规范 - 理想情况下，每个需求都会导致特定代码（稍后会导致对该代码的特定测试）。然后关注不同模块之间的依赖关系：这应该是一个“从上到下”的依赖树，其中驱动程序不依赖于HAL，不依赖于调用者等等。用笔和纸画出这棵树。花哨的UML是好的但不是必需的。
您需要尽早考虑可移植性。代码应该在项目之间移植吗？ （很常见）编译器之间？ （相当常见）平台之间？根据所需的可移植性级别，您可以欺骗设计并跳过一些HAL。但是，将驱动程序与应用程序分开几乎总是一个好主意。
关于“重要规则”，这些与程序设计阶段无关。相反，这些应该在您的编码标准文档中。优选地，用于每个项目的公司标准。它应该专注于禁止各种不良做法，并且还包含风格指南。对于嵌入式系统，我强烈建议将此文档基于MISRA-C，然后根据需要添加自定义规则（例如“保持ISR代码最小”），然后在其上添加样式指南。请注意，编写此编码标准是一个独立的项目。