一定会有人问，裸机C不是比RTOS更简单么?我问你，如果只是点个灯，用C简单还是用汇编简单?你也许会毫不犹豫地回答，用C简单。为什么呢?因为开发工具已经完成了大量的工作，有厂家的固件，完成GPIO的驱动，IDE自动生成的代码，完成了main函数之前的大量环境初始化工作。所以，你只需要3分钟，在main函数里放一个循环改变GPIO状态的代码，一个C语言的闪灯程序就完成了。事实上，如果从0开始做，汇编完成闪灯，不知比C简单多少倍。

　　裸机C取代汇编语言的过程，正在裸机C和RTOS编程之间重演着，不信么?我出个“简单”的题，写一个“hello world”的嵌入式程序看看。

　　很快，你写出来了，UartSend(“Hello World”);

　　别急，我的题还没出完呢，我需要输出“你好，欢迎你第xxx次光临”。

　　这就难一些了，聪明的，就写一个MyPrintf吧，谁知道这道题还有什么变化呢(注意这里，你不能用printf作为函数名的，下面有解释)。

　　花了一个星期时间，把MyPrintf弄出来了，效率够高吧?

　　好吧，你牛，I 服了 You，现在请你把输出重定位到板载的LCD上。

　　什么，玩我啊，这涉及到IO重定向呢，爷不干了。

　　光重定向一个输出就不干了，还没有要你把输入重定向一下呢，板子上不是有按键嘛!

　　IO重定向，是C语言的基本要求，然而，在裸机C环境下，这个基本要求，却让一个裸机C高手望而生畏。

　　IO服务，只是一个基本需求，它只是C Runtime的一部分，而C Runtime，是IoT开发所需要的进阶工具的基础，恰恰是，裸机C都是很难实现完整的、通用的、可移植的C Runtime。

　　先爆点料，绝大多数嵌入式RTOS，都没有fopen、fwrite、fread、printf函数，有部分RTOS会有xxx_fopen、xxx_fwrite、xxx_fread、xxx_printf之类的API，即使是一些老牌的商业RTOS也是如此，这里我就不点名了。

　　没有IO体系的RTOS也就罢了，那些有IO体系的RTOS，为啥要在API前加个xxx呢?你知道加上那个xxx，会给用户添加多少麻烦吗?IoT时代，许多嵌入式软件工程师，原来可能是Windows或者Linux下编程的，他们熟悉c标准函数;嵌入式设备网络化、应用程序通用化的倾向，许多IoT开发会涉及到开源软件或者第三方库，这些开源软件或者库，许多是遵循C语言标准写的，也就是说，里面很可能会大量调用fopen之类的C标准函数。你要用这些开源软件或者第三方库，就必须修改它的源码，把调用C标准IO函数的地方，全部改掉。改就改呗，改了不就行了嘛，有什么大不了的。好吧，如果是二进制的库呢，怎么改?即使是开源软件，维护方升级了，修正了bug，你是不是要再改一次?既然这么多坏处，为啥还要加哪个“xxx”前缀呢?问题就出在标准C库上，因为编译器所带的C库，实现了那些函数，OS如果要自己实现这些函数，就必须先实现C库，而C库，而许多RTOS，并没有实现自己的C库，而是借用编译器提供的C库，自然就不能使用跟C库重名的函数了。