本文共 1040 字，大约阅读时间需要 3 分钟。

通过CMSIS-utrealos项目中的CTBUG调试，使我对裸机C编程加深了认识。那个BUG调试，现象是出现hard fault，但是fault出现地的汇编指令看着貌似没啥问题，解决一处的fault后，其他处又出现fault了。最后我看到原来是fault出现地的指令中源地址错误了，源地址应该在数据段中，却意外地落到了代码段中。这个现象我忙活了半天才找到。

然后通过看那奇怪的源地址，对照它四周的现象代码，最终才发现是我的demo C文件中的头文件包含错误了（这个错误显然易见，但是在review代码时却没发现）。导致该问题指令的那个源地址计算错误，落到了代码段中。

调试时间花了不少，最后这段调试经历使我对裸机C编程发生了兴趣，从而认真读了armcm3编程权威指南一书。

还有王SAN那个栈溢出调试，王SAN本来还想研究是否是内存分配方面的错误，但是和我最后讨论后，结果用arm权威指南及我们组项目笔记文章中的那个栈溢出调试方法，很快就找出BUG原因了。

我的那个BUG调试告诉我ARMCM3上没有MMU那种保护功能，也没有操作系统（linux操作系统中的那种开启MMU保护以及虚存访问权限检查的功能这里没有）。虽然有MPU，但是这个是可选器件。

linux下的MMU及虚存保护，使得我们PC机编程中，可以不用C指针时，及时将其置为空从而起到保护程序的作用，但是回到裸机下，尤其没MMU部件时，空指针的作用意义在这里都消失了。这也就是嵌入式编程的复杂性。

但是通过嵌入式编程，尤其王san那个BUG调试，毕竟能加深对C编程底层调试的认识。比如现在嵌入式调试，可以直接通过观看内存地址处的数据信息是否异常，各个汇编指令和cpu寄存器值变化是否异常，嵌入式调试使人真正回到了二进制时代。

不可否认，MMU和虚拟存储的设计，真正简化了上层程序的设计，提供给用户一个好的开发应用程序的界面。详情见uclinux与linux的不同一文。

但是由于MMU的存在必要，这延缓了CPU访问内存的速度。为了解决这一问题，又带来cache，还有TLB（之前作linux性能检证搞过TLB的性能分析一文可以参考）。而ARM CM3中没有这一切，毕竟cortex-m3和A5的应用范围是不同的。CM3和CA5的设计架构比较可以见我的邮件performence difference caused by cache on Cortex A9 platform and Cortex M3.eml

未完。

转载地址：http://purvb.baihongyu.com/