hhuysqt

很多人开发C程序就像写脚本那样，查错，靠的是眼睛看；但是作为系统开发程序员，bug单纯靠看是查不出来的，于是就用printf，于是每一次查错都不可避免要机械地写printf、编译、烧写、运行，没有IDE的时候烧写、运行还不太方便。如果能在命令行下面设断点、单步调试什么的，想必是极好的。 有时候开发一些程序还不得不在Ubuntu下弄，比方说国外的不少开源项目像px4、openmv之类的，又比方说Linux、nuttx之类的系统开发，等等。当然诸如Eclipse之类的IDE配置一下也能聊胜于无，但是配置它们的复杂度不亚于在命令行下面弄，而且连接板子、开gdb server这些工序只能在命令行下完成；好处是调试时候能用鼠标操作。 其实，命令行下面用gdb调试，熟悉基本命令之后，用起来相当顺手；在TUI模式下面调试，视觉效果不亚于使用IDE。 需要安装的软件gdb包管理装就行： $ sudo apt-get install gdb-arm-none-eabi 当然也可以选用别的，比方说 arm-uclinuxeabi-2010q1里面就有arm-uclinuxeabi-gdb。不过这个的TUI有问题。 SourceForge的uclinux下载页面（崩掉了） 阅读全文…

交叉编译的常识制作交叉工具链，会涉及到三个架构的机器： build，哪个机器制作的这个编译器 host，哪个机器将运行编译器 target，编译器生成代码将会跑在哪个机器上 如果build == host == target，就叫native编译器。这是最正常的情况。如果build == host != target，就叫cross编译器。这就是常规意义下的交叉编译器。如果build != host != target，就叫canadian编译器。据说在社区讨论这种情况的编译器时候，加拿大国会有三个党，于是就这样开玩笑了。。。这种情况一般用在Compile farm里面。编译农场或许就是一堆树莓派，它用来编译不同架构的软件包，制作这个编译器的或许就是某台高性能的x86机器。 其他情况也有不同的叫法，参考这个回答 对于Cortex M，有哪些工具链可选？ optimize-uclinux这篇报告第34页简述了一些可用的编译器。 Bootlin（以前叫Free electrons）公司收录了一堆常见CPU架构的不同版本的gcc工具链。不过armv7-m的工具链貌似不行。 社区推荐的arm2010-q1工具链有很强的可用性。 arm官方维护的亲儿子gcc-arm-none-eabi可用用来开发裸机程序，基本没bug，适应的CPU又多。 包管理可用安装gcc-arm-none-eabi工具链，不过版本略旧与arm官网的gcc。 自己动手做arm-none-eabi或者arm-uclinuxeabi工具链。 阅读全文…

用哪个BSP？ST为他们STM3210E-EVAL的评估板制作了uClinux-dist-20080808的补丁。bootloader是一个莫名其妙的bin，kernel和rootfs放在片外nor flash里面，并且带有jffs。官方评估板又贵又买不到，不过我手上一块淘宝上一百多块钱的相似配置的板子也能玩。shell跑起来太慢了，跑个ls都要卡一两秒。 Emcraft为一些ST的板子做了第三方的BSP，其中包括STM32F429I-disc的uclinux BSP。虽然是给STM32F4板子写的，但是它里面也包括一些STM32F1的驱动，比方说USART、DMA。做一些修改还是可以用的。这份BSP血统比较纯正，用uboot作为bootloader，uclinux内核单独抽出来编译，应用程序用的busybox，包装为ROMFS的镜像。这些东西全部都在片内flash里就地执行，性能颇高，在429 discovery板子上跑的很欢快。 既然要build it from scratch，那就应该好好研究Emcraft的BSP，好好学学社区的玩法吧。github上有一个makefile，从头开始为429 discovery编译所有东西，它从robutest的仓库里面下载的uboot和uclinux，我猜Emcraft的东西来源也是这个，因为里面的驱动感觉是一样的。 首先在我买的板子上跑通整个系统，然后再移植到自己的板子上。别人的板子配置颇高，有2MB的片外SRAM跟4MB的片外NOR flash，还有64MB的nand flash，完全可以跑通。我的板子只有1MB的SRAM，加上一个256MB的nand flash；配置之所以那么诡异是因为我芯片只能淘宝。。。 阅读全文…