今天跟大家分享一位嵌入式工程師的項目開發感悟，寫得非常的接地氣，學習和開發過程可以進行相應參考！自從我（原作者）去年被調到了嵌入式組，終于和以前研究生階段搞的開發經歷一致了。

但以前用的是ADS工具，還有用Linux平臺上的交叉編譯工具鏈，還有看linux 內核的驅動代碼。

現在搞起對日外包了。日本人不愛用linux，凡事總是搞出自己的一套。現在用的ut-kernel（看成一個RTOS就好）， 開發工具則有RVDS，DS-5，MTK和IAR， 硬件調試器有Dstream， Realview ICE。現在對應的是富士通半導體部門，做的MCU（基于arm cm3，cm4， ca5核的富士通芯片） 的軟件開發測試。

本來自己的想法是搞搞嵌入式，熟悉下硬件東西，這樣可以加深的我的底層編程功底。

以下是幾個階段的工作感悟：

1ut-kernel/FA5 測試修復BUG工作：

日本人做的ut-kernel屬于嵌入式RTOS范疇，這塊同類的產品有uc/os， vxworks等，共同特征是高度可裁減，想塞到片內那有限的容量內。還有實時性好吧。實時性不僅表現在可搶占式進程調度，還有快速響應中斷的能力。

RTOS的設計畢竟和通用操作系統（linux）的設計思想還是有很大的差別的。感覺這個領域更適合微內核結構的發揮，宏內核結構如linux可裁剪性方面是個缺點。這個ut-kernel算是代碼量比較簡單，里面的修復BUG工作我覺得也不難，期間有timer相關的BUG，最后一看發現timer相關的代碼根本沒改造。

印象深刻的是后期做性能測試，對FA5和FM3芯片做比較時，因為兩個各基于Cortex-m3和cortex-a5架構，架構不同，發現這里面還是很有意思的。一開始FA5的性能沒有發揮出來，找到原因，cache沒打開。高檔次的CPU是要靠cache發揮威力的。

于是查找芯片手冊，正確地初始化了cache并打開它。后來又發現還有些功能如指令分支預測等這些也得打開，于是又修改了相關寄存器。完了，感覺FA5的性能比以前好了很多。于是對CM3和CA5的架構差別方面，我又充滿了興趣。我覺得知道這些，對以后并行多核程序開發，物聯網領域的一些東西都有幫助。

感覺FA5這種檔次高的芯片應該用到手持設備開發中去。那些工控級別的應用應該是FM3這類51單片機取代者的天下。ut-kernel是配著FM3芯片開發的，感覺配上FA5的話，ut-kernel架構就應該進行大改變了，或者直接用linux等內核比較好。

期間做了個初始化外接的DDR芯片工作，我們直接從UBOOT社區那邊拷過來該芯片的初始化代碼。然后針對該代碼做成一個具有初始化DDR單一功能的AXF可執行文件。以此來方便我們測試。還有測試中間差點鬧出來一個大問題，當時日方客戶見我們的初始化DDR代碼中還殘留有GPL版權信息，他們大怒，拷貝代碼慣了，對版權從來沒怎么看重。日本人對這塊比較看重，聽說在日本下載盜版音樂好像要被起訴。

下來經過這場事，我們對版權方面的東西特別敏感，搞好代碼后，首先要在代碼包中掃描版權信息。

2micro.NET framework 在FM3平臺上的移植

這個項目做起來還是非常有發展前途的。看看現在物聯網炒得多么火熱就知道了，可惜做了不到一半，日本人就給咔嚓掉了。不是我們做的不好，而是他們又想讓我們做別的是事情了。做對日外包就是這樣，沒自主權，得按別人指令辦事。這個項目的做的過程中，終于我對串口，timer，GPIO移植熟悉了很多，自己也做了些特性改造。而且我也會根據開發板的板子布線原理圖以及芯片手冊來寫一些簡單的驅動代碼了。

還有對scatfile，分散加載也熟悉了很多，對于MDK， RVDS，DS-5調試工具以及ICE，Dstream等硬件調試器的靈活運用也掌握了不少。

3ut-kernel/M3及M4F的測試

我親自參與并熟悉了怎么在片外再擴接一個SRAM，因為我們的測試代碼體積還比較龐大，無法放到片內中。想想自己以前本科學電子的，那時對示波器，萬用電表掌握的特別熟練。現在卻全部都忘完了（因為后來一直都搞的是純軟件）。

看到項目組同事在使用示波器時，我想到自己還是有基礎的，快速學習能力還是有的。因為做驅動開發，不可避免要用到示波器等這些設備。可惜當時外接SRAM硬件并沒多大問題，而且示波器等還是借的，所以我沒太多機會熟悉這些硬件測量設備。

想想自己本科數字電路，模擬電路等一些硬件課程，實驗課程都學的不錯的。哎，如果我這些功底都恢復并加強的話，那么自己的底層軟件編程也會加強不少，最主要的是編程視野也會相當開闊。畢竟最高層的軟件算法分析設計，我研究生階段都掌握了。沒事以后會有機會繼續窺探到這一領域的。

可惜外接ram又不穩定，后來我們又不得不移到片內進行測試。這時為了能把程序放到片內去跑，就要對ut-kernel里面占用內存空間的地方進行剪裁了，好在ut-kernel都是可裁剪的，在我們裁剪完之后，發現放到片內ram中測試比片外ram穩定多了。還有對嵌入式系統的軟件BUG調試也有所掌握，感覺嵌入式里面的軟件調試時，發現東西跑飛了。

這時可以有多個途徑查找。也許是沒禁掉看門狗，或者那些pend_sv中斷在內存中根本沒有初始化正確， 或者中斷向量表被沖掉了，或者對照著匯編指令看看寄存器狀態有沒有正確。要卡住出問題的地方來進行多方面原因的判斷調查。另外也要結合map文件，看看地址鏈接和加載得是否都正確，有沒有越界。

在測試M4F FPUT時，曾經發現一個詭異現在，一些調用子函數換個先后順序去執行時，就崩潰了，再換過了就不崩潰了。這時我調查了下，發現崩潰前代碼執行時用的棧遭到了破壞。

具體我往前推，發現在調用某個API返回之后，就會破換掉待返回的正確棧上的值。具體再調查時，發現是執行某條匯編指令時，棧遭到了破壞。不過這時候這個調查上面中止了，事情實在太多了又去做其他事情了。不過我相信只要掌握了方法和本質，這些問題都只是時間問題。
編輯：lyn