在以往的軟件開發中，在結構上吃了不少的虧。慢慢的對結構方面逐步重視起來，下面我寫一些關結構方面的認識，希望大家指導批評。這樣在不段指正下成長 方能造就出，可靠性高，移植性強，維護方便的程序出來。
個人感覺，在寫代碼時，盡量做到模塊化。Ucos是個很好的平台，他可以讓所有的功能化分為多個模塊。在其之間有很好的獨立性，就是說只要給你一個任務，就可以完成一個功能。可是任務間有時也會牽扯到數據交互的問題，這個時候就使用模塊接口。別人在加載您的模塊接口頭文件時后，所有的數據都可以通過接口傳遞了，這樣塊的封裝就可以做的非常獨立。這樣在功能的刪除和增加會變的很簡單。不用再為兩個模塊 重復的枚舉，宏而擔心。因為所有的變量，都是本地的（靜態的）。嘿嘿，本地模塊是你的，你就可以隨心所欲。當然在保證編程規范的前提下。最主要的是接口函數，要清晰明了。別人看一眼也大概是什么功能，就很到位了。
到這里，就不得不說下在用ucos整個軟件的層次了。筆者以往是采用四層的方式，硬件相關層，驅動接口層，應用接口層，應用層。好的分層會讓軟件開發相對獨立化，分工同步進行。下面是以前找資料看到的結構，感覺很不錯。
所有的硬件被抽象化，應用層的程序，基本上不用再考慮硬件的問題，也就是說，在硬件完全更換的情況下，只要硬件相關層被更新，完全可以等同原先的所實現的功能。這樣就極大成度上方便了移植。要做到完全的划分，下面逐步對這幾層做一個說明。
硬件相關層：在這層中，要盡量所有硬件相關都囊括在其中。不管是GPIO還是定時器，或串行接口。只要提供標准統一的接口，就可以讓上層會因此而變的很瀟灑。這其中有三個最為重要的接口Open,Close,Ctrl。 Open主要來完成對應硬件初始化，形參中包括了些，初始化的相關參數。Close失能硬件。Ctrl來實現一些控制的修改如：優先級，中斷回調函數等等，硬件的不同，內容也大為不同。
驅動接口層：其實在上一層也算是驅動層，只不過因為硬件相關，而把他分離。這層中會用到一個或多個硬件層的接口，進行組合來實現特定功能的程序。這部分程序可舉例進行說明。以Flash為列，它這里主要調用硬件層的SPI函數接口，但是主要的寫，讀指令都是在這里函數中完成的。在這層中需要提供5個標准統一的接口函數：
XXXOpen
XXXClose
XXXWrite
XXXRead
XXXIoCtl
沒有被用到的函數，可以為空。本來還需要Install函數來進行動態加載和刪除，因為stm32內存一般都很有限，所以舍棄動態分配。而把這5個函數用常量的形式直接編譯到ROM中。在驅動的抽象接口層中可以做選擇，哪些驅動要加載到內核，哪些不需要。不要的驅動不參與編譯。這樣有限的資源 可以得到合理的應用。這一層大部分工作可以說屬於一次性投入。
應用接口層：主要連接驅動和應用。又是連接應用層模塊與模塊之間的一層， 這一塊有很強的特殊性，第一包括了驅動抽象接口層，第二包括了模塊與模塊的接口層。第三又與應用層密不可分。
先說下驅動抽象接口，在驅動層時也有提過，這個接口 其實就是通過ID去訪問那ID對應的那五個函數。抽象接口也是一次性投入的函數，在設計時對其可靠性要很重視。
模塊與模塊的接口層，包括模塊的接口頭文件，這些頭文件要求是非常獨立的，不能加載模塊內的內部頭文件，應該包括接口函數的函數聲明，在接口中盡量少用到全局變量。如果非要用到可以使用函數的方式進行傳遞，或ucos消息隊列方式。最好用ucos進行傳遞，因為有很好的互斥保護功能。
應用層：這里所有模塊都算是應用層，在前面以經提到過，在模塊內所有變量，或函數（接口除處）應該都本地化。在模塊內可以有本模塊化共用的主頭文件，來方便本模塊的維護。對硬件的訪問其實直接調用應用接口就可完成。
到些主要的結構就算是大概總結完畢，希望給大家一點點幫助，也希望大家給一定的指正和完善。