我现在正和一位同事就架构问题争论不休。我希望你们中的一些人可以通过强烈建议一种方法而不是另一种方法来帮助解决这个问题。
我们将 DSP 和 Cortex-M3 耦合在一起,并共享内存。 DSP 接收来自外部世界的请求,其中一些请求用于执行某些只能在 CM3 上完成的无线测试功能。 DSP 写入共享内存,然后通过中断向 CM3 发送信号。共享内存指示请求是什么以及执行请求所需的任何必要数据(要调谐到的 channel 、要读取的 RF 芯片的寄存器等)。
我的偏好是为可能发生在中断中的每个请求生成一个唯一的事件 ID。然后在离开中断之前将事件传递到状态机的事件队列,该队列将在专用于 RF 事件的线程中处理。
我的同事希望将单个事件 ID(通用 RF 命令)传递给状态机,并在状态机中接收到该事件 ID 后解析共享内存区域。解析后,您将知道需要执行的具体命令。
我不喜欢这种方法,因为无论您碰巧处于什么状态,您都将对共享内存进行解析。您可以将其设为一个函数,但它仍在处理应该与状态无关的内容。她不喜欢在中断中解析共享内存的想法。
对更好的方法有何评论?如果有帮助,我们将使用 Miro Samek 的 QP 框架来实现状态机。
最佳答案
这是一个妥协:
- 将单个事件 ID(通用 RF 命令)从中断传递到状态机
- 创建一个“解析”共享内存并返回特定命令的 action_function
- 使用
[parser_action_func() == RF_CMD_1]
等在状态图中保护 RF_EVENT 转换
状态图代码生成器应该足够智能,每个 RF_EVENT 只执行一次 parser_action_func()
。 (不知道 QP 框架是否那么智能)。
这与“每个请求的唯一事件 ID”具有相同的状态图语义,并避免在中断处理程序中解析共享内存。
附录
状态图中的区别在于标记了 N 个转换
----RF_EVT_CMD_1---->
----RF_EVT_CMD_2---->
...
----RF_EVT_CMD_N---->
对
----RF_EVT[cmd()==CMD_1]---->
----RF_EVT[cmd()==CMD_2]---->
...
----RF_EVT[cmd()==CMD_N]---->
其中cmd()
是解析 Action 函数。
关于c - 多处理器架构中的状态机事件生成,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15820308/