其他

      仔細看了昨晚搜刮到的那篇關於WinCE錯誤報表的文章，受益匪淺。使用流程已經介紹得足夠詳細，這裡不再贅述。需要參考的同志，請直接看原文。這裡補充一點原文中貌似沒講到的，個人覺得很關鍵的地方，如何在產品中保留錯誤報表。       那篇文章中提到要將錯誤報表從Windows的目錄下拷貝到別的非易失性的儲存空間中，以便後續的分析與處理。這在開發過程中是沒有問題的。但如果產品已經發布，我們需要從客戶的裝置中擷取錯誤報表，就行不通了。      

　　以前曾利用GAPI實現應用程式直接操作顯示驅動的FrameBuffer，以提高螢幕繪圖和視頻播放的效率。GAPI依賴於顯示驅動，必須在顯示驅動中添加相應的介面才能正常使用。如果平台是我們自己定製的，在WinCE5.0中，我們也可以通過另外一種方法來操作FrameBuffer。　　以DeviceEmulator為例，我們已經知道FrameBuffer的物理地址是0x30100000,大小為0x100000。那麼在應用程式中可以通過如下代碼，直接擷取操作FrameBuffer的機會。代碼

    最近在一款ARM11的開發板上移植WinCE6.0，碰到了一些問題，也收穫了一些經驗。雖然ARM+WinCE的開發已經做過一段時間了，但開始用一款新的MCU時，總會碰到這樣那樣的問題。首先是DataSheet，看慣了三星的文檔，總覺得DataSheet就該那麼寫，條理清晰，方便查看。但不同廠家的文檔有不同風格，起初調試時很不習慣Telechips的文檔編排方式，要找到想看的內容得翻半天。這大概是先入為主的原因。晶片文檔在開發過程中是很重要的資料，提高看文檔的速度也就能提高開發的速度。所以

　　前一篇介紹了如何在應用程式中操作FrameBuffer，實際上得到FrameBuffer後，對於我們來說截取螢幕就是很容易的事情了，完全可以繞開GDI，並且效率要比使用GDI高。　　Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--> 1     BITMAPINFO    bi; 2     BITMAPFILEHEADER bmfHdr; 3  

     WinCE6.0的OAL跟WinCE5.0中的有較大差別。瞭解這些差別，對我們移植OAL部分很有協助。本文將簡要介紹WinCE6.0 OAL的特點。     WinCE5.0將核心、OAL和KITL連結成一個核心可執行檔NK.exe。而WinCE6.0將這三者分開，分別對應Kernel.dll、OAL.exe和KITL.dll。顯而易見，這樣做最大的好處是可以單獨升級這三者中的任何一個，而先前的結構則是牽一髮而動全身的。WinCE5.0的OAL結構1所示：               

      前面介紹了如何直接操作WinCE的FrameBuffer，這裡將介紹一種通過寫FrameBuffer顯示資源中BMP圖片的方法。並與使用GDI做一個比較，看看直接讀寫FrameBuffer是否能提高效率？      採用GDI的方法，關鍵代碼如下:Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->    hScrDC = CreateDC(

    今天在偵錯工具時，發現了ARM-GCC下sprintf()的一個問題，它不支援浮點數。以前從來沒碰到這個問題，而且認為這肯定不會有問題，折騰了半天，最後在ADL_User_Guide中找到了答案。ARM-GCC下的sprintf()確實不支援%f，文檔中給出了相應的解決方案。     Important remark about GCC compiler: When using GCC compiler, due to internal standard C library

    跑了兩天的現場，終於對使用者有了一個交代。最後還用遠程顯示工具錄製了一段示範視頻，供他們參考，效果也不錯。但寫文檔必須用圖片的，找了很久的AVI轉BMP的工具，都沒能找到好用的，鬱悶壞了。所以整理了下以前弄的一個WinCE下的截屏工具，希望能方便使用者使用。    新版本的WinCE截屏工具，支援BMP和JPG的儲存格式，支援手動儲存和自動儲存，如所示：            新版CECap的: http://files.cnblogs.com/we-hjb/CECAP.rar

       這兩天在調試RMC程式，這是一個WinCE下的“遠端桌面”程式。由於在單位沒有時間調，所以只能回家做，可家裡又沒實驗板。好在Windows CE是有模擬器的，可以用模擬器代替實驗板進行程式的調試。即便如此，還是碰到了一些問題，不過都一一解決了，寫出來跟大家分享一下。       最早主機上已經安裝了EVC4+SP4，VS2005+SP1+Platform Builder6.0+R2等 Windows CE的主要開發工具。既然沒有實驗板，那就定製一個中文的WinCE6.0的作業系統，

    這兩天在調試一款新的硬體平台，它採用的MCU依然是S3C2410。該平台新增了一個RTC模組，採用的晶片是DS1337。這是一個IIC介面的時鐘晶片。在開始調試時碰到了一些問題，MCU始終無法與DS1337通訊，走了些彎路，浪費了不少時間。後來發現是IIC的SDA和SCL接反了。為了以後能方便調試2410下的IIC裝置，所以決定為2410的WinCE做一個IIC調試助手，以免下次再碰到類似的問題，而多花冤枉時間。      IIC調試助手的主要功能：檢測S3C2410

         這個對話方塊，大家應該都不陌生。程式員做開發時經常會見到，使用者肯定也曾被它騷擾過。很顯然，這是軟體的BUG所致。軟體中存在的BUG肯定是會出現的，只是時間的問題，或早或晚，有些很幸運在測試時就會被發現，那些不幸的就成了客戶抱怨的緣由。所以，我們不能抱有僥倖心理，而應該想辦法來解決這類問題。       

　　這兩天在WinCE6.0上調試了下3G模組，華為的EM730，它支援GPRS和WCDMA。雖然沒有涉及到驅動的移植（沒有原始碼），但調試過程還是幾經周折，記下來以便後用。　　EM730是MINI PCI介面的，也支援USB。於是先請硬體工程師幫忙飛了一堆線，在PC上測試了一下，工作完全正常，證明模組本身沒有問題。　　在WinCE6.0上，安裝了HW提供的一個驅動，並將模組插入，驅動似乎也是正常工作了，沒有提示需要再安裝驅動。開啟串口調試助手，竟然發現多了三個可用的串口，確定驅動是工作起來了。

　　今天Google資料時，意外找到了這本Sam先生出的WinCE6.0的參考書，英文原版的《Professional Microsoft Windows Embedded CE

       WMP100的開發，真是舉步維艱，寸步前行。雖然越來越順手，但還是不斷碰到奇怪的問題。想是想不通的，百度一下，還是不知道的，Google裡也冒不了幾個泡。就說數學函數在OPEN AT中的使用，就讓我很是鬱悶了一陣。好在今天終於解決了，在這裡留個記號。當然最好是WAVECOM能出一個關於OPENAT的FAQ，方面廣大開發人員參考，不要讓這些小問題再成為我們的大麻煩。^_^       要想在OPENAT的應用程式中使用如sqrt()、cos()等數學函數，首先需要包括標頭檔math.

      前面介紹了如何顯示資源中BMP圖片的方法，這裡補充一個顯示32位色BMP圖片檔案的方法，並再次比較直接寫顯存與用GDI的區別。      首先將WinCE5.0的模擬器顯示內容修改為480*272*32，並準備一張32位色的圖片，如所示。                      使用直接寫顯存的方法，關鍵代碼如下: Code highlighting produced by Actipro CodeHighlighter

上一篇已經詳細介紹了如何在主機上搭建WinCE開發環境，說白了就是通過PB6.0匯出一個SDK給VS2005用，似乎VS2008也可以用這個SDK。據說做系統的開發必須用VS2005+PB6.0，而應用的開發是可以用VS2008的。機器上沒有裝VS2008，所以不能測試了。不管怎樣，我們已經有了一個模擬器代替實驗板，可以用這個模擬器來偵錯工具了。雖然是模擬器，但基本的外圍裝置都有了，包括網路、Storage Card、調試串口，也支援同步。在使用模擬器的過程中發現一個小技巧。如果從Device

    前面曾說過WinCE6.0中的RomImage.exe存在一個BUG，在某些情況下不能正確產生nb0檔案，不管是正式版還是試用版。最近發現試用版Platform Builder 6.0中的RomImage.exe竟然還被埋了個定時炸彈，而且已經爆炸了，現場如下：makeimg: run command: romimage F:\OSDesign\CHSOS\CHSOS\RelDir\DeviceEmulator_ARMV4I_Release\ce.bibError: failed PB

   “誰動了我的GPIO”，我想很多做嵌入式開發的同行可能也碰到過類似的問題：硬體沒有按照設計的程式工作，好像是相關的寄存器在別處被改了。遇到這種情況，一般有兩種處理方法，一是通過JTAG模擬器進行調試，單步跟蹤，確認相關的寄存器就是我們要設的值。而這在調試WinCE驅動或者應用程式時是不方便實現的，一般在WinCE中通過添加列印資訊來確認。前面曾講過基於KITL調試WinCE的方法，這種方法固然強大，但也只是一種手段。個人以為，在WinCE已經跑通的情況下，調試驅動或應用還是少用KITL的好

       早先跟ZL討論過WinCE6.0下使用TCPMP播放視頻的問題。他認為直接寫顯存應該可以讓視頻播放更流暢。今天我在我們的平台上實際測試了一下，分別使用GDI、Direct和DirectDraw三種方式做了Benchmark，其中Direct就是他所說的直接寫顯存的方式。