YTM32B1LE0 IIS

[sunxuehu]

但是比较奇怪的是TMU的trigger时间有点延时过长了，如果这样的话，理论上LRCK会出现严重的偏移

[sunxuehu]

示波器的channel2是LRCK？

[sfuyuan]

sunxuehu 硬件上没有配置PCS的线，就三根线，即SCK,DAT,和tum。 是的示波器的2是LRCLK,1是sck，因为产生严重的失真，猜测就是一个是LRCLK和sck的响应偏移太大，另外就是每一包数据间隔太长导致不停偏移

[sunxuehu]

这个不会，你可以看下在一包的数据里面的LRCLK是否会有偏移，最后一帧那个不是延时，只是在一包数据发送完后开始新的一包的初始化状态，SCLK那个时候没有启动，是没关系的。还有就是LRCLK不是TMU出来的，是eTMR出来的

[sunxuehu]

可以将一包的数据和音频信号一起拉出来看下，是什么样的失真

[sfuyuan]

sunxuehu 意思是这个没有影响？只要下一包的LRCLK根sck没有偏移就可以？我

[sunxuehu]

是的，LRCLK只是判断是左右声道

[sfuyuan]

sunxuehu 但是现在我的LRCLK和BCLK上下边沿完全没办法对其，我应该怎么调整，数据是通过spi发送的跟spi的时钟是对齐的

[sunxuehu]

完全对齐是不可能的，因为只有在SPI的帧结束了才会发送trigger到TMU，再路由到eTMR , 将SCKPCS(帧结束段，CLK结束到PCS拉高的时间)的时间等价到PCSSCK(PCS拉低到CLK开始的时间)或帧间隔的时间，看看这种方式有没有改善

[sfuyuan]

sunxuehu 另外就是有没有办法缩短那个50微秒的间距，就是每一整包数据的间隔，波形的数据本身就比较短，是靠循环发送同一个波形去执行的，现在每个正弦波的数据中间隔了50微秒，这个我要如何解决，程序里只有一个while在一直循环发送数据

[sunxuehu]

目前推测耗时最多的是代码的执行时间，如果代码没开优化等级的话，可以开一下

[sfuyuan]

sunxuehu 这个是SCK跟LR在每次发完的波形， 这个是sck跟dat每次发送完的波形这个看着是正常的， 这个是sck跟dat的波形对其情况，看着也是正常的， 这个是SCK跟lr的对其情况，差个几十纳秒把，应该也能算正常。

[sfuyuan]

@sunxuehu测试过开更高级的优化了，开了程序就没反应了，目前程序啥也没有执行，就是循环执行发送函数优化等级为2的话就是50u秒

[sunxuehu]

您好，可以排查以下内容：

1. 是否在IIS callback函数里面执行长时间的函数或者在其他中断占用了时间
2. 可以用PIN脚翻转测量下实际代码的运行的时间，比如I2S_DRV_MasterSend()进入到出去的时间

[sfuyuan]

此回复已被删除！

[sfuyuan]

sunxuehu 回调函数是空函数，用io测试， 这个函数的执行时间是10微秒

[sfuyuan]

sunxuehu 这个函数执行时间是40微秒I2S_DRV_MasterSend

[sunxuehu]

实际代码需要这些时间重新发送一包数据，这个应该不会影响音频的失真吧

[sfuyuan]

sunxuehu 目前的情况确实是有点问题，主要原因是我们不需要输出声音，就是单纯的一个正弦波，来驱动振子一个数组的话就几百个字节，中间穿插了50微秒就会导致信号频率都变掉了，一次性发送10个正弦波，似乎就会失真，即发得少没办法识别发的多又会失真。目前是执行这个发送函数是需要这么长的时间没办法消除对吗？

[sunxuehu]

把10个正弦波的数据打包一次性发完不行么，时间长的问题可以改善，但是根除不了