挑战用一百个字节写一个闪烁灯程序！

我们使用的硬件是一块STM32跟踪参考板。它非常简单，只有一个STM32F407微控制器、3个LED、一个调试/跟踪接口和一个USB供电端口。

每个J-Trace仿真器交付中包含该开发板，然而，在这里，我仅仅使用常规的J-Link功能下载和调试程序。用户也可以选择任何带LED的硬件测试。

非常简单，打开Embedded Studio开发环境，从菜单中选择File -> New Project，选择第一个选项，创建可执行文件。

根据提示，选择使用默认值，单击next几次后，我最终得到了一个小项目，如下面的Project Explorer窗口中所示。

选择Build->Build Mini或按F7构建我们的程序。

Debug -> Go或F5启动调试器。

我们现在没有连接硬件，所以Embedded Studio要求我们使用内置模拟器。

点击Yes或点击Enter启动模拟器。

调试器停在main()函数处，这是一个标准的 “Hello world”应用程序。

现在，为了实现最小的应用程序，我们将其简化为一个基本上是空的循环。

结果只占用了158字节的Flash。这已经非常不错了，但是在添加实际LED闪烁功能之前，我需要了解内存的占用，以及如何使我的程序最小化。

为了做到这一点，我可以查看Memory Usage Window、链接器映射文件、生成的ELF文件，或者简单地查看Project Explorer。

从Project Explorer窗口可以知道，这个可执行文件由3个源程序文件构成，以及它们使用了多少Code + RO空间。请注意，这些是编译器生成对像的数值。对于最终的可执行文件，链接器可以消除未使用的功能，或者在必要时添加一些结合层代码（从Flash跳到RAM或从Thumb指令跳到ARM指令）和填充（如：保证4字节对齐）。

另一个使用Flash存储器的地方，可能是从库中链接进来的代码，例如：C运行时库。然而，我们的小项目并没有使用库函数，因此我们不必考虑库代码的空间占用。

而且，Project Explorer展示了每个源文件的内存使用情况（2、128和24字节）和项目可执行文件总的内存使用情况：158字节。这和我们在Output窗口中看到的数值相同。

这三个文件的用途？我们的应用程序只是一个简单的main()函数。为什么我还需要另外两个文件呢？

🔹main.c – 应用程序。

🔹C ortex_M_Startup.s – CPU相关代码，包含中断向量表。

🔹SEGGER_THUMB_Startup.s – 应用编程人员不需要修改的代码。

让我们更详细地了解它们，以揭开大家都想知道的谜团：启动代码是如何工作的？

有了这些知识，让我们看看如何缩小我们的应用程序。

main.c包含我们的应用，一个最简单的main()函数。

我们的编译器足够智能。它可以看出这个程序什么都不做，并将其优化为只使用一条指令或两个字节代码的空循环。

我怎么知道的？我们可以看看main.o，这是编译器产生的输出。在Project Explorer中，右键单击main.c->Show Disassembly，或者展开它，双击Output files中的main.o。它揭示了主程序只有一个分支。

这是我们的主应用程序。我们已经没有办法再简化它了。

Cortex_M_Startup.s包含了应用程序在Cortex-M硬件上执行所需要的CPU相关代码。它包含中断向量表和上电或复位时执行的函数：Reset_Handler。

此文件使用了大部分Flash空间。让我们仔细看看它产生了什么。

Cortex_M_Startup.o显示其包含中断向量表 .vectors段及默认的异常处理程序实现。

这就是罪魁祸首。

ARM内核定义了向量表中的前16个表项，然后是设备外部中断的表项。该文件提供了一个有16个表项（或64个字节）的向量表。这些条目仅用于该表。

在应用程序中，我们没有处理任何故障或中断，实际上我们只需要Reset_Handler，这是复位立即执行的代码。我们还需要向量表中的第一个表项，它在复位时完成堆栈指针（SP）的初始化。

因此，我们删除所有不必要的表项，将此表删减为两个表项，同时将消除默认的异常处理程序。

我们重新生成应用程序。不错！现在应用减少为42个字节。

让我们看看输出的elf文件的内容。

从0x0000 0000开始的8个字节：向量表，包含初始化SP和指向Reset_Handler的指针。

从0x0000 001E 开始的8个字节: Reset_Handler，两条4字节指令。链接器插入的一条nop指令，代替SystemInit的调用（在应用程序中不存在），以及一个跳转到_start的指令。

从0x0000 0008开始的20字节：SEGGER_THUMB_Startup.s的通用运行时初始化，它执行链接器生成的对来自SEGGER_init_table的初始化函数的调用，然后，调用main，如果main返回，则停在exit循环中。

从0x0000 0028开始4字节：链接器生成了SEGGER_init_table，

其中包含需要在main之前调用的初始化函数。它可能包含段初始化（复制初始化的数据）、段填充（用于0初始化的静态变量或堆栈的预填充）、堆初始化或全局C++对象的构造函数调用。这些都没有在我们的应用程序中使用。

最后一条（唯一）指令是跳到运行时初始化的末尾，调用main函数。 

加上从0x00000026开始的为对齐SEGGER_int_table的 2个字节的填充，总共是42个字节。

因为应用中没有使用SystemInit功能，所以我们可以删除bl SystemInit语句，并用nop取代，以节省4个字节，并减少到38+2=40个字节。

我们的应用程序已经是尽可能小了。下面我们开始添加闪烁代码！

我们编写了一些用于初始化和控制参考板上LED的代码和一个简单的延迟函数。

有了这些代码，我们就可以创建带有闪烁功能的主应用程序了，如下所示：

完整的源代码工程可以访问（可点击“阅读原文”）：https://blog.segger.com/wp-content/uploads/2020/08/Blinky_Mini.zip

让我们重新构建并检查输出。 

成功了！应用程序的大小只有96个字节（需要使用release模式构建，使用debug模式代码体积会比较大）。

它真的可以运行吗？让我们试一试。我们将电路板连接到J-Link，并将J-Link连接到我们的计算机。按F5键运行它。就像这个项目开始时一样，调试会话开始并运行到main函数，只是这次是在实际硬件而非模拟器上。当我们再次点击F5继续执行时，我们可以看到开发板上的LED0在闪烁。

用C语言写的闪烁程序确实可以放在不到100字节的程序（或者更准确地说是只读）存储器中。

启动代码不需要那么复杂。它只是完成了硬件的初始化（SystemInit的用途）和运行时系统的初始化。

运行时系统初始化由Embedded Studio和SEGGER链接器负责。它确保只包含必要的代码，以使生成的可执行文件尽可能小。

SEGGER链接器还能够包括特定的初始化，例如：在需要的时候，完成堆的初始化和调用构造函数。这些功能是由链接器中的脚本控制。

SEGGER链接器生成的启动代码非常小，并且易于理解。联合高效的SEGGER编译器与模块化的运行库和主机端输出printf()函数，我们就可以傲视群雄了。

看看电脑上简单的“Hello World”程序的大小，也许我们还应该提供一个可以在电脑上生成相同小程序的SEGGER Studio。

你程序还能更精简吗？用你的工具链试试，挑战用100字节写一个闪烁程序！我相信，在同样的硬件上，这将是很难被击败的。

令人惊讶的答案是：是的。

首先：一些微控制器具有切换寄存器，这允许将循环切割为_ToggleLED() / Delay()。

还有，初始化内容需要的代码量各不相同，在其他硬件上可能会更小。

但是即使在相同的硬件上，我们也可以进一步减小程序大小。

我们可以将_start放入向量表中，这样程序就可以在通用启动代码中开始执行，从而节省了4字节的跳转空间。 

我们可以删除exit() 和2字节的分支，因为我们知道main()程序中永远不会返回。 

因为我只想要不到100个字节的程序，所以，让我们到此为止吧。

最后，祝大家编码快乐！