通過CMSIS-utrealos項目中的CTBUG調試，使我對裸機C編程加深了認識。那個BUG調試，現(xiàn)象是出現(xiàn)hard fault，但是fault出現(xiàn)地的匯編指令看著貌似沒啥問題，解決一處的fault后，其他處又出現(xiàn)fault了。最后我看到原來是fault出現(xiàn)地的指令中源地址錯誤了，源地址應該在數(shù)據(jù)段中，卻意外地落到了代碼段中。這個現(xiàn)象我忙活了半天才找到。
然后通過看那奇怪的源地址，對照它四周的現(xiàn)象代碼，最終才發(fā)現(xiàn)是我的demo C文件中的頭文件包含錯誤了(這個錯誤顯然易見，但是在review代碼時卻沒發(fā)現(xiàn))。導致該問題指令的那個源地址計算錯誤，落到了代碼段中。
調試時間花了不少，最后這段調試經歷使我對裸機C編程發(fā)生了興趣，從而認真讀了armcm3編程權威指南一書。
還有王SAN那個棧溢出調試，王SAN本來還想研究是否是內存分配方面的錯誤，但是和我最后討論后，結果用arm權威指南及我們組項目筆記文章中的那個棧溢出調試方法，很快就找出BUG原因了。
我的那個BUG調試告訴我ARMCM3上沒有MMU那種保護功能，也沒有操作系統(tǒng)(linux操作系統(tǒng)中的那種開啟MMU保護以及虛存訪問權限檢查的功能這里沒有)。雖然有MPU，但是這個是可選器件。
linux下的MMU及虛存保護，使得我們PC機編程中，可以不用C指針時，及時將其置為空從而起到保護程序的作用，但是回到裸機下，尤其沒MMU部件時，空指針的作用意義在這里都消失了。這也就是嵌入式編程的復雜性。
但是通過嵌入式編程，尤其王san那個BUG調試，畢竟能加深對C編程底層調試的認識。比如現(xiàn)在嵌入式調試，可以直接通過觀看內存地址處的數(shù)據(jù)信息是否異常，各個匯編指令和cpu寄存器值變化是否異常，嵌入式調試使人真正回到了二進制時代。
不可否認，MMU和虛擬存儲的設計，真正簡化了上層程序的設計，提供給用戶一個好的開發(fā)應用程序的界面。詳情見uclinux與linux的不同一文。
但是由于MMU的存在必要，這延緩了CPU訪問內存的速度。為了解決這一問題，又帶來cache，還有TLB(之前作linux性能檢證搞過TLB的性能分析一文可以參考)。而ARM CM3中沒有這一切，畢竟cortex-m3和A5的應用范圍是不同的。
下載文檔
