微控制器的状态机与 RTOS
我偶然发现了一个免费状态机工具。这似乎是为了以图形方式对嵌入式系统进行编程。作者声称，通过这样做，生成的代码比使用 RTOS 更易于维护。该工具基于 UML，虽然很容易了解，但学习曲线很陡。
我想知道这里一些更有经验的程序员如何看待这个工具。
我正在为 LM3S5P36 微控制器开发嵌入式应用程序。 TI 有一个名为 Code Composer Studio (CCS) 的 IDE。我还没有接触 CCS，但我怀疑它是否具有能够将所需行为输入状态机图表、转动曲柄并弹出 C 或 C++ 代码的酷功能。然后返回并编辑图表以生成相应的修改代码。我用 C 语言编写过微控制器，但对 UML 几乎一无所知。过去我维护了两个文件，其中一个是微控制器代码，另一个是流程图。每个代码修订都意味着维护两个单独的文件。
所以我的困境是：在发现了这个很酷的图表到代码、包含文档的一体化工具后，我很想使用它，但更重要的是，我只想完成我的项目。我是用老方法做，还是花几周时间学习 UML？
I stumbled across a free state machine tool. This appears to be for programming embedded systems graphically. By doing so, the author claims that the resulting code is more maintainable than if an RTOS had been employed. This tool is based on UML, which is nice to know, but has a steep learning curve.
I would like to know what some of the more experienced programmers here think of this tool.
I am developing an embedded application for the LM3S5P36 microcontroller. TI has an IDE called Code Composer Studio (CCS). I have not got into CCS yet, but I doubt it has the cool feature of being able to enter the desired behavior into a state machine chart, turn the crank, and pop out C or C++ code. Then go back and edit the chart to generate corresponding revised code. I have programmed microcontrollers in C, but know almost nothing about UML. In the past I have maintained two files, one of them microcontroller code and the other a flow chart. Each code revision meant maintaining two separate files.
So my dilemma is: having discovered this cool chart-to-code all-in-one-documentation-included tool, I would love to use it, but, more than that, I just want to get my project done. Do I do it the old way, or spend a few weeks learning UML?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可能还对 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 图中定义最清晰的语义。
You may also be interested in Miro Samek's book "Practical UML Statecharts in C/C++". Note that Miro is founder and president of Quantum Leaps, so this book goes hand-in-hand with the tool.
It seems that Miro has a lot invested in state-chart development over RTOS development, having written the book and blogged on the subject extensively. He started the thread on LinkedIn's Real-Time Embedded Engineering group titled "Is an RTOS really the best way to design embedded systems?" - plenty of opinions on the subject there!.
I am not sure that the two are necessarily distinct; it is often useful (and frequently done) to implement individual RTOS threads as state-machines. He makes some good points in his blog "I Hate RTOSes, but his reasoning is largely based around poor application design than RTOS technology itself. Just as C or C++ can be dangerous when used ill-advisedly, so to can an RTOS. What I typically see is applications with too few threads with poor cohesion and tight coupling, but I am sure that Miro will be tearing his hair out at the thought that the solution is more threads!
UML 2.2 specified 14 types of diagram, state-machine being just one, so there is no need to learn UML in its entirety. It is used in this case because it is a well defined model with clear syntax and semantics, suitable for defining behavioural detail. State-machine diagrams (or state-charts) are probably the easiest UML behavioural diagrams to understand, and have the most clearly defined semantics of any UML diagram.
我没有尝试该工具，但如果您获得 UML 图，那么它对于您的项目文档来说总是更好。现在使用类图从 UML 生成代码非常好，我想其他图也可以是一样的。
I did not try the tool but if you get UML diagrams then it is always better for your project documentation. Code generation from UML is now pretty good using Class diagrams and I suppose it could be the same for the other diagrams.
http://www.StateSoft.org 上提供了一种可能满足您需求的方法
它使用非常小但功能完整的 UML 子集 - 如果您查看状态机库中的图形 API 集，您将在几分钟内直观地了解所需的 UML SM 符号子集。为了提高嵌入式系统内存使用效率，生成了高度优化的表。根据您使用 C 还是 C++，您可以选择紧凑表执行器。
One approach which may satisfy your needs is presented on http://www.StateSoft.org
It uses very small but functionally complete subset of UML – if you look at the set of graphical API’s at State Machine Gallery, you will learn needed subset of UML SM notation intuitively in matter of minutes. For the efficiency of embedded system memory usage highly optimized table is produces. Depending if you use C or C++, you choose compact table executer.