這幾年來，一些所謂電子產品的開發趨勢已與數年前略微不同了，
尤其是一些有所謂的Firmware based 的電子產品東西，
所以，我只好把他擺在FPPA 的相關分類中。
套一句老同事講的話：各位長官也不要太過於反應或窮緊張的...
這些沒有什麼好高度機密的東西...尤其是這種單晶片的開發平台，
( http://godspeedlee.myweb.hinet.net/ 其中的2007/07/07
或是： http://godspeedlee.myweb.hinet.net/job4.html )
看來看去：大家都是大同小異，也沒有什麼好驚豔的！
甚至連一些FPGA 或是CPLD 的開發平台也都如此....
好東西是不怕人家抄的...如果，連別人都還不想抄的東西...也沒什麼好怕的嘛！
----
其實，對於一些類似單晶片MCU的市場來說：開發工具是扮演著一個很重要的角色，
也不單是單晶片MCU產品，現在的電子產品所講求的也都是重視開發平台的...
大家不是很喜歡說： SOC 或是什麼Total solution（解決方案）啊！
結果：每個客戶就反過來問您說：那我用您的方案有什麼特色啊？！
講難聽一點...我有什麼好處啊，或是有什麼利益先機啊？！
不要一個turn-key solution 拿給客戶，玩了大半年的，還搞不清楚方案...
所以，一套簡單容易﹑平易近人的開發平台就是很重要了...
現在連要作絨毛玩具的語音IC 也都要提供簡單容易上手的開發平台工具...
講難聽一點：現在的工程師誰還有那麼多美國時間搞得懂您的解決方案...
更不用說：要從頭一行一行的寫程式了說....還要懂得每一個單一指令的意義說？！
大概就剩下我們這些LKK，中毒很深的工程師才想要去研究說...
---
首先在下我玩過單晶片也不少...也做過許多開發工具...說真的：人生苦短...
像雷兒網站裡太乙大大...最近因癌末也走到油盡燈滅階段，也令人不禁欷噓...
( http://www.haifeng.idv.tw/leo/cgi-bin/topic.cgi?forum=37&topic=46&start=0&show=0 )
過去多少古人先賢的偉大發現與發明也都因為十八般武藝，傳了十七代就全抱進兵馬俑似的坑穴了...
喊了多少五千年優良文化歷史又如何？！...科技的東西：還不是國外的月亮比較圓吧！
見賢思齊...見不賢則自省之....（一般人比較容易做到第一點，後面那一句話就比較難吧！）
所以，在下就寫了這一篇...關於開發平台工具的一些觀念東西..
-----------------------------
話說：在下最近研究ATMEL 的AVR 系列產品...之前也發表過AVR Dragon照片...
最近終於把平台架起來了...當初買AVR Dragon 時，設定的目標就是要用ATmega64...
因為要作機器人啊﹑或馬達相關研究議題時，所重視的除了硬體資源需求外...
就是希望ROM Size 稍微大一點...誠如先前提到的...現在寫韌體...不用C寫的話...
改天又要您換成 dsPic 或是ARM時...不就是搞死人了...
至於組語就留給平時沒事拿來研究單晶片用的...
改天有機會就拿一些組語的基本指令來說明單晶片的特色...
----
其實，在網路裡搜尋結果，有關AVR Dragon 的資訊也不多...原先也沒有很仔細的詳讀
相關資訊或資料...後來才發現...AVR Dragon 除了標榜是一塊簡易型的AVR 開發平台...
他也是一個AVR 燒錄器或模擬器....但是呢...他竟然不支援ATMega64 的JTAG debug...
嗚...嗚....他只支援到ATMega32（包含）以下的模擬環境 ...
害我當初買AVR Dragon 時，跟人家也拗了一棵ATMega64 ..
不過，幸好的是我們這種LKK 的老工程師，大都可以透過許多方式來Debug ...
但至少AVR Dragon 還可以支援Serial ISP programming 及JTAG Programming 功能，
雖不滿意，卻也可以勉強接受啊...如下圖所示...
---
接下來，我們就要提有關開發平台（IDE，Integration Development Environment），
之前提過這一類的東西大多大同小異，一般人只要多摸個一兩個類似的開發平台，
應該都會很熟悉這種東西...不過，我要在這邊提的倒是一個跟硬體有關的東西...
就是：這些相關的開發平台，如模擬器或是燒錄器等等...因為不論是各種電子產品...
最終還是得落實到實體的IC產品上...沒有實體IC...那原廠賺什麼？！
但是：對於一些所謂系列產品來說： 諸如Microchip 的 PIC﹑dsPic 或AVR等啊...
人家也不會是一棵吃遍天下吧，尤其現在的電子產品都講求多樣化，又講求經濟成本效益...
所以一些電子零件也幾乎要為客戶或市場量身定作的...所以，人家每一家把產品擺出來，
就是落落長的一系列產品...環肥燕瘦，任君挑選...所以相對作開發平台工具就累了囉...
以前作的向前相容，這一點到也算是小Case，但最難的是：以後的東西有誰料想得到呢？！
開發工具也不能一天到晚更換或是重新設定...不把工程師搞死才怪，
更不用說：搞兩回合之後，新客戶給嚇跑了...連舊客戶也不想玩了...
所以，這些開發平台或工具開發，就必須有長遠規劃...一開始就要很小心設計...
我們就可看到在Atmel的 AVR Studio 的下拉式選單中的這一項目：（如圖所示！）
我們可以很清楚的看到一些系統的更新機制...而這些更新機制是要留給客戶自行處理的...
話說萬一您的開發平台工具賣到千里之外的北京﹑莫斯科...您該不會想一趟飛過去更新吧..
而自從USB 及Flash的機制出現後，這種遠端更新系統的方式就很容易達成了。
所以啊...版主當初在設計FPPA的開發平台時，也預留了這個機制：如圖所示：
而其中的那些所謂的Reserved Cmd0 及Reserved Cmd1 就是拿來測試一些USB 命令或
保留給一些未來開發平台用的...只是功能在測試完後，就把他Inhibit 掉了...
我沒騙您...我在原始的工具的程式平台中真的有如此設定喔...如下圖..
---
相對來說：您的USB 相關的程式庫啊...或是一些 callback 程式庫就要不斷的
增加與擴充，以因應未來不可預期的需求...如下圖所示中...
相對USB的callback 程式庫就得不斷的延伸與建立...
但相對來說：在系統端的韌體也要有相對應的擴充性...
所以啊，您們就應該可以體會的到：人家 Atmel的USB controller是採用
自家的Atmega128 外加PDIUSBD12....您覺得用一個程式容量的小小的幾K的
USB Controller 就可以不斷的去擴充未來系統需求嗎？！...
當然，人家還有一個比較重要的考慮點是：這樣的解決方案是他們未來可以掌握的！
這也是人之常情，可想而知的...
----
其實，因為現在的電子產品乃至電子零件越來越會講求使用或開發便利性...
像是一些所謂Flash device 或智能升級的功能等...所以，相對來說：這些搭配的
開發平台或輔助工具所扮演的角色是越來會越重要的，甚至某些特定市場領域中，
配合一些turn-key solution 的開發工具更是決勝負的重點...
相對來說：像USB這麼方便的PC周邊介面，也可以搭配一些PC 端的應用軟體...
會讓這些輔助開發工具亦彰顯著其重要性...
就像一些人開始利用PC平台開發機械人產品的道理是一樣的...
所以，像有些單晶片MCU來說：當Program flash (ROM) size 動輒幾十K Bytes乃至百K時，
硬體要加幾個PWM 或是Timer 已經不是那麼重要時，
相對來說：開發平台與相關輔助硬體工具，變得相對重要性了！
留言列表
