研發紀事

設計說明         最近實現在 STM32F207 控制器 (ARM-based) 上面實現一個簡易型的 FTP server，其目的是為了文件的傳輸。原本在一般電腦上的 FTP 是一個再平常不過的網路功能，但是在 embedded system 上如果沒有搭配 Linux 作業系統，通常要自行開發 FTP 才行。圖一所示就是 STM32F207 控制器，上面有網路介面和 SD 卡，我們希望從遠端能將儲存在 SD 卡上的文檔經由網路下載，而這個 SD 卡就類似硬碟的功能。         為了完成 FTP 服務器，在控制器上面的源代碼需要準備： 作業系統 、 檔案管理系統 、 TCP/IP 網路協定 。幸運地，STM32 晶片已經整合了 FreeRTOS 作業系統，LwIP 網路通訊協定，還有 FatFs 檔案管理系統，所以我們必須利用這些材料將 FTP 的功能完成。由於晶片速度和記憶體的容量有限，FTP 服務器必須考量到連線的數量，只能盡量簡化 FTP 的功能，否則整個系統容易崩潰。另外，FreeRTOS 作業系統是運行在多工環境，當 FTP 連線存取多個檔案時，必須考慮到檔案管理的保護 (critical section)，這部分的設計如果沒保護好，檔案管理也可能會崩潰進而當機。底下是我們實現了一個簡易型 FTP server 的驗證，分別從命令列的 ftp 或者從檔案總管的 ftp 連線。 圖一：STM32F207 控制器 實現設計         我們從電腦上打開命令列，輸入 ftp xxx.xxx.xxx.xxx 就可以連上 FTP 服務器，成功連上後可以看到圖二的結果。因為設計為了方便簡單，所以不需要輸入使用者與密碼，直接就能登錄成功。在開發 FTP 服務器時，以最輕便的功能來考量，所以我們不可能把所有 FTP 協定的指令通通設計進去，只能實現一些常用的以及必要的指令，比如圖二和圖三的 dir / ls / quit 就是必要的指令。 圖二：命令列的 FTP 連上服務器 圖三：輸入 FTP 指令的結果         除了以命令列的方式執行 FTP，也可以從檔案總管上面輸入 ftp://xxx.xxx.xxx.xxx 來登錄FTP 服務器，如圖四所示。從檔案總管登錄的好處就是 Windows

        語音播放器應用在停車場系統 、 音樂鈴 、 語音導航...等等。 之前曾使用過一款語音IC -(新唐的 ISD15100 系列)- 單晶片內建 FLASH，可以儲存語音資料且音源輸入出的功能齊全，可說非常便利。後來，筆者發現 WT588D 語音模組的價格更為親民 (大約50~100 TWB 與儲存容量大小有關)，而且從網上零售採購非常容易，這是開發者的福音。         WT588D 語音模組稱為 WTW-16P ，其外觀如圖一所示，模組上包含兩顆晶片：一顆是 WT588D，另一顆是 FLASH 晶片。WT588D-20SS 是語音撥放IC，需要外掛一顆 FLASH IC 用來儲存語音資料，兩者之間用 SPI 介面通訊。這個語音模組並沒有把 WT588D 所有 pin 都接出來，只有接出重要的 pin 腳，共 16 支接腳，如圖二所示。 圖一：WT588D語音模組外觀 圖二：語音模組方塊圖與接腳分配 << 語音燒錄方式 >>         燒錄 WT588D 模組需要一個 USB 燒錄器，如圖三所示，再搭配電腦上的燒錄軟體將音檔下載到模組的 FLASH 裡面。在這裡要特別留意一點， 模組放置到燒錄器上的基座方向與位置必須正確，否則語音模組會真的燒壞 。 圖三：燒錄器與語音模組使用方式          打開燒錄軟體後，建立一個新文件。左邊區塊載入打算燒錄的音檔，如圖四所示，而右邊區塊用來編輯每個地址序號內的音檔 。每個地址序號代表播放語音的編號，每個編號裡的語音可以由一個左邊區塊內的音檔組成，或者由多數的音檔所組成。下圖四中，地址0裡面只會撥放一個音檔 "請按鈕取票"。地址序號旁有個 +/- 符號可用來編輯下個地址，我們將左邊區塊的音檔拖曳到右邊區塊，表示該地址序號會撥放此音檔，如圖五所示。編輯 完成後，我們再下載並燒錄到語音模組上。 圖四：使用WTW軟體載入音檔，右邊是地址存放的音檔。 圖五：將左邊音檔拖曳到右邊區塊，代表燒錄到地址序號。 <<模組控制方式>>         控制語音模組有分成一線式或三線式，一線式就是 MCU 下給模組的指令透過一根 pin 腳，這種方式沒有

        最近用 Microchip dsPIC30F4011 的開發板 (APP020 PLUS) 結合藍芽模組，如下圖所示，打算做一個馬達控制的顯示器。之前，接觸的 MCU 都是 STM32 和 NXP LPC 以 ARM 為核心的 32-bit 控制器。有機會首次使用 Microchip 的控制器，於是查詢了一下才了解 Microchip 發展很久了，過去主要以 8-bit 或 16-bit MCU 為主，目前也有 32-bit MCU。搜尋的過程中，大多數找到 8/16 bit 的資料是10年前的，這跟市場主流控制器是 32-bit 有關吧。dsPIC30F4011 系列晶片與 PIC 系列不同的地方在於一個核心有 DSP 運算指令，一個則無。目前使用的這顆 dsPIC30 相當於 ARM M0 等級的控制器，不過價格上，似乎 dsPIC30 比較貴，這就視使用者的應用而決定了。         第一次用 Microchip MCU，所以先準備一塊開發板，APP020 PLUS 是以 dsPIC30F4011 16-bit為控制器的開發板，PLUS 多了一些 I2C 和 SPI 介面的操作。另外，板子上還有一顆小控制器 PIC16F684 8-bit MCU。除了開發板之外，我們還要準備一個除錯器，也可燒錄程式之用。若預算有限，買 PICKit3 就可以了，如果開發的系統比較複雜，那最好買 Mplab ICD3，兩者的差別在於效能，PICKit3 除錯時無法設定太多斷點。因此，這個項目的硬體開發要準備的部分就是：         (1) APP020 PLUS 開發板         (2) PICKit3 或 Mplab ICD3 燒錄器         (3) 藍芽模組 HC-08 Bluetooth BLE         接下來，我們要到 Microchip 網站下載開發套件編譯器 MPLAB IDE v8.92 以上，注意一點：由於 Microchip MCU 種類分成 8/16/32 bit，每種的編譯器都不一樣，因為我用的是 dsPIC30F4011 16-bit，所以要下載 MPLAB C30 軟體專門 compile & link 16-bit MCU，在 IDE 裡面將編譯的路徑設到 C30 目錄上

本文說明「SipTalk 移動分機 APP」的隱私權政策。請您詳細閱讀，本文不定期更新，您若繼續使用「SipTalk 移動分機 APP」，即代表您同意相關此政策。 1. 個人資料之類別 當您使用「SipTalk 移動分機 APP 」（下稱「本APP軟體」）時，會執行下列動作：讀取通訊錄、讀取手機電信狀態、使用麥克風等。 2. 資料的收集與應用 「SipTalk 移動分機 APP 」服務器端，有收集下述資料： (1) 透過APP軟體撥打網路電話時，APP會使用手機麥克風進行通話，當使用者有設定錄音要求時，服務器將會進行通話錄音。 (2) 透過APP軟體撥打網路電話時，APP會讀取手機的電信狀態，以避免影響個人手機門號的通訊。 (3) APP軟體會讀取手機通訊錄之號碼和常用號碼，讓使用者能快速撥打網路電話。 3. 本軟體不會收集的項目 凡是您手機內的個人通訊錄之資料，「SipTalk 移動分機 APP」不會做收集，以維護您的個人隱私。 4. 「SipTalk 移動分機 APP」的資料儲存與保護 「SipTalk 移動分機 APP」為方便用戶使用，提供多項個人化設定功能。包含「常用號碼 」、「通話紀錄」。這些都是儲存在手機的記憶體內，請您妥善保管手機。另建議您在新增智慧撥號規則時，不要新增有關個人隱私的資料，譬如：身分證字號、信用卡號、生日等等，以減少手機遺失或遭駭客攻擊時的威脅。 5. 同意個人資料之蒐集、處理、利用或國際傳輸： 您了解並同意本團隊依本「隱私權政策」及相關法規，蒐集、處理或利用您所提供的個人資料。 6. 除下列情形外，本團隊不會任意將您的個人資料出售、轉讓或揭露予任何第三人： (1) 本團隊／本APP軟體將因法律規定、法院命令、行政調查或其他法律程序的要求而提供您的資料，惟在此情形下，該資料只會單純提供予調查單位，並受中華民國相關應適用法律的保護。 (2) 為了調查和防止非法活動、涉嫌詐欺、對人身安全有潛在威脅的狀況、對本團隊／本APP軟體服務條款的違反，或為了對上述情形採取應對措施。 (3) 本APP軟體或本團隊被其他公司收購或合併，我們有權利將您的個人資料移轉給該公司。如果發生這種情況，本APP軟體會在您的個人資料被移轉且將適用不同的隱私權政策前通知您。 7. 個人資料之安全 本團隊將依相關法

        花了不少時間開發一個APP，不斷地在手機上 debug 、 安裝 APK 、 移除 APK 、調整頁面 ...等工作，最終的目標就是能上架 Google Play，這樣才算是完成一套 APP 的開發。上架的流程可以參考 Google support [1]，當然網路上也有不少前輩留下巨細靡遺的步驟 [2]，只要按圖索驥也能成功完成上架。圖二所示就是我依照前人方法最後上架的截圖。我這裡就不重複說明上架的詳細步驟，只紀錄上架時所遇到的一些問題，相信也有其他開發者遭遇下列的情況。 1. 上傳的 APK 未經壓縮校準         第一次上傳 APK 到 Google Play，上傳完畢後，Google 跳出一個視窗，告訴我說 "上傳的APK 未經壓縮校準" ，心想在開發過程中我不是都能透過 Eclipse 成功安裝到手機上嗎？怎會出現這個錯誤。原來，上傳的 APK 必須先產生 keystore，再經過 jarsigner 和 zipalign 兩道程序，所產生的 APK 才能傳給 Google。至於詳細的做法請參考 [3]。當第一次上傳成功後，我們應該能看到圖一的版本資料了。 2. 裝置與版本不相容         上傳成功後，很開心地便想從 Google Play 下載這個 APP 來安裝試試看，結果 APP 視窗上面出現一行字 "裝置與版本不相容"。奇怪了，在開發時期無論是從 Eclipse 安裝或是 copy APK 到手機安裝也沒出現什麼問題，為何從 Google Play 下載安裝卻遇到不相容的問題。於是，詢問了 Google support 後，才知道 manifest.xml 裡面宣告了硬體要求，因為 Google Play 會檢查手機裝置是否有滿足這個 APK 的硬體要求，如果沒有，便不允許安裝了。另外，也可以從圖一的 "支援裝置數" 得到相容性的答案，Google Play 會列出這個 APP 能支援的裝置與不支援的，如果遇到能支援的數量很少，那我們就必須好好檢視自己的 AndroidManifest.xml 裡的內容。盡量移除不必要的權限，選用適當的 MinSDK 版本號，移除不必要的硬體要求。 3. 上傳更新版本         接下來想

        前陣子在開發安卓系統的 SIP 撥號功能 (參考 " SIP Voip 在 Android 系統上的開發 " 一文)，底層 NDK 設計與編譯大致完成，接下來要設計使用者頁面。首先，必須在腦海中約略規劃一個使用者頁面的雛形，再根據這個雛形設計一個符合 Android 系統的 layout。我們可以思考整個頁面該如何的布局，是垂直型排列或者水平的排列？還是類似表格式的布局？         就布局而言，安卓系統的 Layout 分成三大類型，分別是 LinearLayout 、 RelativeLayout 和 TableLayout 。LinearLayout 顧名思義就是內部 Widget 元件必須是直線布局，直線的排列可分為垂直或水平 (這裡可沒有斜線喔！)。RelativeLayout 是指內部的元件屬於不規則型的布局方式，每個元件彼此間靠著相對位置來排列。TableLayout 是指元件排列方式屬於表格類型，由幾行幾列所組成。         使用者頁面可以由上述三種類型混合搭配設計而成，每個大 layout 裡面又可以由小的 layout 組成，類似一種巢狀的架構。用例子說明更容易明白，圖一的左邊所示是一個撥號頁面的使用者介面，圖一的右邊所示則為頁面的布局概念圖。這個 APP 頁面布局是由一個具有垂直排列的大型 LinearLayout 構成，裡面再包含四個小型 layout。由於是垂直排列，所以裡面這四個子 layout 從上到下依序排列。第一個子布局是具有水平排列的 LinearLayout，因此裡面的 Widget 元件由左到右排列。接著底下的子布局有四個方向鍵和兩個按鈕，因為不具有垂直或水平排列的特質，只能用 RelativeLayout 來規劃這六個按鈕的相關位置。撥號盤的排列像是表格 4 x 4 的布局，所以這裡用 TableLayout 很適合。最底下四個按鈕呈現水平排列則使用 LinearLayout 布局。 圖一：撥號頁面的 layout         安卓系統的使用者頁面以 xml 檔案語法來描述，在 IDE 打開 xml 檔案後，我們可以看到模擬的頁面與 xml 語法，修改 xml 後能立刻看到模擬頁面的呈現。從圖二所示可以看出布局結構的情況，包含裡面的元件