1. 项目缘起：为什么需要“最大速度”翻转GPIO？
在嵌入式开发，尤其是基于STM32这类MCU的项目里，控制GPIO引脚的高低电平翻转是最基础的操作。你可能觉得，不就是一句HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_0)的事吗？确实，对于大多数控制LED闪烁、检测按键的应用，标准库或HAL库提供的函数完全够用，时序上差个几十纳秒甚至几微秒，根本感知不到。
但当你开始涉足一些对时序要求极其苛刻的场景时，情况就完全不同了。比如，你想用GPIO模拟一个精度要求很高的通信协议（如DHT11温湿度传感器的单总线协议，其时序要求以微秒计）；或者，你在用IO口直接驱动一个需要特定脉冲宽度的器件；再比如，你在做软件PWM、红外发射编码，或者仅仅是想测量一下你代码执行某段逻辑的最短时间。在这些场景下，GPIO翻转速度的极限，就直接决定了你系统性能的上限和功能的可行性。
我最初意识到这个问题，是在尝试用STM32F103的IO口模拟一个高速串口时。用HAL库的翻转函数，最高波特率死活上不去，波形用逻辑分析仪一看，方波的边沿抖得厉害，周期也不稳定。这才逼得我去深挖：从软件触发到物理引脚电平变化，这中间到底经历了什么？所谓的“最大速度”到底被什么限制了？我们又能在哪个层面上进行优化？
所以，今天我们就抛开那些封装好的库函数，深入到寄存器层面，甚至结合一点编译器的知识，来一场关于STM32 GPIO极限速度的“压榨之旅”。目标很明确：让一个GPIO引脚在程序控制下，以MCU内核所能允许的最快速度，稳定地输出方波。这不仅是一个有趣的性能挑战，更能让你透彻理解从软件指令到硬件动作的完整链条。
2. 理解瓶颈：GPIO速度的制约因素链条
要实现最大速度翻转，我们得先知道“敌人”在哪里。从你写下那行翻转代码开始，到示波器上看到一个完美的方波，中间至少经过以下几个可能产生延迟的环节：
2.1 软件层面的开销
这是最容易被忽视，但也最容易被优化的部分。当你调用HAL_GPIO_TogglePin()时，你实际上调用了一个包含多层封装的函数。这个函数内部会进行参数检查、计算引脚掩码、访问对应的寄存器。对于HAL库，其函数体可能还包含了一些状态管理和超时判断（虽然Toggle函数通常很简单）。每一次函数调用，都有压栈、跳转、执行、返回的开销。在追求极限速度时，这种开销是巨大的。
2.2 总线访问延迟
STM32的CPU（Cortex-M内核）通过总线矩阵（Bus Matrix）访问外设寄存器。GPIO的寄存器挂在AHB（高级高性能总线）或APB（高级外设总线）上。对寄存器的每一次读或写操作，都不是瞬间完成的，它需要经过总线的仲裁、传输。虽然这个延迟通常很小（几个时钟周期），但在以MHz频率翻转IO的语境下，它也变得不可忽视。特别是如果你错误地将GPIO所在的端口时钟配置在了较低速的总线上（比如本该在AHB上却配在了APB上），延迟会显著增加。
2.3 GPIO硬件本身的响应速度
即使CPU瞬间写入了寄存器，GPIO端口硬件电路改变输出电平也需要时间。这个时间主要由GPIO端口本身的“输出速度”配置决定。在STM32的GPIO初始化结构体中，有一个GPIO_InitTypeDef.Speed成员，可以配置为低速、中速、高速、超高速（具体等级因型号而异）。这个配置直接影响的是IO口驱动电路的压摆率（Slew Rate），即电平从低到高或从高到低变化的速度。配置为低速模式，内部会使用较小的驱动电流，变化慢，但噪声小、功耗低；配置为高速/超高速模式，会使用更大的驱动电流，变化快，但功耗和噪声也会增加。如果你需要输出高频信号，却配置成了低速模式，硬件本身就会成为瓶颈。
2.4 物理线路与负载
最后，信号到达物理引脚后，还要经过PCB走线，并驱动负载（比如一个LED，或者示波器探头）。如果走线很长、容性负载很大（比如直接驱动一个大的LED阵列而没有缓冲），上升/下降时间会变长，导致方波变形，从示波器上看就是边沿不陡峭。这虽然不属于软件优化范畴，但在实际测量极限速度时，必须使用尽可能短的引线和轻的负载（通常接一个50欧姆端接到示波器），以避免测量误差。
我们的优化，将主要集中在前三个层面：编写极致高效的软件、确保总线架构最优、正确配置GPIO硬件。
3. 从HAL到寄存器：剥离软件开销
让我们从最上层的应用代码开始，一步步向下优化。假设我们要让PA0引脚以最快速度翻转。
3.1 基准测试：使用标准HAL库
首先，我们建立一个性能基准。使用STM32CubeIDE或Keil创建一个工程，开启PA0的GPIO输出模式，然后在主循环里调用HAL库的翻转函数。
// 初始化代码略... while (1) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_0); }用逻辑分析仪或示波器测量PA0输出的方波频率。以STM32F103C8T6（72MHz主频）为例，你测到的频率可能只有1-2MHz左右。这个速度远远低于理论值，原因就是函数调用的开销。每次循环，CPU都要执行一大堆指令来实现那个“安全”但“臃肿”的Toggle函数。
3.2 第一级优化：直接操作寄存器
STM32的GPIO输出数据寄存器是GPIOx->ODR。翻转一个引脚，本质上就是让这个寄存器对应的位取反。我们可以绕过HAL，直接操作寄存器。
while (1) { GPIOA->ODR ^= GPIO_PIN_0; // 使用异或操作进行位翻转 }^=操作符会先读取GPIOA->ODR的当前值，然后与GPIO_PIN_0（其值为0x0001）进行按位异或，最后将结果写回ODR寄存器。这样一次循环包含了一次读、一次异或运算、一次写。实测下来，频率可以提升到10MHz左右，相比HAL有了数倍的提升！但这里依然有优化空间：ODR寄存器的读-修改-写操作不是原子的，且效率并非最高。
3.3 第二级优化：使用位设置/复位寄存器（BSRR/BRR）
STM32的GPIO提供了一个巧妙的寄存器：GPIOx->BSRR（位设置复位寄存器）。这个寄存器是“写1有效”。它的高16位用于复位引脚（输出低电平），低16位用于设置引脚（输出高电平）。最关键的特性是：对BSRR的写操作是“一次性的”和“原子的”。你写入一个值，相应的引脚立刻被置位或复位，而不影响其他引脚，也无需先读取当前状态。
那么如何实现翻转呢？我们需要知道引脚当前的状态，然后决定向BSRR的哪一部分写入。但我们可以用另一个寄存器来避免读-修改-写：GPIOx->ODR的“影子”——GPIOx->IDR（输入数据寄存器）？不对，对于输出模式，读取ODR才是最直接的。但还有更好的办法吗？有，那就是使用两个独立的操作，但通过一点小技巧。
while (1) { // 方法A：判断后设置/清除 if (GPIOA->ODR & GPIO_PIN_0) { GPIOA->BSRR = GPIO_PIN_0 << 16; // 当前为高，则置位BRR位（高16位）使其变低 } else { GPIOA->BSRR = GPIO_PIN_0; // 当前为低，则置位BSRR位（低16位）使其变高 } }这个方法虽然用到了判断分支（if-else），可能会因分支预测影响一点效率，但它避免了读-修改-写ODR。然而，在追求极限的场合，分支是不可接受的。我们需要一种确定性更高、周期数更少的方法。
3.4 第三级优化：使用ODR的“取反写回”与编译器优化
让我们回到ODR，但尝试更极端的写法。我们能否让编译器生成更高效的代码？考虑以下代码：
while (1) { GPIOA->ODR = ~GPIOA->ODR; // 翻转整个端口 }这会把端口A的所有16个引脚都翻转，显然不是我们想要的。我们只想翻转PA0。那么可以这样：
#define PIN_MASK GPIO_PIN_0 while (1) { GPIOA->ODR ^= PIN_MASK; }这就是我们3.2节的做法。在-O2或-O3优化等级下，编译器可能会将这段循环编译成非常精简的汇编。但“读-修改-写”的本质没变。有没有一条汇编指令能直接完成“翻转某个内存地址的某个位”呢？在ARM Cortex-M的指令集里，没有直接的“位翻转”内存操作指令。最接近的是LDREX/STREX（独占访问），但那用于多核或中断环境，更复杂。
所以，在纯C语言层面，ODR ^= PIN_MASK可能已经接近最优。但我们可以做另一件事：确保操作的数据都在CPU寄存器中。将GPIOA的地址和PIN_MASK加载到寄存器，然后在循环中只进行寄存器的异或和存储操作。
#define GPIOA_ODR (*(volatile uint32_t*)0x4001080C) // PA端口的ODR寄存器地址 #define PIN0_MASK (1U << 0) void fast_toggle(void) { volatile uint32_t *odr = &GPIOA_ODR; uint32_t mask = PIN0_MASK; while (1) { *odr ^= mask; } }通过将地址和掩码放入局部变量（编译器很可能将其优化到寄存器中），可以减少每次循环从内存加载常量的开销。配合编译器最高级别优化（-O3），这个循环的汇编可能被精简到只有几条指令：加载ODR值到寄存器，与掩码异或，存回ODR。实测在72MHz的Cortex-M3上，这种方法可能产生约18MHz的方波（一个周期包含上升和下降沿，所以翻转频率是时钟频率的1/4左右？这里需要仔细算）。
注意：这里直接给出了ODR的地址（0x4001080C），这是STM32F1系列GPIOA_ODR的地址。不同系列、不同型号的STM32，这个地址可能不同。最可移植的方法还是使用
GPIOA->ODR，编译器在优化时同样能处理好。
4. 核心加速：深入汇编与编译器屏障
当C代码的优化触顶后，如果想再榨取一点性能，就必须请出汇编语言，或者使用一些编译器内置指令来指导编译器生成我们想要的代码。
4.1 内联汇编实现
以ARM GCC编译器为例，我们可以使用内联汇编来精确控制指令。
void toggle_pa0_asm(void) { while (1) { __asm volatile ( "ldr r1, =0x4001080C \n" // 将GPIOA_ODR地址加载到r1 "ldr r0, [r1] \n" // 将ODR当前值加载到r0 "eor r0, r0, #0x0001 \n" // r0与1异或，翻转第0位 "str r0, [r1] \n" // 将结果存回ODR // 注意：这里没有延时，会疯狂循环 ::: "r0", "r1", "memory" // 告诉编译器我们修改了r0, r1和内存 ); } }这段汇编直接对应了C代码GPIOA->ODR ^= 1;，但去除了所有C语言可能带来的额外开销（比如检查变量是否在寄存器等）。理论上，这是C语言能达到的极限效率的直观体现。但即便如此，它仍然是一条加载（LDR）、一条异或（EOR）、一条存储（STR）指令，至少3个时钟周期。在72MHz下，单次翻转（一次电平变化）需要至少1.5个周期？不对，一次完整的翻转（高->低->高）需要执行两次这个循环体。所以频率大约是 72MHz / (3 cycles * 2) = 12MHz。这似乎比我们之前用C测的18MHz还低？这说明编译器优化后的C代码可能比我们手写的这段汇编更高效（例如，编译器可能使用了更快的寻址模式，或者将某些操作进行了流水线优化）。
4.2 编译器优化屏障与Volatile
在操作硬件寄存器时，volatile关键字至关重要。它告诉编译器，这个变量的值可能会被硬件或其他线程意外改变，因此编译器不能对这个变量的读写操作进行优化（比如，不能把连续的多次写合并成一次，不能把读操作缓存到寄存器而不再从内存读取）。
在我们之前的代码中，GPIOA->ODR已经被定义为volatile uint32_t，所以是安全的。但在我们追求极限的循环中，编译器可能会觉得这个无限循环没有意义，从而进行一些激进的优化，甚至可能把循环体移除！为了防止这种情况，我们需要确保循环体被正确执行。
while (1) { __asm volatile ("" ::: "memory"); // 编译器内存屏障 GPIOA->ODR ^= GPIO_PIN_0; __asm volatile ("" ::: "memory"); // 另一个屏障 }__asm volatile ("" ::: "memory")是一个内联汇编语句，它不产生任何实际指令，但告诉编译器：“在此处，内存内容可能被更改了”。这会阻止编译器跨这个屏障对内存操作进行重排序或优化。在极限优化时，这可以保证我们的翻转操作不会被编译器“优化掉”。不过，在大多数情况下，对于volatile变量的操作，编译器已经足够谨慎，不需要额外添加屏障。
4.3 循环展开
另一种常见的优化手段是循环展开（Loop Unrolling）。与其在循环中只做一次翻转，不如连续做多次，减少循环判断的开销。
while (1) { GPIOA->ODR ^= PIN_MASK; GPIOA->ODR ^= PIN_MASK; GPIOA->ODR ^= PIN_MASK; GPIOA->ODR ^= PIN_MASK; // ... 可以展开更多次 }这样，每次循环判断while(1)时，内部执行了4次翻转，理论上提高了效率。但编译器在-O3优化下，可能会自动进行循环展开。我们可以通过#pragma unroll(GCC) 或__attribute__((optimize("unroll-loops")))来提示编译器。不过，对于这个极其简单的死循环，手动展开的效果可能并不明显，因为循环跳转本身的开销已经很小。
5. 硬件配置：解锁GPIO的物理潜能
前面的优化都在软件指令层面。现在，我们要确保硬件没有拖后腿。这主要涉及两方面：时钟和GPIO输出模式配置。
5.1 时钟树配置：让总线跑在全速
GPIO端口挂载在哪个总线上，这个总线的时钟频率是多少，至关重要。以STM32F4系列为例，GPIOA通常挂在AHB1总线上。在系统初始化时，你需要通过RCC（复位与时钟控制）模块，确保AHB1的时钟分频系数为1（即不分频），使其运行在系统时钟的最高频率（如168MHz）。如果你错误地将AHB1分频了，GPIO的访问速度就会直接打折。
在STM32CubeMX中配置时钟树时，务必检查AHB Prescaler是否为1。在代码中，初始化后可以检查一下相关时钟：
// 检查AHB1时钟频率（以HAL库为例） SystemCoreClockUpdate(); // 更新SystemCoreClock变量 printf("SystemCoreClock: %lu Hz\n", SystemCoreClock); printf("AHB1 frequency should be same as SystemCoreClock if prescaler=1.\n");5.2 GPIO输出模式与速度配置
这是硬件层面影响翻转速度最直接的设置。在初始化GPIO时，我们通常使用HAL_GPIO_Init。现在，我们直接配置寄存器来确保最优。
void GPIO_MaxSpeed_Init(void) { // 1. 使能GPIOA时钟（假设挂在AHB1上，以F4为例） RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN; // 2. 配置PA0为推挽输出模式，无上拉下拉 // MODER[1:0] = 0b01 (输出模式) GPIOA->MODER &= ~(GPIO_MODER_MODER0_Msk); // 先清零 GPIOA->MODER |= (0x01 << GPIO_MODER_MODER0_Pos); // 设置为输出 // OTYPER[0] = 0 (推挽输出) GPIOA->OTYPER &= ~(GPIO_OTYPER_OT0); // OSPEEDR[1:0] = 0b11 (非常高速，具体含义见参考手册) GPIOA->OSPEEDR &= ~(GPIO_OSPEEDER_OSPEEDR0_Msk); GPIOA->OSPEEDR |= (0x03 << GPIO_OSPEEDER_OSPEEDR0_Pos); // PUPDR[1:0] = 0b00 (无上拉下拉) GPIOA->PUPDR &= ~(GPIO_PUPDR_PUPDR0_Msk); // 初始输出低电平 GPIOA->BSRR = GPIO_PIN_0 << 16; // 使用BRR部分复位 }重点关注OSPEEDR（输出速度寄存器）的设置。对于STM32F4，这个2位字段可以配置为：
- 00: 低速 (约2 MHz)
- 01: 中速 (约25 MHz)
- 10: 高速 (约50 MHz)
- 11: 非常高速 (约100 MHz)
这里的“MHz”不是指你能输出的信号频率，而是指该IO口驱动电路在特定负载（如30pF）下的压摆率对应的近似信号带宽。设置为“非常高速”，意味着IO口内部使用更强的驱动电流，可以更快地对引脚电容充电放电，从而得到更陡峭的边沿。这对于输出高频方波至关重要。如果设置为低速，即使你的软件翻转得再快，硬件也反应不过来，输出的波形边沿会非常缓慢，看上去就不是方波了。
重要提示：将速度设置为最高，会增加功耗和可能产生的电磁干扰（EMI）。在不需要极限速度的应用中，应根据实际需要选择最低足够的速度，以降低噪声和功耗。
6. 测量与验证：如何准确评估极限速度
优化了半天，我们怎么知道效果如何？需要科学的测量方法。
6.1 使用示波器或逻辑分析仪
这是最直接的方法。将MCU的引脚通过短而优质的线缆连接到示波器或逻辑分析仪的探头上。
- 示波器：可以直观看到波形形状、上升/下降时间、频率和占空比。测量翻转频率时，最好使用示波器的频率计功能，或者测量多个周期的平均时间。
- 逻辑分析仪：更适合抓取和分析数字时序，可以清晰地看到翻转的周期和稳定性。
6.2 测量方法
- 测量频率：让程序运行我们优化后的无限翻转循环。在示波器上应看到一个近似方波。测量其周期T，频率f = 1/T。这个频率就是该引脚在纯软件驱动下的最大翻转频率。注意，这个频率是输出信号频率，等于软件翻转频率的一半（因为一次完整的电平变化算一次翻转，而一个方波周期需要两次翻转：高->低和低->高）。
- 观察波形质量：重点关注上升时间和下降时间。在最高速度配置下，边沿应该非常陡峭（例如，在3.3V系统下，从10%到90%的上升时间可能在几纳秒到十几纳秒，具体取决于芯片型号和负载）。如果边沿很缓，说明GPIO速度配置可能不对，或者负载太重。
- 检查稳定性：观察方波是否稳定，周期是否抖动。在纯软件循环中，由于指令执行时间是确定的，周期应该非常稳定。如果出现抖动，可能是被中断打断了。为了测量极限速度，在测试前需要关闭所有中断（包括SysTick），让CPU全心全意执行我们的翻转循环。
6.3 计算理论极限
我们可以粗略估算理论极限。假设：
- CPU主频：
F_cpu = 72 MHz，周期T_cpu ≈ 13.89 ns。 - 一次翻转操作（
ODR ^= mask）编译后假设需要N个时钟周期。通过反汇编可以精确知道。假设N=4。 - 那么执行一次翻转操作的时间是
T_flip_op = N * T_cpu。 - 产生一个完整的方波周期需要两次翻转操作（高->低，低->高），所以方波周期
T_square = 2 * T_flip_op。 - 最大方波频率
F_max_square = 1 / T_square = F_cpu / (2 * N)。
如果N=4，F_cpu=72MHz，则F_max_square = 72 / (2*4) = 9 MHz。
这个计算忽略了总线延迟、指令预取等因素，但可以作为一个数量级参考。如果你测得的频率远低于这个值，说明软件或硬件配置还有优化空间；如果接近甚至略超（考虑到流水线等优化），说明优化已经比较到位。
7. 超越纯软件：使用定时器与DMA实现终极翻转
纯软件循环的翻转速度受限于CPU取指、译码、执行指令的速度。有没有办法让GPIO翻转不占用CPU资源，甚至比CPU操作更快？有，那就是使用外设：定时器（TIM）的PWM输出模式或定时器结合DMA。
7.1 使用定时器PWM输出模式
这是实现高精度、高频率方波最标准、最稳定的方法。将一个GPIO引脚配置为某个定时器（如TIM1, TIM2, TIM3...）的PWM输出通道。通过配置定时器的自动重载值（ARR）和比较寄存器（CCRx），可以精确控制输出波形的频率和占空比。一旦启动定时器，硬件就会自动在比较匹配时翻转引脚电平，完全不需要CPU干预，精度可达单个时钟周期。
例如，在72MHz下，如果定时器时钟不分频，那么产生一个1MHz的方波（周期1us）轻而易举，且波形极其稳定，不受中断或其他任务影响。频率上限取决于定时器本身的时钟和分辨率要求。
7.2 使用定时器更新事件触发DMA修改GPIO
这是一种更灵活、可以产生任意波形的方法，但同样不占用CPU。思路是：
- 配置一个定时器，以你想要的频率产生更新事件（UEV）。
- 配置DMA，将定时器的更新事件作为DMA传输请求源。
- DMA的目标地址设置为GPIO端口的位置置位/复位寄存器（如
BSRR）或输出数据寄存器（ODR）。 - 在内存中定义一个数组（波形表），里面存放着需要依次输出到GPIO的电平数据。
- DMA在每次定时器更新时，自动将波形表中的下一个数据传输到GPIO寄存器，从而在引脚上产生预设的波形。
这种方法可以产生非常复杂的数字波形，频率也可以很高（受限于DMA和总线的速度）。对于简单的方波，有点杀鸡用牛刀，但它展示了脱离CPU后IO操作的另一种可能。
7.3 纯软件 vs 硬件外设
| 特性 | 纯软件循环翻转 | 定时器PWM输出 |
|---|---|---|
| 最大频率 | 较低，受CPU指令速度限制（通常<20MHz） | 极高，可达定时器时钟的一半（如72MHz下可达36MHz） |
| 精度/稳定性 | 一般，易受中断、总线竞争影响 | 极高，由硬件时钟驱动，绝对稳定 |
| CPU占用 | 100%，CPU被死循环独占 | 0%，配置好后CPU可休眠或执行其他任务 |
| 灵活性 | 高，可随时插入复杂逻辑 | 较低，主要用于固定频率/占空比的波形 |
| 实现复杂度 | 低 | 中（需配置定时器） |
所以，如果你的目标是获得一个频率尽可能高的方波信号，那么使用定时器的PWM模式是唯一正确且高效的选择。我们今天探讨的“纯软件最大速度翻转”，更多是一种对MCU底层性能的探索和理解，在实际产品中，除非有非常特殊的理由（比如在一个没有多余定时器的芯片上临时产生一个中低频信号），否则都应优先考虑硬件方案。
8. 实战心得与避坑指南
在折腾这个极限翻转的过程中，我踩过不少坑，也总结了一些经验。
8.1 编译器优化等级是关键
在测量性能时，务必使用-O2或-O3优化等级进行编译。在调试模式（-O0）下，编译器不会进行任何优化，生成的代码非常冗余，性能可能比优化后慢5-10倍。这会导致你的测量结果毫无意义。在Keil或IAR中，记得在Release配置下测试；在STM32CubeIDE或GCC环境中，在Makefile或项目属性中设置优化标志。
8.2 关闭中断与调试器
为了得到纯净的、不受干扰的极限速度，在最终测试时：
- 关闭所有中断：包括SysTick定时器中断。SysTick通常用于HAL的延时函数，它会周期性打断你的循环。
__disable_irq(); // 关闭总中断 // ... 你的极限翻转循环 ... // __enable_irq(); // 测试完后记得打开（如果程序还需要运行的话） - 断开调试器：有些调试器会在后台进行通信，占用总线资源，可能轻微影响性能。最好将程序烧录后，脱机运行并测量。
8.3 注意电源与去耦
当GPIO以极高频率翻转时，尤其是驱动容性负载，会产生较大的瞬态电流。如果MCU的电源去耦不好，可能会导致电源电压波动，甚至影响MCU内部其他电路的稳定工作。务必确保在MCU的VDD和VSS引脚附近有足够且合适的去耦电容（通常为100nF陶瓷电容，并可能并联一个10uF的钽电容）。
8.4 测量引线要短
测量高频信号时，长的探头引线会引入电感、电容，导致信号失真、振铃（ringing）等现象，使你测到的上升沿变慢，波形变形。使用探头配套的短接地弹簧，而不是长长的鳄鱼夹地线。
8.5 不同STM32系列的差异
本文的例子多以STM32F1/F4为例。对于其他系列如STM32G0（Cortex-M0+）、STM32H7（Cortex-M7），原理相通，但细节有异：
- GPIO寄存器名：可能略有不同，如有些系列用
GPIOx_BSRR，有些用GPIOx_BSRRH和GPIOx_BSRRL，需查阅对应参考手册。 - 最大输出速度：不同系列的GPIO支持的最高速度不同。H7系列的“Very High”模式可能比F4的更快。
- 总线架构：高性能系列（如H7）有多层总线矩阵和缓存，访问速度更快，但配置也更复杂。
8.6 一个常见的误解：翻转速度等于系统时钟
经常有人问：“我的MCU是72MHz，是不是GPIO就能翻转72MHz？” 这是一个误解。72MHz是CPU核心的时钟频率。执行一条指令至少需要一个或多个时钟周期。完成一次GPIO翻转的“读-修改-写”操作，至少需要几条指令。因此，纯软件翻转的频率远低于核心时钟。只有使用硬件定时器，才可能输出接近定时器时钟频率一半的方波（因为方波周期至少需要两个定时器时钟周期，高电平和低电平各占一个计数）。
