对于嵌入式newlib中printf的一个小思考
最近在做一个关于RISCV嵌入式项目的开发,RISCV平台用的是一个picorv32的一个开源小核,代码只有不到三千行,但是功能基本完备,非常适合在FPGA中做一些和控制相关的操作。
为了程序开发方便,我在编译CPU程序的时候,直接使用了newlib来实现一些标准的C库程序,这样虽然程序效率不高,好在常用的C库程序不需要单独开发,我们只需要将我们的精力集中在应用程序开发上就好,并且在程序测试的时候,我们也可以直接在PC上调用本地的标准C库,实现程序测试,对于这部分内容也挺多,基本也可以单开一个很大的章节,这里就不详述了。
其实我遇到的问题是在引入标准C库的时候碰到了,我们知道,一般要实现libc,我们需要重新定义一些系统调用相关的函数,比如针对printf我么就需要实现_write
函数,这个我还是按照之前的写法进行操作,然而我发现我定义了_write
函数之后,我调用printf,输出过程并没有调用_write
函数,当然信息也就不能输出到串口上了。
通过艰难的debug,我发现printf最终调用了一个类似_fake_stdout
的变量上面,这个搞得我有点摸不着头绪,后来找了很多资料才发现这个问题是因为printf的缓存机制导致的。
其实标准库中我们调用printf的时候,printf子函数并不会直接将数据打印到串口,而是会经过一个缓存,重写底层系统调用的时候我们知道,我们要实现一些文件操作,并且对于_write
操作其实也是往文件里面写的,只不过写的目标文件是一个stdout
或者stderr
的特殊文件。所以C库对这些文件进行操作的时候,中间会经过一个缓存,这样就可以避免对文件的多次读写,提高系统的效率,其实是一种非常好的设计。
不过这种设计,对于我们这种小白用户就可能造成一些困扰,因为这个buffer一般是1KB大小,所以我们常常打印了很多字符也看不到,因为我们实际都是写在buffer里面了,除非显示的调用flush或者字符结尾加上\n
,系统才会将这些字符打印到我们的目标文件,也就是串口上。
我在一直过程中就直接写了一个printf("Hello world!")
,就是因为没有加上\n
,所以这些字符全都写到了buffer上。串口完全没反应,中间几度放弃,还好最终找到了这个原因。想想,这个问题其实以前应该也会碰到,不过之前的程序打印的时候内容都比较多,中间都有\n
所以没发现这个问题。
另外针对于这个问题,解决方法一种就是在字符串结尾加上\n
,另一种就是直接把这个buffer关掉,总之要记住这里有个坑就好了。
最后更新于 2020-03-01 03:15:35 并被添加「C embeded newlib printf」标签,已有 6498 位童鞋阅读过。
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。