• 状态 Resolved
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 238 视图
  • 用户 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/CC3220MODA：硬件计时器延迟

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/800115/rtos-cc3220moda-delay-with-hw-timer

器件型号：CC3220MODA

工具/软件：TI-RTOS

您好、社区

从论坛上的内容可以看到、实现精确延迟的建议解决方案似乎是使用硬件计时器。

我们需要延迟几个周期、因此我们打算在10us 上设置一个计时器、并使用一个中断例程来递增变量。  

Timer_Params_init (&params)；
params.periodUnits = Timer_Period_US；
params.period = 10；
params.timerMode = Timer_Continuous_callback；
params.timerCallback = timer0Callback； 
空 timer0Callback (Timer_handle)｛
++m10MicroSeconds；
｝

1.是否有更好的方法来实现这一点？  

2.是否存在每10us 触发一次计时器中断来使我们的应用程序垃圾邮件的风险？

提前感谢！

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

    您能否进一步解释一下您要实现的目标以及为何需要精确的10uS 延迟？ 根据您的目标、是的、可能有更好的解决方案。

    是的、每10uS 触发一次中断、很有可能没有其他东西会运行。 特别是因为它是一个硬件中断、因为它们具有更高的优先级。

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

    我们有一个 spi2uart (SC16IS752)芯片、用于将数据传输到多个 UART。 当它们的内部缓冲器已满时、我们需要等待(非常短的时间)、然后启动下一个传输。
    其他芯片在 POR 之后需要特定的时序。
    嗯、即使延迟更大(1ms)、也需要更高的测量频率。

    我们非常欢迎您的建议。
  • 0
    TI__Guru**** 2387830 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Vincent：

    查看该 spi2uart 芯片的数据表、可以看到它可以在满足特定条件时向 CC3220提供 GPIO 中断。 其中一个是 FIFO 水平达到可编程设置时。 或许一种解决问题的更好方法是、一旦 spi2uart 芯片发出信号、表明它已准备好接收更多数据、就让您的 SPI 写入函数在 GPIO 中断将发布到的信标上挂起。 这种方法对您的系统来说不是有效的原因吗？

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

    好的... 我知道你会这么说。
    原因是项目开始时没有 RTOS。 由于该特定的 spi2uart 芯片、因此必须对其进行更改。
    那么、从现在开始、你是对的。 在这种情况下、我们可以使用它们的"TX empty"中断。
    对于使用短延迟的其他情况、我们可以使用更大的延迟。
    因此，我们决定将计时器周期从10us 增加到100us。
    这必须是好的。 你怎么看？
    感谢您的意见！
  • 0
    TI__Guru**** 2387830 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Vincent：

    我认为最好使用"TX empty"中断。 每100us 触发一次的计时器中断可能会有点太频繁、但如果数据传输仅针对短时脉冲、而这可能不会对您的应用产生太大的影响、因为该计时器仅在数据传输期间处于活动状态。

    请告诉我您是否需要进一步澄清或对该主题有进一步的问题。

    此致、
    Michael
  • 0
    TI__Guru**** 2387830 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Michael、
    是的、我也是、这就是我们要做的事情。
    我们仍在使用计时器中断来生成精确的毫秒计数器。 实际上、我们还有许多其他时间关键型任务、我们无法为每个任务都执行 FreeRTOS 任务。 因此、我们在状态机中读取毫秒计数器的值、用于状态转换、延迟等。
    计时器始终运行。
    我还研究了 POSIX clock_gettime()函数，但它使用的_clock_gettimeMono()禁用所有中断，这似乎是一个巨大的开销，因为我们状态机中的某些状态将在每次运行时调用此函数，直到经过一段特定的时间(最多几秒钟)。 因此、让变量值由计时器递增的选项似乎是一个更好的选项。
    但同样、我愿意提供更好的建议。
    谢谢！
  • 0
    TI__Guru**** 2387830 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    尊敬的 Vincent：

    考虑到您提到的所有限制、使用该计时器可能对您的系统最有效。 尝试在代码中使用它、看看它是否会导致可接受的行为。 如果您在使用计时器时遇到问题、请随时告诉我。

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

    感谢您抽出宝贵的时间和考虑因素。