[参考译文] TMS570LC4357：HET HTU、用于慢速信号的第一个 PCNT (RISE2FALL)始终为零

该请求在 L00中未启用、因此 L01中的请求用于触发 L00 DF 和 L01 DF 的传输、对吗？ 在这个情况下、帧数量为2、在 HTU 控制数据包中 HET addr 增量为16字节。  

我对您的消息中的"准时"传输不是很清楚。  

您好、OJ：  

让我更清楚一点。  

哎呀、抱歉...

l00 PCNT｛hr_lr=low、next=L01、type=RIISE2FALL、pin=12｝；接通时间
L01 PCNT｛hr_lr=low、next=L02、reqnum=0、request=GENREQ、type=RIISE2RISE、pin=12｝；句点

我认为帧计数的说法是不正确的。 帧计数是缓冲区深度、元素数量应为2。 不管怎样、我的 HTU 设置看起来是正确的、它按照预期工作、除非我使用慢速信号(<= 10Hz)来馈送它。
HTU 被设置为双缓冲模式并在 bufA 和 bufB 之间自动切换。
我设置一个 HTU 中断断点、在 bufA 或 bufB 已满时触发。 当 bufA 满时、第一个中断被触发。 假设帧数为6、我预计缓冲区中会出现以下结果：

bufA   内容   
 0     导通时间周期1
 1.       周期1时的相位
 2     导通时间周期2
 3.       周期2
 4.     导通时间周期3
 5     周期  3
这对于更快的信号是合适的。 对于10Hz 及更低频率、我得到：
 bufA   内容   
 0          0
 1.       周期1时的相位
 2     导通时间周期2
 3.       周期2
 4.     导通时间周期3
 5     周期  3
这只是第一次触发中断、然后就没有问题了。 我不希望出现这种情况、因为 L00和 L01都从上升沿开始。 L00结束、下降沿结束、L01位于上升沿。 这就是为什么我希望 L00始终有效、而不是为零。 L01触发 HTU 传输。

此致、
Juergen

您好、QJ：

我不打算使用 L00来触发 HTU 传输、而是由 L01完成。 我的假设是, L00已经捕获了计数器到它提交的数据,因为它测量了 Rise2Fall 和 L01从 Rise2Rise。 L01触发一个 HTU 传输、在两个元件的帧中传输 L00和 L01的 Df。 为什么建议对第一次转账进行分立？ 我在文档的某处读取了类似的内容。 我认为必须关注 HET 和 HTU 是如何被启用的、以及 HTU 在并非由信号边沿引起的特殊情况下如何触发一个请求的序列。 我已经过测试、在启动时不会从 HTU 接收到不需要的传输。 如果我不明白为什么它的行为方式、我不想公开结果。

您好！

最好使用一个 HTU 请求来传输 L00 DF 和 L01 DF。

linhong yao 说：

为什么建议取消第一次转账？

L01使用 RISE2RISE、捕获周期计数器、并在上升沿复位。

请参阅 PCNT 指令描述部分中的注释：

注意：对于 FLL2FALL/RISE2RISE、如果、用户应始终丢弃第一个中断/HTU 请求
在 HET_ON 之前启用中断/请求。 对于这两种类型、复位边沿和捕捉边沿都是
相同、并且中断或 HTU 请求在捕获边沿(除了复位边沿)上触发。
一旦执行单元被启用、第一个边沿就会生成中断、但计数器的值为
不使用、因为这不是2个边沿之间的周期。 因此、N2HET 导通后的第一个边沿主要用于
复位计数器并开始周期计数。