做了快一年的案子, 終於要結束了. 比預估的時間多了 3 個月. 雖然不是很滿意, 不過還在控制範圍內. 在還沒有完全冷掉之前, 把一些心得和檢討記下來.
承接專案因由
這完全是偶然.
本來在目前的工作準備要離職, 和朋友一起做. 剛好公司也希望我離職 (沒有專案可以做了), 跟我說不調走就資遣. 當時想, 反正要走了, 就領一下資遣吧, 就同意了. 隔一天, 朋友那邊打電話來, 表示產品方向覺得不妥, 叫我先不要過去, 那就好吧, 先不要過去. 一回神, 想到接下來不就沒工作了嗎 ? 剛好有朋友的公司, 需要做一個專案, 但是擔心能力不夠, 所以就找我幫助. 當下就想, 至少有一點收入會進來, 工作再繼續找好了, 就先答應了.
接下來那個星期, 就開始瞭解這個案子的相關資料, 排定 schedule, 簽訂合約, 準備接這個案子.
一個星期過去之後, 公司又來通知說不資遣 (講白了就是不想花這筆錢), 要我自己離職. 真的滿討厭這種專搞檯面下小動作的行為. 那好吧, 把我調走, 我一面做案子, 一面找工作. 原先要一起做的朋友隔天又打電話來, 說有東西要做了, 要我趕快過去!! 是講好一起來亂的嗎 ?!
結果就是我接了這個案子.
專案內容簡述
這個案子主要是 porting. 客戶有一個 TI Stellaris 已經完成的測試設備專案, 希望 porting 到 TI Tiva (新一代的處理器). 以下說明主要變更的部份
- 配合硬體的 schedule, 先用 TM4C123 Launch Pad, 再用 TM4C129 Launch Pad, 再換成 實作的 TM4C129DNCPDT
- Library 從 TI Stellaris 移轉到 TI Tiva
- 開發環境從 IAR (付費, 而且很貴) 改到 Code Composer Studio ( TI 自己的, 免費用於 TI 的 solutiom)
- 編譯程式從 IAR compiler 換成 CCS 的 GCC
- 作業系統從 SafeRTOS 換成 FreeRTOS
- Embedded Python 調試及修改
- PC 端 Visual Studio 的 software 配合修改
執行中遇到的問題
以下記錄專案執行中, 遇到的問題點
規格定義不明確
只要是程式相關的專案, 大都會遇到這樣的問題. 不過這次遇到的問題不太一樣, 客戶這套系統是國外部門開發的, 移轉到國內來, 國內也沒有人在用. 只能看著 source code 推測. 雖然後來有提供一些設計文件, 不過已經消耗掉一些時間.
Secondary Boot Loader
這套系統需要能 udpate firmware, 因此需要有 secondary boot loader. 之所以稱為 secondary 是因為 IC 本身就有 boot loader, 可以載入 NAND 上面的程式碼. Seconday Boot Loader 就是被 IC 載入的部份. 它負責更新或是執行主要應用程式.
這本來不是太困難的事. 不過為了相容於原有系統, 所以必需在 build 好的映像檔中, 插入一段資料. Tiva 的映像檔的開頭, 固定是 { 堆疊指標 + 重置向量 + 其他中斷向量 }, 檔案最後, 原系統也另外加了 check sum. 在 IAR 中可以指定一個 structure 在 link 的時候, 固定的位置. 其實 CCS (Code Composer Studio) 也可以, 只是文件沒有說明這件事, 因為 CCS 用的 compiler/linker 是 GCC, 所以它在這部份沒有特別說明.
Release/Debug mode switch
這本來是很簡單的一件事. 不過因為實作了 Secondary Boot Loader, 應用程式的映像檔會有兩種. Release mode 的啟始位置不會是 0x00000000 (已經被 Secondary Boot Loader 佔用). 但是用 JTAG debug 的時候, 它的位置是 0x00000000. 在 CCS 的環境下, 它會使用到兩個 configure file. 這其實也還算簡單. 比較麻煩的是, 要如何在切換 debug/release mode 的時候, 自動去切換這兩個 configuration file. CCS 的 pre-build 可以接受的路徑格式是 Linux 風格, 無法存取到 local 的檔案. 最後只是很簡單的設定兩個批次檔來做切換. 不過還是覺得有點遺憾, 感覺滿蠢的.
C/C++ 混用
原系統的程式碼, 有很多 C/C++ 混用的情形. 在 IAR 的設定中, 是可以把 C/C++ 都當作 C++ 來使用. CCS 也是可以這樣做. 不過,有部份的編譯指引 (#pragma) 不能使用. 尤其是中斷向量必須宣告在 data section. C/C++ 的函式的 naming 是不一樣的, 所以常常發生 linker 找不到 object code 的問題, 有時候沒注意到, 繞了一大圈, 才發現又是一樣的問題.
Heap Configuration
最麻煩的是 heap. 原系統裡面用到了很多 new 這個 operator, 不過我們的記憶體不是很大, 才 256 K, new 一個包含 7 KB 的 buffer 的 object, 就掛了, 而且很不容易查出來問題是什麼, 更不容易聯想到需要調整 heap 的 大小.
Task Stack
所有的 RTOS 都需要一些 stack 來支持不同 task (或是叫做 thread,…) 的切換. SafeRTOS 的 stack 是在建立的時候給定位址及大小. FreeRTOS 則是在 init 的時候, 先配置一大塊, 而後在 create task 的時候, 自行從這一塊中去分配.
USB Update
原本想要用 USB 的 DFU class 來做 firmware update. 不過因為有兩塊 firmware (Boot Loader/Application), DFU 沒有辦法很好的支援這個動作. 最後還是用一般的 Bulk Transfer. Boot Loader 只檢查需不需要 update Application. 如果需要就更新, 否則就執行 Application. Application 負責對應 PC, 接收 firmware image. 如果收到的是 Boot Loader, 就直接更新, 更新完系統 re-boot. 如果是 Application ( 自己是執行中的 image, 不能自己更新), 就先寫到 NAND 的後段, 並且留一個記號給 Boot Loader, 然後 re-boot, 讓 Boot Loader 去處理更新 Application 的動作.
在把 USB device 從 USB bus 上移除, re-boot 重新連線的時候也遇到過一些問題.
這部份 debug 比較困難. Boot Loader/Application 以及 PC 的軟體都需要同時運行. 而且也不能用 JTAG 進行 trace.
Python
Embedded Python 也是第一次遇到. 在 Embedded system 上內建一個 Python 來執行 PC 傳過來的 script, 這部份我是覺得很有趣. 而且在設備的實作,裝機,調整上, 應該是很有發展性. 不過在處理的時候(大多是在看文件找資料), 也是掉了不少頭髮.
結語
整體來說, 滿有挑戰性, 大致上設定的功能也都完成. 也相當疲倦, 不過總算是沒摔了招牌.
接下來, 要開始準備生涯的下一個階段了.
