 剛才在網(wǎng)上看到了一個介紹Qt嵌入式編程的教程（其實也是該硬件公司的產(chǎn)品宣傳），我突然發(fā)現(xiàn)，一向讓我感到神秘的嵌入式變成原來如此簡單。呵呵，這個有點吹牛了，因為我沒有做過嵌入式，所以這篇寫的都是些想當(dāng)然的東東，如果有不正確的地方，還望指正;p 我說嵌入式簡單，意思只是說它和PC程序開發(fā)沒有什么本質(zhì)的區(qū)別，甚至比PC程序還要簡單。由于嵌入式設(shè)備硬件平臺往往比較固定，所以幾乎不用考慮移植性的問題，程序員的任務(wù)往往只是調(diào)試出在當(dāng)前平臺上運行程序即可。 設(shè)計軟件就是設(shè)計不同層次的接口，而編程只是使用已實現(xiàn)的接口來實現(xiàn)自己設(shè)計的這些接口而已，嵌入式也不外乎此。對于安裝Linux系統(tǒng)的嵌入式設(shè)備其實 就是根據(jù)此系統(tǒng)已有的接口設(shè)計并實現(xiàn)新的接口。如果熟悉Linux，再按照說明書了解一下目標(biāo)硬件/軟件平臺，完成這些任務(wù)應(yīng)該是不在話下的。 我們通常聽說嵌入式難，那其實是因為我們使用的接口的抽象層次太高了，這些接口對于嵌入式設(shè)備而言是毫無用武之地的，那些.NET程序員就是典型的例子。 但是，對于一個熟悉Linux Kernel的程序員來說，任何給予Linux系統(tǒng)的嵌入式設(shè)備都應(yīng)該是不在話下的，他們要做的只有三個工作：1.看看說明書，了解一下自己可用的接 口；2.搭建開發(fā)平臺；3.充分考慮資源限制。
要一定說嵌入式難，我倒是覺得不是難在開發(fā)上，而是難在平臺的搭建上。嵌入式開發(fā)平臺基本上都是交叉編譯的平臺，這種開發(fā)方式的特點就是不能在搭建系統(tǒng)的
平臺上進行測試，必須把編譯、鏈接好的可執(zhí)行文件拿到目標(biāo)平臺上去調(diào)試。所以，我覺得，除非借助于虛擬機制，不然gdb這類調(diào)試工具應(yīng)該是沒有用處的，因
為程序根本就無法在編譯平臺上運行，而只能在由于資源限制而無法安裝和使用調(diào)試工具的目標(biāo)平臺上運行。
這樣，我覺得調(diào)試器的用處實際上已經(jīng)不大了，尤其是一些涉及到更底層的實現(xiàn)時更是如此。這就讓人想起了Hurbert
Xu以前講的那點經(jīng)驗：把gdb這個拐杖扔掉，想辦法把可能出錯的地方轉(zhuǎn)換成可輸出的信息輸送到屏幕上！ gdb雖然可能在某些地方派不上用場，但是我們還有一個工具： 條件編譯。我在自己的程序中喜歡用自己定義的D_OUTPUT宏來得到自己想要的信息： #ifndef MY_DEBUG_H_ #ifdef DEBUG #include #endif //DEBUG #endif //MY_DEBUG_H_ 除此之外，還可以用到__FILE__，__LINE__，__FUNCTION__
我覺得最后，也是最重要的一個困難應(yīng)該就是資源限制。我在網(wǎng)上看了一下，好像現(xiàn)在的一般的ARM設(shè)備都只有幾十K的RAM和幾百K的Flash(這個數(shù)據(jù)
不準(zhǔn)確，知道的麻煩說一下)，這種配置應(yīng)該是不能運行GUI程序的吧，要是可以那簡直太神奇了。
就是CUI界面，這點可憐的資源也會很容易就被吃掉，在這種情況下，想用C++似乎都得要考慮下了。所以，這個時候的嵌入式程序最麻煩，動輒就要考慮資源
不足的問題。  |
|
|
Previous 
Next 
嗯，能空想到這個程度不錯了。不過，我指出幾點錯誤：
第一：可以移植性，如果一個公司有一個產(chǎn)品、你在上邊寫一個一個應(yīng)用，這個產(chǎn)品做完了？然后，后來又有兩個差別不大的平臺，也需要這個應(yīng)用，然后你重寫一 遍？其實，我感覺相對來說，你恰恰說反了，PC因為其體系結(jié)構(gòu)的固定性，有時候不考慮往其他平臺架構(gòu)移植可能也可以。但是嵌入式的軟件產(chǎn)品，如果寫程序的 時候不考慮，以后可能光改軟件就得改哭你。
第二：嵌入式平臺難在平臺搭建上。這個觀點有兩面，如果你把設(shè)計硬件也算在平臺搭建里邊的話，可能是比較難。但是我接觸到的東西，平臺搭建都不是什么難 度，特別是gcc本身就支持的平臺。你可以看看關(guān)于gcc和libc的交叉編譯的資料，頂多就是耗費時間的很而已。我認為嵌入式開發(fā)真正的難度在于，嵌入 式開發(fā)，往往都是多線程的，把哪些認為規(guī)為那個線程，線程之間的數(shù)據(jù)關(guān)系，那些數(shù)據(jù)是需要加鎖保護的，在這種情況下，還要保證系統(tǒng)的穩(wěn)定、避免競爭條件、 還有性能要求，這樣寫程序簡直是戴著枷鎖跳舞。
第三：gdb，有一個東西，叫做gdbserver，你可以看看。不過說實話，我比較贊同你的 觀點，我更傾向于在程序里把東西輸出出來，帶上文件名函數(shù)名和行號。
第四：現(xiàn)在嵌入式平臺不是你查到的那樣了，不知道你在什么地方查到的。比如我就見過x86的嵌入式平臺有2G內(nèi)存的。我接觸到的ARM也往往至少有32M 內(nèi)存，64M和128M常見。我手機還有128M內(nèi)存呢。NAND Flash往往是128往上，因為這個現(xiàn)在很便宜。而NOR Flash往往有1～2M。也還不錯了。當(dāng)然，如果是有些片子片內(nèi)，估計就比較緊張了。所以現(xiàn)在嵌入式編程，除了一些極限情況，資源并不算太緊張。我的感 覺GUI消耗資源的原因在于，這些平臺往往沒有圖形芯片，用CPU來渲染圖形界面，有時候刷新頻繁的時候，就比較惱火罷了。
你的這個博客系統(tǒng)和東八區(qū)有三個小時時差？？？？
多謝指點！老大給俺寫了這么多，真是感激不盡:) 尤其是上面的第四點，俺真是閉門造車了。
那個gdbserver我回頭看看。至于線程的那些問題，我建議你不妨用面向?qū)ο蟮姆绞綄懘a，這種思想絕對是個節(jié)省腦力勞動的好辦法:) 我也把自己的想法總結(jié)一下，寫在另一篇中。
BTW：時區(qū)問題已經(jīng)改正。
面向?qū)ο?？現(xiàn)在用的雖然是C，但是程序設(shè)計基本上都是OO的??？但是，面向?qū)ο竽芙鉀Q線程調(diào)度優(yōu)先級以及一些公共變量在線程之間訪問加鎖的問題嗎？愿聞其詳，現(xiàn)在正給同步問題折磨這呢～