您曾经必须创建有限状态机吗？
这不包括您可能在大学里做过的有限状态机。
我想知道谁必须创建一个以及为什么？
制造这台机器最困难的方面是什么？
This does not include a finite-state machine you might have done for college.
I want to know who has had to create one and why?
What was the most difficult aspect of creating the machine?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
是的，很多。 基本上，出于性能原因，我必须手动实现词法分析器。 其他个人用途包括 GUI 设计，其中 FSA 控制与用户的交互流程。
创建这样的机器一点也不困难。 更改它们是因为 FSA 的至少部分结构被严格嵌入代码中。 状态模式有助于缓解其中一些转换 - 但不是全部。
Yes, lots of them. Basically, I had to implement lexical analyzers manually for performance reasons. Other personal uses have been in GUI designs where the FSA has controlled the flow of interaction with the user.
Creating such machines is not difficult at all. Changing them is because at least part of the structure of the FSA is embedded rigidly in the code. The state pattern helps to ease some of these transitions – but not all of them.
多次！
通信系统中使用的大多数协议栈都是作为状态机实现的。 CSTA 调用模型就是一个很好的例子。
而且大多数嵌入式系统本质上都是状态机。
基本上，任何必须对现实世界中的事件做出反应的系统都是作为状态机实现的良好候选者。
关于状态机最困难的事情是在缺乏最新文档的情况下理解它们的作用。 他们倾向于将错误修复得面目全非。
Many times!
Most protocol stacks used in communications systems are implemented as state machines. The CSTA call model being one good example.
Also most embedded systems are essentially state machines.
Basically any system that has to react to events in the real world is a good candidate for implementation as a state machine.
The most difficult thing about state machines is understanding what they do in the absence of up to date documentation. They have a tendency to get bug fixed beyond recognition.
当然，我设计并制造了一个涡轮调速器来控制小型涡轮机、泵和电机。 它是一个带有DSP芯片的嵌入式设备。 它具有停止、启动、运行、超速测试等状态，并且运行状态中还有多种状态来涵盖其他控制可能性。
就我而言，状态机管理最困难的部分是设计一个干净的转换，特别是当状态可以有子状态时。 对于涡轮机调速器来说，这意味着必须在转换之间平滑地调整速度输出（执行器）。 其他挑战与用户界面（按钮和 7 段 LED 显示屏）以及它们如何与状态机交互有关。 因此最终形成了一个主控制状态机、一个相关的用户界面状态机和一个相关的通信状态机（在涡轮机运行时不允许写入某些值）。
我在各种其他项目中使用过状态机，包括一些嵌入式软件和一些标准软件，以及从通信到用户界面软件。
Sure, I designed and created a turbine governor to control small turbines, pumps, and motors. It is an embedded device with a DSP chip. It has states such as stopped, startup, running, overspeed-test and then there are several states within the running state to cover other control possibilities.
In my case, the hardest part about the state machine management was designing a clean transition, especially when states can have sub-states. For the turbine governor, this meant that the speed output (actuator) had to be adjusted smoothly between transitions. Other challenges were related to the user interface (push buttons and 7-segment LED display) and how they interacted with the state machine. So there ended up being a master control state machine, a related user-interface state machine, and a related communications state machine (it was not permissible to write certain values while the turbine was running).
I have used state machines in a variety of other projects, some embedded and some standard software, as well from communications to user interface software.
如上所述，FSA 的目的就是，从一步到一步，所有处理（和状态更改）都在一个循环中处理。 而且，当流程发生变化时，进入下一个逻辑步骤很容易。
是的，它们很容易做到，25 年来我经常使用它们。
As above, the purpose of an FSA is just that, going from step to step to step, all your processing (and state changes) are handled in one loop. And, when something changes in the process, getting to the next logical step is easy.
And yes, they're easy to do, I have used them frequently over 25 years.
我也有。 我通常创建小型 FSM（状态很少），因为较大的 FSM 会成为维护噩梦，但有时对于给定任务，FSM 是一种非常简单而优雅的设计。
作为一个真实的例子，我创建了一个小实用程序来修复某种类型的文件一次。 与用户只有 3 或 4 种可能的交互路径：
创建状态机使这些路径变得明显且易于实现。
I have too. I usually create small FSMs (with few states) because bigger ones become maintenance nightmares, but sometimes an FSM is a very simple and elegant design for a given task.
As a real-world example, I created a little utility to repair a certain type of file once. There were only 3 or 4 possible interaction paths with the user:
Creating the state machine made those paths apparent and easy to implement.