我偶然发现了一个免费的状态机工具。这似乎是用于以图形方式对嵌入式系统进行编程。通过这样做，作者声称生成的代码比使用 RTOS 时更易于维护。这个工具是基于 UML 的，很高兴知道，但是学习曲线很陡峭。
我想知道这里一些更有经验的程序员对这个工具的看法。
我正在为LM3S5P36微控制器开发嵌入式应用程序。TI 有一个名为 Code Composer Studio (CCS) 的 IDE。我还没有进入 CCS，但我怀疑它是否具有能够将所需行为输入状态机图表、转动曲柄并弹出 C 或 C++ 代码的酷特性。然后回去编辑图表，生成相应的修改代码。我用 C 编写了微控制器，但对 UML 几乎一无所知。过去我维护了两个文件，一个是微控制器代码，另一个是流程图。每个代码修订都意味着维护两个单独的文件。
所以我的困境是：发现了这个很酷的图表到代码的多合一文档工具后，我很想使用它，但更重要的是，我只想完成我的项目。我是按旧方法做，还是花几周时间学习 UML？
您可能还对 Miro Samek 的书“ C/C++ 中的实用 UML 状态图”感兴趣。请注意，Miro 是 Quantum Leaps 的创始人兼总裁，因此本书与该工具密切相关。
与 RTOS 开发相比，Miro 似乎在状态图开发方面投入了大量资金，他就该主题撰写了这本书并发表了大量博客。他在 LinkedIn 的实时嵌入式工程组上发起了题为“ RTOS 真的是设计嵌入式系统的最佳方式吗？ ”的主题 - 那里有很多关于这个主题的意见！
我不确定这两者是否一定是不同的。将单个 RTOS 线程实现为状态机通常很有用（并且经常这样做）。他在他的博客“我讨厌 RTOS ”中提出了一些好的观点，但他的推理主要是基于糟糕的应用程序设计而不是 RTOS 技术本身。就像 C 或 C++ 在不明智的情况下使用会很危险一样，RTOS 也是如此。通常会看到线程太少、内聚力差且耦合紧密的应用程序，但我相信 Miro 会因为解决方案是更多线程而撕毁他的头发！
UML 2.2 规定了 14 种图，状态机只是其中一种，所以没有必要学习完整的 UML。在这种情况下使用它是因为它是一个定义明确的模型，具有清晰的语法和语义，适用于定义行为细节。状态机图（或状态图）可能是最容易理解的 UML 行为图，并且具有任何 UML 图的最清晰定义的语义。
http://www.StateSoft.org上介绍了一种可能满足您需求的方法。 它使用非常小但功能完整的 UML 子集——如果您查看 State Machine Gallery 中的图形 API 集，您将了解所需的 UML 子集在几分钟内直观地显示 UML SM 符号。针对嵌入式系统内存使用的效率，生成了高度优化的表格。根据您使用 C 还是 C++，您可以选择紧凑型表执行器。
我没有尝试使用该工具，但如果您获得 UML 图，那么它对您的项目文档总是更好。现在使用类图从 UML 生成代码非常好，我想其他图也可以这样。