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.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/634482/compiler-difficult-question-functions-called-from-dma-interrupt-routine
工具/软件：TI C/C++编译器
您好！
我注意到一个奇怪的问题：
如果我从 DMA_ISR 函数调用、程序运行缓慢。
为什么？
我知道答案并不简单、但我很好奇、我想准确了解 C5505的功能。
非常感谢您的参与
Paolo
尊敬的 M MAR：
我同意你的看法、我应该更具体一些。 我已经在 C5505 eZdsp 中实施了与 AIC3204编解码器进行 DMA 数据交换的三路缓冲方案，配置(正确)为以192kHz 的速率进行采样。
我有三个缓冲器、例如 A、B 和 C。算法是：
当 A 满(中断0x0004)时、我将 B 置于接收状态、将 C 置于传输状态、并详细说明 A 的内容
当 B 满时、我将 C 置于接收中、将 A 置于传输中、并详细说明 B 的内容
当 C 满时、我将 A 置于接收状态、将 B 置于传输状态、然后详细说明 C
...等等。
我的问题是、在这些日子里进行调查、详细信息会溢出、并被 DMA 中断中断中断、从而中断我的算法。
详细说明需要48毫秒(使用 CCS 时钟进行测量、计算周期并将其转换为时间、同时考虑120 MHz CPU 时钟)。 接收缓冲器的采样长度为384个样本、因此、当编解码器以192kHz 的频率交换数据时、填充缓冲器需要2ms。
我正在尝试找到解决此问题的解决方案。
如果您有任何想法、我非常感谢
此致、
[引用用户="Paolo Martinetti]M MAR、 为了将浮点型转换为32位整数型计算、您是否有一些建议的示例/提示？ 谢谢 Paolo
[/报价]
大家好、这取决于您需要转换多少行代码。 基本上、您必须重新编写基于浮点的计算、以便它们以32位(甚至64位)整数完成。 所有函数都需要转换，但您可能必须注意转换过程中引入的错误(量化等)，因为整数不能像浮点那么精确(取决于它们的大小...)。
如果您使用的是库、则可能会查找已使用整数计算编写的版本、避免将浮点组合在一起、并使它们更快地执行。
另一个更严厉的措施(如果您有时间和知识、可以选择)是切换到另一个具有浮点协处理器的处理器 DSP。 查看 TI 浮点 DSP (更基本的 DSP)。 它们更昂贵，消耗更多的功率，但会非常非常快地执行浮点...
谢谢、MM
您好 MMAR、
我有一个想法：
如果我保持接收到的信号的缓冲器、复杂的传输信号、我将以45毫秒的延迟传输详细的信号、这是可以接受的。
你怎么看？
抱歉、我坚持提问、但我是实时编程的新朋友、我需要在不使用功能最强大的 DSP 的情况下解决问题。
再见
[引用用户="Paolo Martinetti]MMAr、 如果我详细说明信号(因此我解调接收到的信号)并以45毫秒的延迟传输信号、我认为通信中不会发生任何情况。
您好，根据您所说的内容快速计算：
DMA 每2ms 传输一次。 这= 1个音频帧= 24 (16位)字节。
您的处理延迟=最大46ms /2ms 音频帧。
您必须等待46ms 才能重新传输前2ms 的音频帧。 因此、您所能做的就是依次存储接收到的2ms、所有23个帧(23 x 2ms = 46ms)、因为它们是通过连续 DMA 传输一个接一个地接收到的、因为 DMA 将在不加载处理器的情况下为您执行此操作。 这将需要至少192000 / 16 x 0、002 x 23 = 552个字的存储(使用高速 DRAM 进行此操作)才能进行接收。
您获取每个接收到的帧，然后依次开始处理序列1、2、3...23，然后将每个结果存储在另一组输出缓冲区1、2、3...中。 23同样按顺序、仅在所有23个输入音频帧均已处理后才可传输。
当您处理完所有23个输入音频帧后、这将花费23 x 46ms = 1058ms。 然后，您可以开始按顺序1、2、3传输输出缓冲器(输出音频帧)... 23等
在您继续接收下一组输入音频帧并将它们存储在23个接收器缓冲阵列中的平均时间内，现在它们是帧24、25、26 ... 46，并且也开始处理等...等等... 等等...
遗憾的是、您的实际延迟看起来更像是1、058ms 秒左右。 这可能会给您的应用带来太多的延迟。 最终、您只能通过将46ms 的处理延迟减少为20ms 或10ms 或更短来降低此延迟。
希望这对您有所帮助。
毫米
是 MMAR、 昨天，我的理由是你所做的那样，得出了同样的结论。 我完全同意您的意见、我将按照您的建议尝试优化、从浮点运算传递到 int32运算。 我注意到、trig 函数 sin、cos 和 atan2在其参数的浮点格式中非常"饿" CPU 周期。 此外、FP 运算(简单的加法和乘法)也会消耗很多。 我学到了很多、但很难。 现在、我尝试使用 Int32格式创建一个 sin、cos、atan2。 我在将 float 转换为 Q31方面也有一些困难...但了解这些参数非常具有挑战性。 很明显、如果您有任何提示、我很高兴听从您的建议。 再次感谢、MMAR！ 此致、 Paolo
P.S. DSPLIB 对我的问题帮助不大。
