我有一个周期性输入信号、并且希望在输入信号之后生成一个90度的上升沿。 我想使用 TMRxA 捕获输入进行时间读数(从此处计算出的周期和相位)、这样做很好。
但是、我找不到一种使用 TMRxB 来生成输出上升沿的方法... 我可以同步启动 A 和 B、但比较操作仅在超时发生、因此我需要中断同步以使其正常工作... 更糟糕的是、在 ISR 上开始比较会增加无法预测的延迟。
换而言之、我想生成一个上升沿延迟的输出信号、与输入信号的上升沿完全延迟 N 个时钟周期。
有什么想法吗?
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.
我有一个周期性输入信号、并且希望在输入信号之后生成一个90度的上升沿。 我想使用 TMRxA 捕获输入进行时间读数(从此处计算出的周期和相位)、这样做很好。
但是、我找不到一种使用 TMRxB 来生成输出上升沿的方法... 我可以同步启动 A 和 B、但比较操作仅在超时发生、因此我需要中断同步以使其正常工作... 更糟糕的是、在 ISR 上开始比较会增加无法预测的延迟。
换而言之、我想生成一个上升沿延迟的输出信号、与输入信号的上升沿完全延迟 N 个时钟周期。
有什么想法吗?
我同意海报"Millwood 的" 建议- 选择"单脉冲"(在这里称为"单脉冲")是正确的。
话虽如此-您的评论、
[引用 USER="Lucas Hartmann"]更糟糕的是,开始比较 ISR 会增加不可预测的延迟。
可能不是" 精心挑选!" 您是否建议 ARM、Cortex"M"系列 MCU 证明"不是确定性的"- 尤其是在它们对中断的响应中? 这是 ARM 设计团队的核心意图之一、值得注意。 (并且很容易确认) 您从何处得出这样的结论?
在"中断触发器"和"进入 ISR"之间经过12个系统时钟-前提是遵守(适用)设计指南。 这些准则可包括:
这是"不是那么不可预测"吗? 您并非只有这样的思维、而 ARM MCU 的非凡成功和广泛采用却使他们"错过" 了这些关键特性... 不太可能! (这)完全 是"可预测的..."
因此、只要您在汇编语言中执行 ISR 代码、对所有可能分支的周期进行计数、并且在较低优先级代码上不使用关键段(禁用中断)、就可以预测。 我不是完全确定 FreeRTOS 如何管理信令,所以我必须假设是最差的(我不是为此而责怪 ARM;-)。
无论如何、我都找不到如何使用外部触发输入。 所有 TIvaware 用户指南提到的都是使用一个计时器的超时作为下一个计时器的触发器。
也许我可以使用周期为1的捕获计数计时器来触发下一个计时器。 占用一个额外的计时器、但应该起作用。
[引用 USER="Lucas Hartmann"]因此只要在汇编语言中执行 ISR 代码,它就可以预测[/引用]
再次-我相信您的信念是"错误的!" ARM 的一个关键目标是确保 ISR 可以完全用 C 编码!
您不必"计数周期"-如果您的关键中断被提升为 "抢先式"、则其进入其服务例程将证明(高度)可预测。 我先前提到过、 "所有较小的中断都将(暂时)停止、以便 "挤占"立即接收服务、 这可能没有被正确吸收。 您不必"禁用中断!"
ARM MCU 是比嵌入式产品更早的 MCU "数量级"。 当您有空闲时间时-您访问 ARM (非常大)网站-将展示一个"宝藏"的文档-确保(更好)告知您的意见。 为了保护这家供应商-他们的 MCU 手册(已经超过1K 页)-很难证明他们(改进的)促销和 ARM 提供的独特优势的描述是合理的。
您-现在-介绍"FreeRTOS " (BTW -您/其他人应该知道- FreeRTOS 已获得 MIT 和 Amazon Services 的许可-非常令人印象深刻。 (当然、还可容纳更多的 "一个且只有一个"供应商的 MCU。 (错了(你能说限制)... 这样...) 我会在早期避免使用(任何) RTOS -更"复杂"不会加快或减轻您的目标...
我们应该注意到、您使用 "多个计时器"而不是"一个"、这是有灵感的、并且很可能 会"加快、简化和增强"您的代码开发。 朋友 Robert Here (et Moi)指出的"过早优化"通常会导致"有缺陷和延迟"的开发。 (最好是"完成您的项目-仅(然后)探查、看看"您以外的任何人 真的关心 (始终)延迟"优化!") (提示: 超过90%的时间-他们没有!)
"逐项改进"----长期以来一直是一个词(对被禁止的"亲吻"的另一个描述----建议其支持者 "在 小、独特、可衡量、系统的区块中完成任务----特别是避免任何/所有"优化"的尝试----直至(稍后)。 (如果有!)
您是否可以更好地(并进一步)描述您在"如何使用外部触发器"方面遇到的困难? 有多个触发器-和多个可被触发的功能。 需要更好的规格...
您的限制-由 RTOS 引入-是 RTOS 的(几个)缺点之一-我认为(过于频繁)应该加以掩盖。 (仅接受"希望获得的福利"。)
我非常确信、这里的编程人员(我的小公司-在我之外)可以实现您的目标-然而、"RTOS 入侵"使我们处于(可能)难以维持的位置。
但是、供应商员工 是熟练的、训练有素的、"连接"(与内部信息)-他们应该能够(进一步)指导您。 (虽然 RTOS (可能)会使其工作复杂化并延迟...)