• 状态 Resolved
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 332 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] 通过 HWREG 读取 ADC0 FIFO

admin
Guru**** 2482225 points
Other Parts Discussed in Thread: EK-TM4C1294XL

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/726562/adc0-fifo-reads-via-hwreg

器件型号：TM4C1294KCPDT
Thread 中讨论的其他器件：EK-TM4C1294XL

通过 EK-TM4C1294XL GPTM 102Hz 发生   器对 ANIx 输入进行的测试通过放置在 SS1的3个 AINx 输入中的每一个的单个测试导线来揭示读取 FIFO 数据失败通过 HWREG 通过 Tivaware 宏调用循环读取特定阵列电平似乎失败。 尽管 SS1第0步似乎   已经不那么令人反感、 但 HWREG 读取循环 FIFO 时  返回错误数据、最后  一步的 IE 减 去源引脚。 如果 在与源极引脚的一个步长上存在结束 IE、则其他 WISE HWREG 调用无法读取任何数据。   虽然 HWREG 调用 会将 序列发生器 FIFO 读取 到专用阵列步骤中、 但最终会消耗 它看似 与 其他序列发生器数据交叉的任何剩余数据。 令人困惑 的是、FIFO 滤波、 检查、漏极、上溢/下溢状态类型的宏调用如何防止 这一列车的任何部分从最终灾难中崩溃、这种情况非常令人惊奇、因为它模拟了疯狂的 DSP 信号。  

通过     ADCsequencerDataGet ()对  放入单 个缓冲器阵列的所有步骤进行批量读取、似乎 Tivaware 会从触发的 FIFO 读取中发现不正确的数据。 似乎这 并不能保持 StellarisWare M3代码的兼容性、该代码用于 通过 迁移到 Tivaware 和 M4 Macro 调用来读取单步 FIFO 数据、 而这些调用似乎以某种方式跨越 了过程中 AD 转换器的 FIFO 数据。

  当 HWREG 读取 序列发生 器步骤 由  循环 FIFO 上的 C++指令触发时、通过数据表中所述的特定序列发生器步骤采样的 AINx 引脚的输入源似乎会失败。

下面的级联如何捕获  序列发生器和数组之间可能发生的交叉链接 FIFO 数据、这些数据来自对序列发生器 FIFO 的 HWREG 调用？  

为什么 一个 AINx 输入上几乎没有201Hz 信号、而另 两个输入 在  同一个源发生的不同振幅下具有某种相似性？    

低于201Hz +3.2V GPTM AINx 的输入源 在 3个阶跃之间移动 SS1会导致 返回3个不同级别的 FIFO 数据。  即使 在添加虚拟触发 器(HWREG 调用) 以读 回 3 个序列发生器阶跃后、 也 不会返回与下图所示相同的201Hz GPTM 数据振幅。 此问题困扰 着最终产品的生产。

ui16ADC0DataRaw[1]= HWREG (ADC0_BASE + ADC_O_SSFIFO0)；

/********* /

ulTemp=HWREG (ADC0_BASE + ADC_O_SSFIFO1)；

ui16PhaseRaw[1]= HWREG (ADC0_BASE + ADC_O_SSFIFO1)；


  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    BP101、
    在直接读取 FIFO 之前、您是否检查了最后一次转换是否已完成以及 FIFO 中是否有新数据？ (我们真正推动使用 TivaWare 库例程的一个原因是、其中许多细节都是为您精心准备的。)
  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Bob：

    当然、当转换从 FIFO 采样就绪结束标志触发一个 NVIC 中断时、转换完成。 请再次阅读、在看到一些奇怪的行为后、重新考虑了顶部帖子。 使用基本上执行相同 HWREG 宏调用的 Tivaware 库调用、无法执行 FOC 换向所需的复杂采样。 HWREG 宏似乎无法设置可用于 M3序列发生器的正确 CPU 指令(指针)。

    您可能已经注意到、最后一个序列发生器步骤缺少源引脚、我发布的配置是由 TI 工程师开发的。 这似乎是某种指针故障、无法通过尾指针指示 FIFO 数据的开始/结束位置。 ADCsequencerDataGet() HWREG 调用不使用 Tail 指针，因此从另一个角度来看，这可能是一个错误。

  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    BTW：第一个序列发生器 SS0 HWREG 读取步骤0、1时、HWREG 调用中的尾指针似乎不受影响。 正是 SS1 FIFO 数据在这个问题上受到了极大的影响。 过去的 M3代码 ANIx 样本都是 SS0的一部分、因此、如果这一问题在过去也存在、Stellaris 工程师可能还没有考虑到这一问题。
  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    BP101、
    TI 已验证 ADC 和 FIFO 是否正常运行。 与数千名成功使用这些器件的 TM4C 客户一起、我们发现问题最可能出在您的软件或硬件上。 我无能为力。 如果您能够创建一个独立的项目、例如仅在 Launchpad 上运行的项目、该项目可以演示您认为 TM4C 器件操作不当的情况、我很高兴能查看该项目。
  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    [引用 user="Bob Crosby"]TI 已验证 ADC 和 FIFO 是否正常运行。 与数千名成功使用这些器件的 TM4C 客户一起、我们发现问题最可能出在您的软件或硬件上。 我无能为力。 [/报价]

       有多少客户正在进行 bamboozled 读取他们为序列发生器1及以上配置的内容更是个问题。

    如果 TI 认为(hw-adc.h)寄存器偏移正确 或使其成为嵌入式 MCU 代码的一部分、它 可能会解释头/尾指针 (ADCSSFSTAT)寄存器 似乎不  是 R/W 正确 的索引、 从而使    通过 HWREG 访问 SS0以上的阵列 R/W 的问题复杂化。

    序列发生器0的第0步 FIFO 数据不应从 数组[1]中读取 、如果   未配置第1步、也可以看到 该数据、这表明索引 TPTR 存在问题。  HWREG 宏是 Tivaware 调用的一部分、需要按照 FIFO R/W 过程的任何顺序正确地从任何单个序列发生器中检索数据！  客户不应成为中或硬件中软件功能不正确的受害者、而应执行简单的基本和必要的 R/W 序列发生器操作。

    同样、Tivaware 并未证明所有 序列发生 器都能够  对任一 单步执行进行 R/W 校正、并且 从  上述步骤中读取循环 FIFO 数据、因此与 被采集的样本相匹配。  这是典型的序列发生器功能、而不是我们所做的事情。   被完全忽略的三级联采样振幅会响铃一个问题、振幅 远高于+/-30 LSB！

    问题是为 AIN CH16配置的 SS1或 SS2第0步 似乎与 另一个 GPIO 引脚交叉数据 ADCSSMUX 19：16至15：0位正在置位

  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    在 HWREG 触发 FIFO 读取期间、C++阵列数据位置对齐的快速测试保持一致。 检查尾指针寄存器0x4003.8000偏移(0x48、0x68、0x88、0xA8)分别是 ADC0、 FIFO 0-3与  存储阵列[x]中的数据存储位置完全匹配。 FIFO 是32位的、前16位被保留、所以如果   我们 读取结果&0xFFF、Ui16不会出现大于 MSB 12的数据错误。

    显然、0xFF 和0xF 不是序列发生器1或2的正确头指针或尾指针。 

    如果 HWREG ((ADC0_BASE + ADC_O_SSFSTAT2)& ADC_SSFSTAT1_TPTR_M = 0x0)
｛
ui16ADCRaw[0]= HWREG (ADC0_BASE + ADC_SSFIFO1)；
｝

如果

HWFIFPTR (ADC0_BASE + ADC0_ADC0_CAST_FO=0_ADC0_ADC1_BASE
)




= 0xADCSSO_ADC0_ADC1_ADC0_ADC1_ADC1_ADC1_ADC1_ADC1_FO_ADC0_CASTUCR+ADC0_CAST_FO=ADCK_1 (ADCK_1)+ ADC0_ADC0_ADCK_FO_ADC0_CAST_CAST_CAST_CAST_ADC0_FO_ADC0_CAST_FO=ADC0_CAST_ADC0_CAST_FO=ADCK_1)+ ADC0_ADCK_1 + ADC0_CAST_RES_ADC0_ADCK_1 + ADC0_ADC0_ADC0_CAST

如果 HWREG (((ADC0_BASE + ADC_O_SSFSTAT2)& ADC_SSFSTAT1_TPTR_M = 0x3)
)｛
ui16ADCRaw[3]= HWREG (ADC0_BASE + ADC_O_SSFIFO1)；
｝

  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    最初、我认为索引 TPTR 应该是 FIFO 地址的一部分、而不是 SSFSTATn 寄存器地址。 在读取后的第二个考虑中、ADCSSMUX 根据 EMUX0位被清零选择 AINx 19：16或15：0通道可能更适合 PK0输入数据的 CH16问题。

    稍后、我们将 SS2步骤0切换为在 CH17上使用 PK1、以查看浮动电压(158mV)是否在 CH16 PK0上发现 EKXL/EVM 发生变化。
  • 0
    TI__Guru**** 2482225 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    "我们？？？"    有没有(更多)过一位女巫-为这种"深思熟虑"的酿造做出贡献？