标准输入输出与 MicroLIB：C 语言的终端去了哪里

我以前在电脑上写 C，调用 printf() 以后，总能在黑色的终端窗口里看到文字。那时我几乎不会想到一个问题：文字究竟被送到了哪里？

换到单片机后，这个问题突然变得明显。代码可以成功编译，也可以成功下载，可是 printf("hello\n"); 没有任何地方显示 hello。如果再试着用 scanf() 读一个数字，程序甚至像是停住了。

这个时候，printf() 和 scanf() 还在，电脑上那个现成的“终端”却没有跟过来。要理解这件事，得先把“函数”和“通道”分开。

电脑上的终端不是 C 语言自带的

在电脑上运行程序时，操作系统会为进程准备输入、输出和错误输出。键盘输入被接到标准输入，普通文字被接到标准输出，错误提示通常被接到标准错误。终端窗口只是操作系统安排好的一个去处。

所以这段代码真正表达的意思不是“把文字画到屏幕上”：

printf("speed = %d\n", speed);

这更像是格式化一段文字，然后把这段文字交给标准输出通道。至于通道另一端是终端窗口、文件，还是别的程序，由运行环境决定。

scanf() 也是同样的道理：它没有直接从键盘读取变量，而是尝试从标准输入通道获得字符，再把字符解释成数字或文字。

这层区别在电脑上不明显，是因为操作系统已经替我们把通道接好了。单片机没有这样的默认安排，于是“通道接到了哪里”必须被单独考虑。

单片机里的三个空房间

可以把 stdin、stdout 和 stderr 想成三个房间的名字：

• stdin：程序从外部接收文字的入口；
• stdout：程序发送普通信息的出口；
• stderr：程序发送错误或异常信息的出口。

单片机程序启动时，没有操作系统替它把 stdout 接到显示器，也没有键盘自动接到 stdin。就像是房间名字已经存在，不代表房间里真的有门。如果没有人为安排出口，printf() 仍然可以参与编译和链接，但屏幕或终端未必能收到任何文字。

这也是为什么“调用成功”和“看见输出”是两件事。前者只说明程序执行到了这个调用；后者还要求通道后面确实有一个能接收字符的设备，以及电脑端有一个正在等待这些字符的工具。

直接调用 printf()，可能发生什么

第一次接触单片机时，最自然的尝试通常是：

#include <stdio.h>

int main(void)
{
    printf("hello\n");

    while (1)
    {
    }
}

这段代码有几种常见结果。

第一种，编译器报告相关函数或底层入口没有正确处理。printf() 当然能放在单片机里，问题在于工程还没告诉 C 运行库“字符应该送到哪里”。

第二种，程序能下载，但没有任何可见文字。此时标准输出只是停留在一个没有接收者的通道里，LED 也不会因为 printf() 自动亮起来。

第三种，程序运行到输出位置后停住，调试器提示半主机或调试相关信息。半主机可以把单片机的输入输出请求交给调试器，再由电脑显示出来；它适合做早期观察，却依赖调试连接。程序脱离调试器独立运行时，这条路就不再可靠，甚至可能让程序等待一个永远不会到来的回应。

所以“能在调试器窗口看到文字”不等于“单片机已经拥有了终端”。那只是调试器暂时替它接了一扇门。

把出口接到一个真实去处

嵌入式工程常见的做法，是把标准输出的字符逐个交给一条已经接好的通信通道，再由电脑端工具显示出来。抽象地看，链路是这样的：

printf()
    -> C 运行库整理文字
    -> stdout
    -> 工程提供字符出口
    -> 外部通信线
    -> 电脑端终端工具

最后三步经常被混在一起。stdout 只是标准输出通道，通信线负责传字符，终端软件再把收到的字符显示出来。工程需要提供一小段“翻译代码”，把标准输出中的一个字符交给实际的输出设备；电脑端也要打开对应工具，才能看到这些字符。

看到 printf() 没输出时，我会先查三个地方：标准输出有没有出口，出口后面有没有真实连接，电脑端有没有正在接收的工具。格式字符串反而放在后面查。

scanf() 为什么更容易让程序像死机

输出没有接收者，常常只是“看不见”；输入没有提供者，则可能让程序一直等。

int value;
scanf("%d", &value);

它要从 stdin 取字符，直到这些字符足够组成一个整数。如果单片机没有接好输入通道，或者电脑端没有发送符合要求的内容，函数就可能一直等待。

这会带来几个很实际的后果：

• 主循环暂时不再向下执行；
• 其他本来需要及时处理的工作得不到机会；
• LED、屏幕和控制动作可能停在上一次状态；
• 你看到的现象像“程序死机”，实际只是程序在等输入。

scanf() 也不是完全不能用，只是它默认假定终端前一直有人输入。小车或传感器程序通常不能把核心工作交给一个没有期限的等待，我更常见的做法是自己接收字符、判断一行是否完整，再决定是否更新参数。

stderr 不是自动出现的第二块屏幕

在电脑上，标准输出和标准错误有时可以显示在同一个终端窗口里，也可以被操作系统分开保存。它们的区别是“用途不同”，不是“必然对应两块屏幕”。

单片机里更不能想当然地认为 stderr 会自动跑到另一个地方。没有额外安排时，它可能和普通输出共用一条通道，也可能根本没有可见结果。把错误信息写到 stderr 不会自动点亮故障灯，也不会自动保存日志；还得给这些信息安排实际的观察方式。

MicroLIB 到底改变了什么

如果说标准输入输出是在问“文字从哪扇门进出”，MicroLIB 问的是“负责这些事情的那套 C 运行库有多大”。

完整的 C 运行库要照顾电脑程序的许多需求：文件、环境、地区格式、复杂的输入输出和更多通用功能。单片机往往没有文件系统，也不需要这些完整设施。把整套库都带进一个只点灯、读按键的程序，会占用本来可以留给业务代码的空间。

MicroLIB 就是面向这种场景的精简选择。它通常带来：

• 更小的程序体积；
• 更少的运行时内存占用；
• 更适合裸机程序的启动和运行环境；
• 足够使用的常见 C 语言函数。

某些完整库功能、文件相关能力、复杂格式化能力或边界行为可能有所不同。开启 MicroLIB 后，工程仍然要明确标准输入输出的出口；它不会替你把 stdout 自动接到某条通信线上。

可以把它理解成搬家时选择一套小户型家具：常用的桌椅都在，房间更省空间；不常用的大件没有全部搬来。选小库还是大库，要看当前程序需要哪些功能，以及能不能接受缺少的部分。

stdio.h、reg51.h 和 STM32 标准库分别是什么

#include <stdio.h>

写下它，和“终端”塞进单片机不是一回事。stdio.h 只是 C 运行库提供的头文件，它把 printf()、scanf()、stdin、stdout 等名字和函数声明告诉编译器。真正的输入输出能力，还要由 C 运行库和工程提供底层出口。

reg51.h 是 51 单片机常见的芯片头文件。它把某一型号芯片的寄存器地址、位定义写成 C 语言可以使用的名字，例如定时器和 IO 相关寄存器。换成 STM32 后，芯片的寄存器布局不同，自然不能继续使用这份头文件。

STM32 标准外设库做的事情更完整：除了寄存器定义，还提供了 GPIO、定时器、ADC 等外设的结构体、宏和函数。调用库函数时，程序仍然是在读写芯片寄存器，只是把寄存器的细节整理成了更容易阅读和复用的接口。

没有这些头文件和库文件时，程序仍然可以运行。你可以自己声明变量、自己写函数，甚至直接按芯片手册里的地址读写寄存器；编译器也仍然会把 C 代码编译成机器指令。只是所有名称、地址、位掩码和初始化步骤都要自己维护，写错一个数字就可能把整个外设配置错。

包含它们以后，程序多了三类东西：编译器能够检查的声明，代表寄存器和位的符号名称，以及已经写好的底层操作函数。它们省下的是重复劳动和记忆负担，芯片本身的能力并没有因此增加。库文件最终仍会被编译、链接进程序，程序大小和执行时间也要算在工程成本里。

为什么 printf() 会让程序突然变胖

printf() 看起来只输出一句话，背后却要处理格式字符串、整数转换、宽度控制、填充和字符发送。如果再加入浮点数格式化，运行库还要处理小数、指数、舍入等更多工作。

因此，一个只增加一行调试输出的程序，程序体积和运行时间都可能明显增加。输出本身还要逐字符送出，通信速度有限时，发送一长串文字会占用主循环的时间。

这解释了两个常见现象：

• 调试信息越多，程序越大，剩余空间越少；
• 打印越频繁，程序越容易错过本来应该及时处理的事情。

所以 printf() 是观察工具，不应该被当成没有代价的普通赋值语句。调试阶段可以让它帮助我们看见程序；稳定运行时，则要决定哪些信息值得留下、多久输出一次，以及输出会不会改变程序本身的节奏。

浮点数为什么要单独确认

以后在观察速度、角度或滤波结果时，很容易写出：

printf("angle = %.2f\n", angle);

这行代码能否按预期显示，取决于当前 C 运行库和工程选项是否包含浮点格式化支持。即使普通整数输出正常，也不能据此断定浮点输出一定可用；即使编译通过，也要确认输出内容、程序体积和运行时间是否能接受。

因此，浮点打印应该作为一个明确的工程选择来验证，而不是在任意位置顺手加上 %f。后续工具文章会单独说明如何配置和验证浮点输出，以及什么时候应该改用放大整数、分段输出或其他更轻量的表示方式。

最后橘猫说

在电脑上，终端像空气一样存在，所以我们容易把 printf() 当成“显示文字”，把 scanf() 当成“读取输入”。到了单片机里，原本被操作系统藏起来的关系终于露出来：标准输入输出只是 C 语言约定的通道，必须接到真实的去处，文字才会出现；没有输入时，读取函数可能一直等待；MicroLIB 负责控制运行库的大小和能力，却不负责替你设计输入输出的路线；调试输出也有体积和时间成本，观察程序时可能反过来影响程序。

以后再看到“编译成功但没有输出”或“加了一行 scanf() 就像死机”，不要只盯着函数名发愣，先问一句：这条通道是谁提供的，另一端是谁，程序有没有机会从等待中回来。

最后蜘蛛说

搬了新家，没有给它开窗，printf() 喊半天也没人应它QAQ