我使用的是 s32k314、s32ds RTD4.0.0。
我正在测试 spi 通信。
但我认为效果不佳。
因此，您是否要检查 SpiTimeClk2Cs、SpiTimeCs2Clk 和 SpiTimeCs2CS？
1. SpiTimeClk2Cs、SpiTimeCs2Clk 和 SpiTimeCs2CS 的含义是什么？
2. 请检查 Spi 配置 SpiTimeClk2Cs、SpiTimeCs2Clk 和 SpiTimeCs2CS 与图片的比较。
3.当使用 GPIO 而不是 PS0 控制 SPI 通信的 CS 引脚时，我希望与正常 SPI 时钟操作的时序一致。我该怎么做？(用 PS0 控制时通信不起作用）。
1) 通过 GPIO 控制 cs 引脚（miso 数据有误。）
2) 通过 PS0 控制 cs 引脚
4. 如何固定 spi 时钟中的这一点？
谢谢帮助
当我将 SpiDataShiftEdge 设置为 "尾部 "时，信号源生成在照片的右侧（CPOL(1U)、CPHA(1U)).而当我将 SpiDataShiftEdge 设置为 "Leading "时，信号源生成为图片的左侧（CPOL(1U), CPHA(1U)）。
因此，如果要使用 BNO080，我必须设置 CPOL =1、CPHA =1，还必须设置 SpiDataShiftEdge 为前沿，SpiShiftClockIdleLevel 为高电平。对不对？
你好我回复得太晚了。我做了其他工作。
我还没有解决SPI问题.
总之，我不知道你还记得你的答复。
您回复说我的设置（SpiDataShiftEdge）是错误的，但其他人的引导是正确的。
这是邮政：
https://community.nxp.com/t5/S32K/how-is-set-spi-communication-mode/m-p/2117524
那么，什么是正确的？
(我很抱歉，这么晚才回复......）。
你好@rlaxortn、
问 1：SpiTimeClk2Cs、SpiTimeCs2Clk 和 SpiTimeCs2Cs 的含义是什么？
A1:
- SpiTimeCs2Clk 与 CS 设置时间 (tcssu) 相对应，即 CS 进入激活状态与第一个 SPI 时钟边沿之间的延迟。
- spitimeClk2CS 是指最后一个 SPI 时钟边缘与 CS 处于非活动状态之间的延迟——您的设备未明确指定。
- SpiTimeCs2Cs 是两个连续 CS 激活之间的最短时间，即从 CS 进入非激活状态到下一次激活的时间。
问题 2：你会检查 SPI 配置（spitimeClk2cs、spitimecs2clk 和 Spitimecs2CS）并将其与时序图进行比较吗？
A2：SpitimeClk2CS、SpitiMecs2CLK 和 SpitiMecs2CS 的值通常可以保持在 1 µs，这对于大多数设备来说是安全的。
但是， SPIDataShiftEdge设置存在一个关键问题——应将其设置为 尾随 设置，因为您的设备（BNO080）要求CPOL = 1，CPH A = 1。
问题 3：当用 GPIO 而不是 PS0 控制 SPI 通信的 CS 引脚时，我希望与正常 SPI 时钟操作的时序一致。我该怎么做？(使用 PS0 控制时，通信不起作用。）
A3：如果计时处理得当，应该不会有问题。将 GPIO 用于 CS 时的推荐顺序是
- 将 CS 拉低
- 等待 0.5-1 微秒
- 启动 SPI 传输
- 等待传输完成
- 再次等待 0.5-1 微秒
- 版本 CS HIGH
这模仿了硬件控制的 CS 的行为，并确保了从属设备的时机正确。
问题 3a： 通过 GPIO 控制 CS 引脚会导致不正确的 MISO 数据。
A3a： 如上所述，这可能是由于 SpiDataShiftEdge 设置不正确造成的。请确保将其设置为 TRAILING 以匹配 CPHA = 1。
Q3b：通过 PS0 控制 CS 引脚（硬件控制）
A3b：这个设置总体看来是正确的。唯一需要考虑的是 CS 激活之前的初始 CLK 脉冲。但是，由于该脉冲是在 CS 钳位之前发生的，因此它应该是无害的，并且会被从属设备忽略。
问题4：如何修复SPI时钟中的标记点（意外脉冲）？
A4：即使 CS 由 LPSPI 模块控制，也会出现类似的脉冲确实是不寻常的。请检查在拉低 CS 和启动 SPI 传输之间执行了哪些代码。任何过早启用 LPSPI 模块或错误配置定时参数的行为都可能导致这种现象。
顺祝商祺！
帕维尔