功能要求的实时性很高，需要能捕获到每一个正弦波。我把ADC的数据放到dma中断里面都会被USB打断，因为我采集1000个点，每次都在两次上报之间出现数据丢失的问题，已经把USB的中断优先级降低到4了，DMA和ADC都是0，但依旧出现丢失数据的情况。 现在正在采用串口DMA方式传输，看看能不能解决问题
1.如下图 理论上SETUP事务后 STM32-USB设备应当在IN事务后进行上传设备描述符信息 不太理解HAL库在USB-Device在接收到SetUP事务后的逻辑：HAL_PCD_EP_Transmit是只是将数据存储到FIFO中，等到接受到IN事务后进行发送处理吗？ 但是查看DATAIN函数的运行轨迹很奇怪，麻烦指点一下
给些参考建议： 硬件上检查连线、焊接、接地、系统电源稳定性方面问题； 注意有无电磁干扰方面的问题，必要时考虑做些回避或屏蔽； 系统时钟尽量使用HSE做时钟源； 软件方面重点检查两边的UART通信配置是否完全一致。如果性能可以接受的话，波特率尽量低点； 软件代码方面加强出错监视，在检查到出错时做适当处理，包括在适当位置做LOG输出；
你这样吧。你可以参考下STM32F7456DISC板的相关例程。它的例程里刚好就有针对25Q126的操作。 例程在这个地方： \STM32Cube_FW_F7_V1.17.2\Projects\STM32746G-Discovery\Applications\QSPI\QSPI_perfs
采样速度太高，加上多通道，已经接近CPU的负荷上限，加上FFT就更大了。 所以建议采用64点或128点FFT，以减小CPU负荷，当然，RAM的使用也需要合理规划，否则肯定溢出了。
不同时通信，多核工作的时候可能两个核是单独的程序，我调试的时候基本只能调试一个，或者另一个功能固定，是有固件的，调试口基本上就是其中一个核的，另一个核如何调试下载
假设你的VREF+=VDD, VREF-=GND,做差分采样的话，结果还是在0~4095间变化。 不过，转换结果0对应的是INP接GND，INN接VREF时的情形； 结果4095对应的是INP接VREF，INN接GND时的情形； 当INP=INN时的转换结果则是2048； 假设你现在每次的ADC结果放在dat变量里，你计算那个电阻两端的电压时，应该是 ResultF=((int32_t)(dat-2048)/2028.)*vref; uint32_t ADC_Buf8]; float ResultF=0.0; 下面我这边的测试结果。 Case 1： VINP=VREF, VINN=GND; 对于第三种情形，我搞一根导线将二者连接起来的，测试结果来看，压差将近5mv。
既然是新手就不用使用那个标准库着手学习了，也最好不要使用STM32F1系列芯片，使用STM32G4 G0 U5 H5 系列都可以. 请你使用STM32CubeMx图形化工具和Cube库来着手开发。 你可以到WWW.ST.COM搜索STM32Cube库，每个系列都有。下载后可以先从最简单的例程开始。
您可以在下面链接下载： https://github.com/STMicroelectronics/st-mems-android-linux-sensors-hal
这个地方，手册描述没有什么问题。手册里介绍时，是让TIMER工作在触发从模式，触发后输出1个相关指定宽度的脉冲。 不过单脉冲模式跟TIMER是否工作在从模式没有必然关系，使用单脉冲输出模式时，计数器的使能启动既可以通过软件使能启动，也可以将 定时器配置在触发从模式经过信号触发启动. 单脉冲输出模式是PWM输出模式的特例，利用该模式并不一定只是输出单个脉冲。如果是通用定时器，每次使能计数器后只输出一个PWM脉 冲，如果是高级定时器，每次使能计数器后可能输出多个PWM脉冲，具体多少除了与RCR寄存器的值有关外，还跟计数器的计数模式有关； 即使是输出一个脉冲，其形状特征除了跟CCR值有关外，还跟PWM模式、极性选择有关。
更新，大结局。 TRM确实是对的icode和dcode是执行code使用的。 st更新了bus架构图，回答了我的疑惑，确实是如我猜测的那样，通过重映射来实现icode，dcode对sram的访问
.png)
