通過CMSIS-utrealos項目中的CTBUG調(diào)試，使我對裸機C編程加深了認(rèn)識。那個BUG調(diào)試，現(xiàn)象是出現(xiàn)hard fault，但是fault出現(xiàn)地的匯編指令看著貌似沒啥問題，解決一處的fault后，其他處又出現(xiàn)fault了。最后我看到原來是fault出現(xiàn)地的指令中源地址錯誤了，源地址應(yīng)該在數(shù)據(jù)段中，卻意外地落到了代碼段中。這個現(xiàn)象我忙活了半天才找到。

然后通過看那奇怪的源地址，對照它四周的現(xiàn)象代碼，最終才發(fā)現(xiàn)是我的demo C文件中的頭文件包含錯誤了(這個錯誤顯然易見，但是在review代碼時卻沒發(fā)現(xiàn))。導(dǎo)致該問題指令的那個源地址計算錯誤，落到了代碼段中。

調(diào)試時間花了不少，最后這段調(diào)試經(jīng)歷使我對裸機C編程發(fā)生了興趣，從而認(rèn)真讀了armcm3編程權(quán)威指南一書。

還有王SAN那個棧溢出調(diào)試，王SAN本來還想研究是否是內(nèi)存分配方面的錯誤，但是和我最后討論后，結(jié)果用arm權(quán)威指南及我們組項目筆記文章中的那個棧溢出調(diào)試方法，很快就找出BUG原因了。

我的那個BUG調(diào)試告訴我ARMCM3上沒有MMU那種保護(hù)功能，也沒有操作系統(tǒng)(linux操作系統(tǒng)中的那種開啟MMU保護(hù)以及虛存訪問權(quán)限檢查的功能這里沒有)。雖然有MPU，但是這個是可選器件。

linux下的MMU及虛存保護(hù)，使得我們PC機編程中，可以不用C指針時，及時將其置為空從而起到保護(hù)程序的作用，但是回到裸機下，尤其沒MMU部件時，空指針的作用意義在這里都消失了。這也就是嵌入式編程的復(fù)雜性。

但是通過嵌入式編程，尤其王san那個BUG調(diào)試，畢竟能加深對C編程底層調(diào)試的認(rèn)識。比如現(xiàn)在嵌入式調(diào)試，可以直接通過觀看內(nèi)存地址處的數(shù)據(jù)信息是否異常，各個匯編指令和cpu寄存器值變化是否異常，嵌入式調(diào)試使人真正回到了二進(jìn)制時代。

不可否認(rèn)，MMU和虛擬存儲的設(shè)計，真正簡化了上層程序的設(shè)計，提供給用戶一個好的開發(fā)應(yīng)用程序的界面。詳情見uclinux與linux的不同一文。

但是由于MMU的存在必要，這延緩了CPU訪問內(nèi)存的速度。為了解決這一問題，又帶來cache，還有TLB(之前作linux性能檢證搞過TLB的性能分析一文可以參考)。而ARM CM3中沒有這一切，畢竟cortex-m3和A5的應(yīng)用范圍是不同的。