Closed. This question needs to be more focused. It is not currently accepting answers. Learn more。
想改进这个问题吗？更新问题，使其只关注一个问题editing this post。
两年前关闭。
我的问题可能看起来很一般，但我真的需要你的帮助。我是一个新手嵌入式软件工程师，我已经做了一些小项目与TI DSC和STM微控制器与C和C++编程语言。但现在我要开始为一个大项目编写固件，我正在寻找一种方法，在实现之前对固件进行建模。实际上，我有两个问题：
1.在开始编写固件之前，我想知道专业的嵌入式软件工程师是做什么的？（对于固件的建模，是从rational rose或者企业架构中使用的，适合固件，我认为这两个，适合IT和软件应用程序，而不是固件）
2.在编写固件时，我必须遵守哪些重要规则？
例如，我考虑过：
永远不要在中断服务程序中输入太多代码
b.不要忙着等待
我还应该考虑什么？
想改进这个问题吗？更新问题，使其只关注一个问题editing this post。
两年前关闭。
我的问题可能看起来很一般，但我真的需要你的帮助。我是一个新手嵌入式软件工程师，我已经做了一些小项目与TI DSC和STM微控制器与C和C++编程语言。但现在我要开始为一个大项目编写固件，我正在寻找一种方法，在实现之前对固件进行建模。实际上，我有两个问题：
1.在开始编写固件之前，我想知道专业的嵌入式软件工程师是做什么的？（对于固件的建模，是从rational rose或者企业架构中使用的，适合固件，我认为这两个，适合IT和软件应用程序，而不是固件）
2.在编写固件时，我必须遵守哪些重要规则？
例如，我考虑过：
永远不要在中断服务程序中输入太多代码
b.不要忙着等待
我还应该考虑什么？
最佳答案
这类问题不是话题，但我无论如何都会回答，因为没有真正的论坛来讨论这些非常重要的问题。通常是这样的：
编写规范和要求。在这方面花点时间，专注于产品，而不是技术细节。UML“用例”可以很方便，但常识也同样适用。确保规范是一个活的文件，必要时可以修改。
然后用一个面向对象模型（称之为类/代码模块/翻译单元或你想要的东西）进行程序设计。写下程序需要的代码模块，确保这些模块符合规范-理想情况下，每个需求都会导致特定的代码（稍后会导致对该代码的特定测试）。然后关注不同模块之间的依赖关系：这应该是一个“自上而下”的依赖树，其中驱动程序不依赖HALs，也不依赖调用方等等。用笔和纸画这棵树。花哨的UML是可以的，但不是必需的。
您需要尽早考虑可移植性。代码应该在项目之间移植吗？（非常常见）在编译器之间？（相当普遍）在平台之间？根据所需的可移植性级别，您可以欺骗设计并跳过一些HALs。不过，将驱动程序与应用程序分离几乎总是一个好主意。
关于“重要规则”，这些与程序设计阶段无关。相反，这些应该在您的编码标准文档中。最好是用于每个项目的公司标准。它应该着重于禁止各种不良行为，此外还包含一个风格指南。对于嵌入式系统，我强烈建议将本文档基于MISRA-C，然后添加自定义规则（如“保持ISR代码最小化”），然后在此基础上添加样式指南。请注意，编写这个编码标准是它自己的一个项目。
10-06 00:58