學單晶片經驗談（二）

嘿～嘿～...

上回我有介紹過我的第一台單晶片的學習開發平台 : 8051 ICE。

http://chamberplus.blogspot.com/2008/06/blog-post_13.html

當然啊...我們也不能錯過在單晶片應用市場中的另一大主角： Microchip 的PIC 系列。

在我還在沒學會USB Controller 之前，我就有機會接觸 Microchip 的PIC 了。

那時啊，就是還在玩那個CDI 機車點火器啊，那時就有廠商請我考慮用PIC了。

而後來進了園區晃了一圈...人嘛，總是要顧三餐啊！

那時候的PIC 可以選擇的單晶片的種類也不多，當然啊，

以我對於CDI 點火控制器的系統設計觀點來說，那時候既有的PIC單晶片也未必適合該系統需求啊！

所以啦...也沒多花多少心思去瞭解 PIC 的架構或寫其應用程式。

後來呢？....離開園區之後，因緣際會，還是有機會碰到PIC 的應用了。

這時候的PIC 的單晶片種類就可選擇的機會就很多了...

結果呢？！...人家還是要我利用PIC 寫一個CDI 點火器的範例程式。

所以啦...我就拿到這一組的ICD2 開發平台...也有機會玩了一下PIC了。

（那到底我有沒有寫完那個CDI 數位點火控制器呢？！...這個故事其實還沒結束。

以後我有機會再跟各位報告，因為啊...以我的觀點，我要搞CDI點火器，

絕對不是說只寫一個程式，玩一個產品那麼單純而已，那多沒意思...

那還不如請個大陸工程師寫一寫還比較快...我說過啊...唯有系統整合能力才能創造自己的價值，

與建立自己的技術門檻，否則啊...那不如DIY 一下不是也很好嗎？！）

-----

這個ICD2 我想玩過PIC的人都應該知道的...其實以現在所謂的單晶片開發工具來說：

他的價位應該還是屬於貴的，當然啊...我也知道Microchip 對於學校的支持價位...

以前我在推那個FxxA 多核心單晶片時，就遇到這個類似的笑話...

那時我是跑台南某科技大學時，所碰到的...不過呢？！...這個笑話，我不能在這裡講，

否則啊...萬一有人聽了不高興...我也沒有什麼好處？！...有興趣聽的，再私底下問我啦！

-----------

ICD2 啊...也有人俗稱"餅乾盒"...因為他外觀的關係吧！

但至於這麼有創意的搞一個圓形產品，的確有其創意...但對於PCB 版來說：真的比較好嗎？！

...不知道！也不懂。

打開外觀盒子一看...嘿～嘿～....（這好像是我們這種工程師的天性喔？！ ）

我想：這應該是以前比較舊的設計，也有可能是修改以前開發工具為USB 介面的設計吧！

因為很簡單....現在的IDE Tools 的USB產品，幾乎也沒有再用外加電源方式了。

因為真的比較不方便，...只是會凸顯自己在IDE tools 的開發設計功力不足。

明明USB 可以供電500 mA 給您用，您還搞到要外加電源？！

而明明又是可以是 ISP 功能...我們開發的 Target Board 也會提供電源的...

所以，以我後來看到的像類似 Atmel 的 AVR ...或是 ST912 的 ARM 開發...

乃至那個 Silicon Labs 8051。就幾乎沒有再看到這種還外附電源線的的IDE 開發工具。...

（當然啊...後來Microchip 也有出一種比較小，而且比較便宜的IDE Tools (PICkit™ 2 ） ...

（有興趣者參考：

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en534451 )

就像一條巧克力糖那麼大小的 IDE Tools ...Micrpchip 是不是都比較好吃呢？！

怎麼他們的開發工具怎麼總是令人聯想到餅乾、糖果呢？！）

他裡面用的USB Controller 是 Cypress 的 CY7C64613...外加一棵PIC 本身的 PIC16C877 ...

我想他原本的設計應該就是以這顆 PIC16C877 為主吧...

USB Controller 也只不過是一個過渡方式的提供USB 介面，

否則啊...以USB Controller 本身支持韌體與程式更新能力來說...

應該一棵 USB Controller 本身就可以做到 IDE Tools 的功能了。

那為什麼不用Microchip 本身的USB Controller 呢？！...哈～哈～這可能還要講另一個笑話了...

還是先不講好了...我想為什麼不用MicroChip 的USB Controller 來說：

我不是有提過嗎？！他應該是比較早的設計...那時Microchip 應該還沒有USB Controller 產品線吧！

好吧...我來講後面提到的這個趣事...如果，IC設計公司有自己的產品線...

拿自己的產品線來設計自己的開發工具是無可厚非的...也是自然而然的想法！

但是呢？！...像這種開發工具往往都不是只是作一代而已，或是只是支援眼前那個一兩種產品線而已。

未來還有多少產品線會共用也不知道？！所以呢？！當您有這種考量時，

您對於這種開發工具的解決方案，就不會侷限在自己既有的產品線了。

之前啊...我在作那個FxxA 的燒錄器時...人家就堅持要用自己的微控器來設計燒錄器。

（程式只能寫短短幾KBytes又是OTP的...怎麼會成為搞開發工具的系統平台呢？！）

我也不知道人家為什麼對自己的產品這麼"過渡鍾愛"或是說"過渡保護"？！

後來我提醒說：寫這種開發工具時，講求的是快速升級、維護容易與系統擴充時...

為什麼不選一棵稀疏平常容易維護的單晶片來作呢？！...像是Flash 8051 單晶片就好了啊？！

甚至隨便找個工程師也都會寫...多方便啊...屆時，那時全公司才似乎恍然大悟的點頭似的...

那後來有沒有這樣子作？！我就不得而知了。....

其實，這樣子想法對於很工程師Style 的公司成分來說...是很容易發生的狀況。

的確有一點不是很切實際的作法...我想如果您也是工程師出身的...

當您遇到類似的想法時...您也有可能會陷入這種迷思，不會從比較大、比較廣的"業務"思維方式去想！

否則啊...下回您的開發工具遠在北京或是歐美發生問題時...您該如何遠端維護與系統韌體升級呢？！

還是要工程師辛辛苦苦的跑一趟去看問題呢？！...

----

好吧...回到我們這個 ICD 2 的話題上！...

那您們會很好奇說：既然版主也用過MicroChip 方案...卻很少聽到版主提及Microchip話題？！

說真的...我不是那麼喜歡用PIC ...因為PIC 容易被破解 Copy 是出了名...

以前聽說在大陸啊，破您PIC程式是幾天的事....後來聽說已經進步到是算小時的了。

以寫單晶片的程式來說...您辛辛苦苦寫了幾天乃至於許多系統整合的Konw-how...

人家根本不用去懂您的Know-how ...直接就破解與Copy 您的設計。

我想這是許多工程師所不能接受的，當然啊...以Microchip 產品線這麼多 ...

我們一時也搞不清楚：哪一棵保護比較好？！哪一棵容易被破解？！...

所以啦...當我有比較好的選擇之下,...我還是比較謹慎的。

當然啊...如果您有比較好的建議，也歡迎您提出...或許我們可以交換一下彼此的心得啊！

------

對於PIC 來說：我只有在開始摸的時候，有寫一兩個PIC 的組合語言...

但後來呢？！...就很懶了...而且因為PIC 後來出的單晶片所支持的周邊電路也多了，

而且他單晶片的族系真的"族繁不及備載"的，用組語寫真的越來越不容易維護！

最討厭麻煩的是他那個跨Bank 的問題讓我一時也很難適應...

而用C語言來寫就比較省事多了...而且啊...既然要用PIC 這種微控器來寫案子，也沒有多少程式可以寫。

所以啦...乾脆就全用C來寫了...（講難聽一點...反正都有被破解的機會...

也不用花太多時間在程式Coding 上面，倒不如花多一點時間在系統整合方面還比較實際一點！）

這也是算是一種另類的使用習慣的改變。

所以啦....從我們這種使用習慣的改變來說：（向我們這種LKK 寫組語出身工程師來說如此！）

如果，真的要我再接受另一種新的單晶片微控器來說：真的...沒有支持C語言的...

真的會很累的耶...不知道閣下的感覺是否如此呢？！....