• 状态 Resolved
  • 已锁定 已锁定
  • 回复 6 回复
  • 订户 0 订户
  • 视图 342 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] RTOS/TM4C123GH6PM：事件的隐式布置

admin
Guru**** 2445440 points


请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/630637/rtos-tm4c123gh6pm-implicit-posting-for-the-events

器件型号：TM4C123GH6PM

工具/软件：TI-RTOS

您好！

我的平台是：

EK-TM4C123

- tirtos_tivac_2_16_01_14

- xdctools_3_32_00_06_core

-运行 TI 示例 EVENT_EK_TM4C123GXL_TI

我注意到样本中的显式过帐不会导致事件排队、而隐式过帐会导致事件排队？

我将描述挂起/发布方面的行为

如果 两次调用 Event_post 来布置 Event_ID_00、那么我只执行了一 个 Event_pend、事件屏蔽将被清除(事件没有队列)

如果 调用了邮箱_post 两次、它将隐式布置"Event_ID_02"、然后我对 Event_pend 执行了挂起、它将消耗 Event_ID_02 、然后在 Mailbox_pend 一次、我可以在 ROV 中看到 Event_ID_02再次出现、而没有任何显式/隐式过帐。 因此，隐式事件发布似乎与邮件箱一起排队，这是正确的行为吗？

谢谢、

Mohammed Fawzy

  • 0
    TI__Guru**** 2445440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Mohammed、
    邮箱是实际的容器，您需要指定消息数和每条消息的大小，如 Mailbox_construct()中所示，其中指定了2条消息。 如果两次调用 writertask、则它会将两条消息传递到邮箱、读取器任务将使用这些消息、直到邮箱为空。

    我将请我们的 TI-RTOS 专家提供其他意见。
  • 0
    TI__Guru**** 2445440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Charles、

    感谢你的答复。 但我知道邮箱是如何工作的、我对此没有任何问题。 我的问题是我前面所说的隐含事件。

    简单地说，邮箱上的第一个待处理将导致发布(非常奇怪！！！) 事件标志 Event_ID_02、您可以使用 TI 样片轻松进行验证。

    谢谢、此致、
    Mohammed Fawzy

  • 0
    TI__Guru**** 2445440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Mohammed、
    我不是 TI-RTOS 方面的专家。 但这是我可以根据示例得出的结果。 在写入任务中、您尝试写入3条消息、但邮箱仅配置为两条消息。 因此、如果邮箱已满、writetask 将阻止/挂起、等待读取器任务读取消息。 writertask 将隐式布置 EVENT_ID_02。 根据 Event_ID_00 + Event_ID_01的和掩码以及 Event_ID_02的或掩码、对读取器任务进行了挂起。 在发布 EVENT_id_02时、它将首先使用前两条消息。 Mailbox_pend 获取消息、直到邮箱变为空、并再次变为挂起、等待放置新消息。

    因此、从某种意义上讲、邮箱就像一个队列、三个消息/事件在队列中排队。 在这三条消息从写入器任务发送到读取器任务之后、写入器任务不再生成事件。 读取器任务只能基于 Event_ID_00 + Event_ID_01取消挂起。 由于这两个事件是从时钟模块发出的、具有不同的超时值、并且只有当这两个事件都有效时、才能取消读取器任务的挂起。

    我们的 RTOS 专家可以提供其他意见。
  • 0
    TI__Guru**** 2445440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Mohammed、

    我修改了事件示例、使写入任务的优先级高于读取任务。 我还将写入任务更改为只执行两个 Mailbox_post 调用(然后退出任务)。 读取器任务已运行、且 Event_pend 返回、且传递的值指示邮箱消息已就绪(Event_ID_02)。 当我在 ROV 中查看时，Event->postedEvents 为零(在 Event_pend 调用之前为4)。 现在来看看我们没有很好地记录的棘手的部分。。。
    当读取器任务调用 Mailbox_pend 时、它将获得消息、但它也将 postedEvents 重置回4 (这可以在 ROV 中看到)。 逻辑是内核知道那里还有另外一条消息(因为内部信标计数不为零)。 因此、该事件将重新发布、而不是强制您调用 Mailbox_pend 直到失败、因此您可以再次调用 Event_pend 并使其再次返回4 (这允许您获取下一个邮箱消息)。

    这是不是清除了(还是使它变得更混乱)？ 我将打开一个文档增强请求、以便我们可以在用户指南或 API 参考中对此进行解释。

    Todd

  • 0
    TI__Guru**** 2445440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Todd、

    感谢您的回复、我知道了您的观点、但从我的角度来看、RTOS 的行为在隐式过帐和显式过帐之间是不一致的、这样100个显式事件过帐可以在一个事件等待时使用 (当然、如果在100个帖子之前没有待处理帖子)、而100个隐式帖子需要100个待处理帖子。

    无论如何，目前我了解它是如何工作的，但我担心的是行为不一致，在某些情况下可以被视为一个错误。

    穆罕默德

  • 0
    TI__Guru**** 2445440 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您可以使用一个 Event_pend 使用所有邮箱消息。 例如、以下伪代码是可以的

    EVENT_PEND ()
    执行｛
    RC = Mailbox_pend (&msg、NOTIMEOUT)；
    //进程消息
    } while (rc == true)