我偶然发现了一个 free state machine tool .这似乎用于以图形方式对嵌入式系统进行编程。通过这样做，作者声称生成的代码比使用 RTOS 时更易于维护。该工具基于 UML，这很高兴知道，但学习曲线陡峭。
我想知道这里一些更有经验的程序员如何看待这个工具。
我正在为 LM3S5P36 开发嵌入式应用程序微 Controller 。 TI 有一个名为 Code Composer Studio (CCS) 的 IDE。我还没有进入 CCS，但我怀疑它是否具有将所需行为输入状态机图表、转动曲柄并弹出 C 或 C++ 代码的酷炫功能。然后返回编辑图表以生成相应的修改代码。我用 C 编写了微 Controller ，但对 UML 几乎一无所知。过去我维护了两个文件，一个是微 Controller 代码，另一个是流程图。每个代码修订意味着维护两个单独的文件。
所以我的困境是:发现了这个很酷的从图表到代码的一体化文档工具，我很想使用它，但更重要的是，我只想完成我的项目。我是按照旧的方式来做，还是花几周时间学习 UML？
最佳答案
您可能还对 Miro Samek 的书“Practical UML Statecharts in C/C++”感兴趣。请注意，Miro 是 Quantum Leaps 的创始人兼总裁，因此本书与该工具密切相关。
与 RTOS 开发相比，Miro 似乎在状态图开发方面投入了大量资金，撰写了大量关于该主题的书和博客。他在 LinkedIn 的实时嵌入式工程小组中发起了题为“Is an RTOS really the best way to design embedded systems?”的主题——关于该主题的大量意见!
我不确定这两者是否一定是不同的。将单个 RTOS 线程实现为状态机通常很有用(并且经常这样做)。他在他的博客“I Hate RTOSes”中提出了一些很好的观点，但他的推理主要是基于糟糕的应用程序设计而不是 RTOS 技术本身。正如 C 或 C++ 在不明智的情况下使用时可能会很危险一样，RTOS 也是如此。我是什么通常看到的应用程序的线程太少，内聚力差且耦合度低，但我相信 Miro 会因为想到解决方案是更多线程而感到沮丧!
UML 2.2 指定了 14 种图，状态机只是其中一种，因此无需完整学习 UML。在这种情况下使用它是因为它是一个定义明确的模型，具有清晰的语法和语义，适用于定义行为细节。状态机图(或状态图)可能是最容易理解的 UML 行为图，并且在任何 UML 图中具有最明确的定义语义。
关于uml - 状态机与微 Controller 的 RTOS，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7116881/