YTM32B1LE0 IIS
-
您好，可以按照以下的方式排查：
- SPI_DRV_MasterTransfer()的transferByteCount参数应该是整个音频数据包的长度
- 是否已经使用了DMA的方式
- 修改底层代码，减小帧间距，修改如下位置，将这个三个传入的参数值减小
-
您好这个现象是已经调整过这个了，已经启用的dma，这个sck的帧间隔是正常的，也是一整包数据发送。中间那个50微秒的间隔是发送第二包数据的间隔，是第二次一整包数据的间隔即while第二次循环，下面那个波形是tum进行反转我设置的是硬件触发，但是实际上似乎一整包数据传输完成后反应并没有那么及时 -
您好，把如下的值调小(SCK结束后到PCS拉高的时间配置)，因为TMU收到的是帧完成的trigger，PCS拉高才算一帧结束了
-
50us的时间间隔由以下主要的时间组成(建议把PCS的信号线引出观察PCS的高低才是决定一个帧的开始或者结束)
- SCK结束到PCS拉起的时间(这里主要会导致您贴的示波器途中SCK和TMU trigger之间的距离)，缩短方式SPI_CLK_SCKPCS(x)
- TMU trigger后产生后到下一帧开始的时间主要由：帧间隔时间(和代码执行时间相重合，哪个时间长是哪个)/代码执行时间+PCS拉低到SCK开始的时间(用SPI_CLK_PCSSCK(x)缩短时间)；
- 当然，调节以上方式都是在不影响一包数据中的帧间隔，即在一包数据的帧与帧之间的间隔时间(SCKPCS + FMDLY + PCSSCK)基本等于1bit时间才能保证不失真。
注意：请问下是否只有一包的最后一帧才会出现TMU由严重的延时
-
但是比较奇怪的是TMU的trigger时间有点延时过长了，如果这样的话，理论上LRCK会出现严重的偏移
-
示波器的channel2是LRCK？
-
这个不会，你可以看下在一包的数据里面的LRCLK是否会有偏移，最后一帧那个不是延时，只是在一包数据发送完后开始新的一包的初始化状态，SCLK那个时候没有启动，是没关系的。还有就是LRCLK不是TMU出来的，是eTMR出来的
-
可以将一包的数据和音频信号一起拉出来看下，是什么样的失真
-
是的，LRCLK只是判断是左右声道
-
完全对齐是不可能的，因为只有在SPI的帧结束了才会发送trigger到TMU，再路由到eTMR , 将SCKPCS(帧结束段，CLK结束到PCS拉高的时间)的时间等价到PCSSCK(PCS拉低到CLK开始的时间)或帧间隔的时间，看看这种方式有没有改善
-
目前推测耗时最多的是代码的执行时间，如果代码没开优化等级的话，可以开一下
11/31
发帖前请查看
帮助没办法联网的电脑使用YCT
帮助改进和优化YT CONFIG TOOL，有机会抽取YTM32B1ME0 EVB哦...