DWT->CYCCNT本身是CPU周期计数器，非纳秒计数器；其时间分辨率=1/主频，仅当主频整除1GHz时才能精确实现纳秒级延时，否则存在固有量化误差。
直接用 DWT->CYCCNT 做纳秒级延时不可行——它本身是周期计数器，单位是“CPU时钟周期”，不是纳秒；能否达到纳秒级精度，完全取决于主频是否整除1e9。比如108MHz下，1个周期≈9.26ns，你根本无法精确凑出10ns、50ns这种值。
为什么不能直接把 CYCCNT 当作纳秒计数器用
DWT->CYCCNT 是ARM Cortex-M系列DWT（Data Watchpoint and Trace）模块里的一个32位自由运行计数器，每来一个CPU时钟上升沿就+1。它的分辨率 = 1 / SysClk，仅此而已。
常见误区是认为“开了DWT就能测纳秒”，其实只是“能测到单个时钟周期”，而“纳秒级延时”要求的是可编程、可复现、误差CYCCNT轮询也做不到，除非你主频是1GHz、2GHz这种整数倍关系。
- STM32F401主频84MHz → 周期≈11.90ns，最小步进就是11.90ns，无法实现10ns延时
- GD32F103主频108MHz → 周期≈9.259ns，你写
while(DWT->CYCCNT - start ，实际执行至少是1个周期（9.26ns）或2个（18.52ns），没有中间态 - 哪怕主频1000MHz，也要考虑指令流水线、分支预测、编译器重排对起始/结束点的影响
真正可用的“CYCCNT 辅助延时”怎么做
它不用于生成延时，而是用于**标定和校准**其他延时手段，比如NOP循环、SysTick、甚至GPIO翻转波形。关键思路是：用CYCCNT测出某段代码的真实耗时，再反推参数。
立即学习“C++免费学习笔记（深入）”；
- 必须先使能DWT和CYCCNT：
CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;，然后DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; - 清零计数器要小心：
DWT->CYCCNT = 0;不是原子操作，建议在关中断后做，或用__DSB(); __ISB();同步 - 测量一段空循环时，编译器可能优化掉整个块，务必加
volatile或__attribute__((optimize("O0")))临时禁用优化 - 实测建议跑100次取中位数，避开cache预热、分支误预测等瞬态干扰
示例：标定10个NOP的耗时
__disable_irq(); DWT->CYCCNT = 0; __DSB(); __ISB(); for (int i = 0; i < 10; i++) __NOP(); uint32_t cyc = DWT->CYCCNT; __enable_irq(); // cyc 就是这10个NOP真实占用的周期数
哪些场景下 CYCCNT 测量才真正有意义
它适合回答“这段代码到底花了多少周期”，而不是“我要停50ns”。典型有效用途有：
- 验证SPI/ADC等外设驱动的时序是否满足手册tVALID、tSETUP要求（比如ADS1220要求写寄存器后等≥50μs再读状态，你用
CYCCNT确认delay_us(50)真有50μs） - 排查RTOS任务切换抖动：在PendSV入口/出口打点，看两次
CYCCNT差值是否稳定 - 飞控中姿态解算函数的WCET（最坏情况执行时间）分析——这才是它最该发力的地方
- 对比不同编译器优化等级（-O2 vs -Oz）对关键路径的实际影响
注意：CYCCNT溢出是32位的，100MHz下约43秒溢出一次；若做长延时测量，必须检查溢出位DWT->CTRL & DWT_CTRL_CYCCNTENA_Msk并做补偿，否则数据错乱。
真正要实现亚微秒级可控延时，得靠硬件：比如用高级定时器（TIM1/TIM8）输出单脉冲，或配置SYSTICK为1MHz中断+计数器组合。而CYCCNT的角色，始终是那个沉默但可靠的“裁判”，不是“执行者”。
