年底了，該總結這一年的收穫與失敗。
今年主要做的乙個專案是p500.並負責其中的nandflash模組。
nandflash：一種儲存晶元。p500支援將系統檔案燒錄到該儲存晶元中。nandflash由於工藝的原因導致本身在燒錄過程中不穩定，燒錄的資料易發生位翻轉。或者某個區域極其不穩定的現象。所以就需要在燒錄的時候有ecc進行校驗，還有bbm（俗稱壞塊管理）進行管理區域極其不穩定的塊。（塊是nandflash本身能夠管理的區域的最小單位）。
初始狀態：
1、我加入這個專案組的時候，專案組的其他成員，其他模組已經做得差不多了。
2、我對這個nandflash模組的需求很不清晰。
3、加入該項目的時候手上還有另外要維護的專案跟要進行技術支援的手持機相關東西。
自己在這個專案中角色的融入過程：
1、因為對這個專案的需求不熟悉，對框架也不是很了解。所以剛開始的時候也不知道從**下手。但是該項目的老大說：你先把燒錄nand的流程編寫出來。其他就很簡單了。但是我發現我根本沒辦法寫出該流程。現在回想起來應該是我考慮的太多了：簡單流程就是簡單流程，就不去想其他的東西了。
2、因為該模組要依賴的東西有：匯入的要燒錄的檔案模組、描述nand晶元的資料庫和要燒錄到晶元時，通過的中間層（時序介面）。而跟我配合開發的時序人員（對nand的業務很熟悉）一直沒空，當然也有我個人的原因：就是不會很主動的去問該如何操作。這個我應該要改的地方。初到專案組，在需求不懂，業務不清楚的情況下，還不敢死皮賴臉的去問。所以導致的問題是：資料庫我根本沒有通過規範文件來製作（本應該由時序人員來進行製作的，後來卻變成了乙個生手來完成這個操作，當然了這樣的結果導致了資料庫在描述晶元資訊的時候，描述的亂七八糟，雖然晶元資訊都有了）。然後時序介面的底層，也是由我跟我老大還有另乙個同事來除錯，而不是由真正的那位懂得時序的人員來進行編寫跟除錯。最後導致的結果也是該時序的除錯過程進行的很慢。
3、對nandflash的資料結構，定義的很不合理。首先：我參照了另乙個nandflash的燒錄平台（6000f）的資料結構的封裝方式進行編寫資料結構，然後學6000f的訪問資料的方式進行訪問。對於我的這個愚蠢行為我只能無限的自責。關於對自己的該行為進行愚蠢的描述得追溯到我一直在維護這個6000f軟體。當維護該軟體時，我一直在吐槽該軟體的設計者，為何會設計出如此低劣的軟體時候。回過頭來我竟然去參照了該軟體的資料結構的設計方式跟訪問方法。以至於最近我還在無限的自責，為此已經從上週開始天天自己加班或者週末自己去辦公室進行修改資料結構的設計方式。
關於資料結構的封裝，在我看來資料結構是怎樣的，作為使用者應該不需要去關心，使用者需要的只是獲取該資料的介面。而不是直接去讀取資料庫的資料（導致耦合性非常大）。然後讀取跟寫入檔案的方式也不應該直接操作底層的介面，作為使用者，應該能夠做的只是把資料扔給指定的寫入介面。這樣不管底層資料庫的結構如何改變，使用者層都不用去更改相應的**。關於這次的失誤，其實給根結底是我對該nandflash的需求還不夠清晰，而導致了只能完全依賴老軟體的設計方法，然後自己在加以改良的時候卻只是修改了一點點，沒有做到徹底的修改。
4、對介面的設計，起初邏輯跟介面耦合度太大了。由於時間太趕，而自己也沒想太多，直接進行編碼。可以說是自己編寫的太隨意了，雖然在指定的時間內完成了功能。但是因為介面總是需要修改的，而導致了相應的邏輯也相應的進行了修改。並且在設計該介面的時候，該項目的老大給的介面設計的建議跟跟我配合的時序人員給的建議完全不一樣。而我卻沒有一點的主見，剛開始聽從老大的建議寫了一套。後來時序人員完全不滿意，然後又重新寫了一套。最後，搞得自己的心特別累。關於這個，具體我應該聽誰的，更應該是時序人員。畢竟他對nandflash的業務比較熟悉。但是在我跟他熟悉之後，我發現乙個特點：因為時序人員不是寫軟體的，所以對軟體的一些概念很不熟悉，有些功能其實應該捨棄的，因為那些功能對大部分的客戶根本就不會用到。在幾千個客戶中，也許就那麼一兩個客戶會用到，並且對於這兩個客戶，和增加的軟體設計複雜度相比投入成本是過大的。當然後來某些功能還是直接放棄了，但是中間被他影響而導致邏輯設計上更加複雜了。當然，這個也不能怪他，畢竟他要的是該軟體是萬能的，什麼客戶都能支援，但是有這樣子的軟體的話，那很容易就可以想到研發成本會提高多少。只能說我自己經驗還是太少了，不懂得去評估跟取捨。所以如果有下次跟別人一起做軟體的時候，對於功能的實現，需要進行一定的評估。
5、對燒錄流程的設計，其實到目前為止還是一團亂。關於燒錄流程，我這裡一直在修改。我發現了乙個問題：我沿用了我最初的簡單的燒錄的方式。雖然循序漸進的進行迭代了好幾次。但是都沒能走出那個最初燒錄方式的那個怪圈。一直在最初的版本上面進行修改。並且過早的考慮該nandflash的速度問題。而導致剛開始的設計過於複雜。
如果現在讓我重新設計燒錄介面的話：我會將各個燒錄方式進行相應的模組化，而不是在位元組中進行每個位的計算，異或等操作。這樣的操作沒過幾天就差不多忘記到底這些異或或者位計算是什麼意思。又或者迷惑了自己。
6、對於外掛程式（bbm或者ecc）的操作介面，做的還不夠合理。雖然相對來說已經夠簡單了，但是為了使用者的使用方便，我設計的太過複雜。
總結：0、在拿到乙個專案之後，應該要至少廣泛的了解該專案要做成什麼樣，需求大致是什麼樣子的。哪些點需要注意，哪些點需要捨棄。
1、對於不熟悉的業務，一定要主動去諮詢，對於是別人的工作一定要強烈要求對方去做，否則自己做完的結果是：吃力又不討好。
2、在參照別人的**的時候，覺得設計的不好的時候，需要重新以自己的思路去思考考如何設計。而不是想著怎樣在別人的基礎上修改的好一點（這樣子的結果導致了最終設計出來的其實跟別人**的思想幾乎一樣換湯不換藥）。
3、對於做任何操作的時候，決不能讓客戶**操作底層，一旦涉及到底層了，說明設計的有問題了，需要修改對應的設計方案。
4、對於覺得迭代了好幾次都沒設計好的，最好捨棄，重新設計。否則最終會引發更嚴重的問題。也導致了使用者無法對該**進行閱讀跟修改。
5、關於重構：覺得設計不合理的地方一定要馬上去重構，而不是說要等到把這個專案做得差不多的時候再進行相應的修改。這樣會導致專案很危險。設計不合理馬上重構。
收穫：1、有了一定的工程概念。也有了一些的專案經驗。
2、學到了一些新的技術（學到的技術最多的是來自專案）。
3、知道了需求的重要性。
4、學會去取捨一些東西。
5、一定要去看重構這本書。這本書不只是維護人員需要看，編寫**人員也需要看。因為編寫軟體就是一直在重構的過程。
ps：c++的技術其實自己該學到的其實也差不多，雖不敢說精通，但是好歹也算是熟悉了。但是專案經驗缺很欠缺。從做這個p500的專案就可以看出來。
憶龍2009 iMC iCC配置下發失敗的常見原因
icc配置管理中心基於snmp和tftp兩個協議，對於配置備份或配置下發失敗的問題，可以從這2個方面入手，常見原因有 1 icc需要裝置的寫引數，正確配置snmp的讀寫引數。2 配置的傳送依靠tftp協議，保證裝置與imc伺服器的tftp埠 udp 69埠 通訊正常。3 對於v5平台的裝置，imc下...
NAND Flash的驅動程式設計
摘要 以三星公司k9f2808uob 為例，設計了nand flash與s3c2410 的介面電路,介紹了nand flash在arm嵌入式系統中的設計與實現方法,並在uboot上進行了驗證。所設計的驅動易於移植，可簡化嵌入式系統開發。引言當前各類嵌入式系統開發設計中，儲存模組設計是不可或缺的重要方...
nandflash的啟動原理
大部分arm9的cpu內部都整合有乙個sram，sram是英文static ram的縮寫，它是一種具有靜止訪問功能的記憶體，不需要重新整理電路即能儲存它內部儲存的資料。這樣他不需要初始化就能夠直接使用。這與我們在外部擴充套件的大容量的sdram是不一樣的，外部大容量的sdram是需要初始化後才能使用...