YTM32B1LE0 IIS

[sunxuehu]

您好，把如下的值调小(SCK结束后到PCS拉高的时间配置)，因为TMU收到的是帧完成的trigger，PCS拉高才算一帧结束了

[sfuyuan]

sunxuehu 波形是已经调整过的，现在的情况是失真比较严重，应该是信号没有对齐，波形上中间的一段低电平不是发送中产生的，是我一整包数据发送完在发送第二包的时候有一段间隔，已经启用的dma，另外结束tmu的触发也是设置的硬件触发，跟spi的也对不上

[sfuyuan]

sunxuehu 我要把3个都配置为0吗 配置为0后，每一个字节的数据的会这样，每一整包的数据50ms依旧存在，这样配置似乎sck的整体频率就不对了

[sfuyuan]

sunxuehu 您好，没啥效果，你们有没有用这个芯片模拟的实例测试下看看，我目前的就是加上那个19的延时，可以驱动音频芯片，但是失真严重，如果把延时去掉，就会跟图片的一样频率都不对了，音频芯片完全驱动不了。

[sunxuehu]

50us的时间间隔由以下主要的时间组成(建议把PCS的信号线引出观察PCS的高低才是决定一个帧的开始或者结束)

1. SCK结束到PCS拉起的时间(这里主要会导致您贴的示波器途中SCK和TMU trigger之间的距离)，缩短方式SPI_CLK_SCKPCS(x)
2. TMU trigger后产生后到下一帧开始的时间主要由：帧间隔时间(和代码执行时间相重合，哪个时间长是哪个)/代码执行时间+PCS拉低到SCK开始的时间(用SPI_CLK_PCSSCK(x)缩短时间)；
3. 当然，调节以上方式都是在不影响一包数据中的帧间隔，即在一包数据的帧与帧之间的间隔时间(SCKPCS + FMDLY + PCSSCK)基本等于1bit时间才能保证不失真。
   注意：请问下是否只有一包的最后一帧才会出现TMU由严重的延时

[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]

此主題已被删除！