這幾年來,一些所謂電子產品的開發趨勢已與數年前略微不同了,
尤其是一些有所謂的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 已經不是那麼重要時,
相對來說:開發平台與相關輔助硬體工具,變得相對重要性了!