改寫原廠的USB應用程式(續二）

這種燒錄工具軟體應該沒有一次寫完就到定位的...

依過去的經驗是：需要一直修改，或是一步一步的修改，使其臻於完善。

上回只是稍微改寫了一下：但發現還是有些不完善的地方...

譬如：當我們連線抓到 MCU 型號時，應該就知道該MCU 所支援的Flash ROM Size...

所以啦 ...把這個機制也給加進來了....如圖中所示：F330 為 8KBytes 之MCU 。

（喔...中間那個LOGO...可不是事後用貼圖貼上去的喔...而真的是把這個LOGO 設計在程式中的啦！

....另外也可以把視窗圖框中加註 "ChamberPlus Version"....原廠會告人嗎？！...

所以啦 ...我還是保留了原來原廠的軟體名稱與該公司名號！）

好吧...上回有提到：其實在一般燒錄工具軟體中有一個蠻好用的選項：就是自動序號燒錄。

就是上圖中的那個Serialization Setting...當然，以我們寫的一般MCU Code...

是沒有這種序號...但對於有些應用來說：卻需要每一個MCU的韌體都需要自己的序號。

但是這個序號又無法用韌體本身產生的，需要靠燒錄時加入的！

最常見的就是在USB 的宣告...當USB 宣告都一樣時，就得靠序號來分了。

當然有些人也是希望透過序號來追查貨物流向...所以，這種序號燒錄就其需要。

但很不幸的是：原廠提供的這支程式沒有支援此一功能；但卻在另一隻應用工具程式有支援

此一功能...唉～...可能在原廠不是同一個人寫的，否則，應該不會發生這個問題。

我只好動手把這兩個功能整合成一支應用程式了吧，不過，這一部份就不是那麼容易移植改寫了。

所以啦...我就先暫時先保留這一功能畫面選項，以後有空在慢慢的把他完善吧！

至少，我先把這一部份先移植過來啦！.......

-------------------------------------------------------------------------

因為，我經由連線可以知道我的Target MCU 的Flash ROM Size了，

所以，我就可以把上回那個Read Back HEX File Viewer給他完善了，

因為在視窗上的那個預覽圖表必需知道FLASH ROM Size ，才比較好調整...

目前，這個Preview 的圖表視窗：原則上就把所有Flash ROM的 區域全顯示出來！

這樣子可以提供比較方便的預覽功能！

因為F330 是 8 KBytes 的Flash ROM MCU ，所以他是到達 0x1FFF的！

---但是呢？！依據原廠的資料：F330 雖然號稱是8 KBytes 的Flash，

但是他的最後一個Flash Page 卻是不能使用的 ...（就是0x1E00以後的 ...），

我們實際把這一部份讀回來，的確也是如此的...全部為零（如下圖！）

這一部份有偷偷的問過原廠...好像他們當初拿到這個Flash IP 時，就是這付德行了！

所以啦... 您下回是使用這顆MCU 時，請留意一下這個問題。

---

所以啦 ...經由我們這樣子改寫原廠的應用工具程式時，

似乎可以幫助我們很快速的瞭解到原廠MCU的一些特性...

或許，您也可以嘗試這種另類的學習方式。

----其實，當您多學了這種PC 端應用軟體，就是增加了一種學習工具，

也是可以拿來加速您本身的學習效率的。所以啦...下回對於一些輔助工具的學習，

就不要太排斥它，因為他有可能是您下回學習的好幫手啊！ ......

下回續！ ...

--------------------

1. 改寫原廠的USB應用程式

2. 改寫原廠的USB應用程式(續一）

4.USB DIY-- 自學計畫（一）

5.USB DIY-- 自學計畫（二）

6.USB DIY-- 自學計畫（三）

7.USB DIY-- 自學計畫（四）

8.USB DIY-- 自學計畫（五）

USB DIY-- 自學計畫（四）

好吧....既然我們已經能掌握原廠USB Controller 在USB 的控制流程的話。

當然，不是這樣子就沒有事了，因為我們是不可能每個案子都只是拿著原廠的

範例程式來搞案子吧。否則，這樣子就有點囫圇吞棗...

您下回碰到一些想法比較奇怪的應用時，您就不懂得如何變化應用啊....

市面上買得到的IC ，您買得到，別人也買得到...

那您如何凸顯您本身系統應用功力呢？！...否則，您下回又得另外找一些有沒有

剛好現成的原廠就可以符合您的應用需求？！....這樣子，也未免太累了一點吧？！...

這麼累....乾脆就去原廠IC 設計公司好了...您看他們會不會一天到晚都在幫您開新IC啊？！

所以啦...我們就開始嘗試修改一下原廠的範例程式：

首先是我就把電腦上面一大堆有USB 裝置的周邊全拿掉。以免得一些USB 干擾

我的USB傳輸資料。現在才發現要買PS2 滑鼠或鍵盤還越來越難買了...

還讓我真懷念這種介面。

（所以，您就可以看到我以下的USB 資料就乾乾淨淨了...就只有我一個USB 裝置

在電腦上面！沒有那種PRE...低速裝置周邊了...）

------------------------------------------------------------------

首先我們也把那些寫Flash 的流程也拿掉...免得寫FLASH 時間，掐住USB 速度。

然後我們也把傳輸的檔案從原來4096 Bytes 把他減為1024 Bytes，

只要能通...管他多少傳輸多少長度啊？！...只不過，這一部份您是要去改原廠所附的

PC 端的應用程式。不好意思的是：VC++ 的MFC，這可別怪我說：從以前就在說VC＋＋了，

至於，您是學VB 的...嘿...嘿...我也不知道如何處理？！...

您也該不會從頭要自己搞起吧？！...這個時代搞電子就得靠別人的資源了啊！

OK...要改成 1024 Bytes 的話，您第一組Bulk-Out Command 中，就要重新定義

長度為0x0400了！當然啊因為我們把USB Device 中跟USB傳輸無關的應用程式全拿掉，

我們也可以發現可以加速USB 的傳輸速率的只不過是：他的USB Bulk out 是

用Endpoint 1，他的Buffer 只有128 Bytes ...所以啦...他每傳兩筆(packets) ，

就得停下來，然後MCU 再一個Bytes ，一個Bytes 慢慢的往外搬出來

（雖然他的MCU 是跑 50 Mhz...）看起來也還是比不上PC 端的USB 傳輸速率的

（第一與第二為#27 及#30 ...第三個因為Buffer 滿了...他就等到#146 ...

才有機會再接收另一筆Bulk-Out...）所以啦，您不要以為老是講USB 速度還不夠快？！

...真的您在USB Device 端的處理能力，

真的跟得上USB 真正的傳輸速率嗎？！....這個還只是USB 1.1的規格而已罷了，

所以呢？！...您就更不用說那種還要一來一往的HID 啦...

這是USB Controller 在先天上的許多限制，您知道的在IC 內部的SRAM (Buffer）的

成本是很貴的啦！若搞的DMA...也不知道客戶要用在哪？！...所以在設計上也不可行的！

您看：我們光只是研究探討USB 的Bulk Transfer 就可以這麼瞭解人家USB Controller 的

基本架構了。

---

接下來，我們也把那個塞在中間的Bulk-in （只回個0xFF一個Bytes 也拿掉...）

好吧，我就順便回答一下別人提的問題...您說這個是要確認USB Device 有沒有真的去

處理這一筆Bulk -Out 資料？！...好吧！就算很不幸的，您發現不是0xFF...發現錯誤了！

您的PC 端的Bulk Out 可以停下來嗎？！....

您要如何中途中斷這個一開始就定義的 0x400 的長度啊？！

（注意喔 ...萬一您傳的是那種幾MBytes...如果還停在PC 端上層還好...

萬一是停在USB 的底層怎麼辦？！....當然還有機會解的啦...不過，是比較麻煩的...

所以，我才說那個突然加進來的 Bulk-in 真的看不出他的意義？！...)

倒還不如....就讓他劈里啪啦...先傳完再說...再利用另一個命令來詢問還比較實際吧？！

----純個人觀點，接不接受，就看各位的USB 功力了吧！至少我玩過這麼多顆不同廠牌的

USB Controller ，覺得有點經驗的感覺吧！

OK ...您就可以很快的看到：我這一組Bulk-Out 在短短的幾個Packet 就傳完了

（Packet #205）。不難吧...您自個兒也可以試試看吧。

-------------------

後記：好吧，我們來看這個應用來說：因為他是用一個3 Bytes 的Command Set 來啟動

Bulk -Out Transaction，中間還塞了Bulk -In 做為中間檢查機制。

原廠這個範例程式有一個比較缺乏的範例是：他沒有提供所謂Control Endpoint 0 的

Vendor Command 部分....因為反正您都已經是掛自己的驅動程式了，

其實可以使用Control Endpoint 0 中的Vendor Command 來讓整個USB Transaction，

更具有使用上的彈性...只不過，這個作法，在USB Device 的韌體端要實現是比較容易的。

PC 端就比較辛苦了...這部分是要動到USB 底層的驅動程式：就是原廠所附的那支驅動程式。

可不是指Microsoft 的那個更底層的USB 驅動程式喔。

如果有Control Endpoint 0 的Vendor Command 會讓我們在USB 通訊協定上更具有彈性啊。

因為我們在這個範例中的那個 3 bytes Command Bulk -out 就可以移到Vendor Command 中

處理了，在Bulk-Out 的韌體程式就比較單純一點了...您可以稍微思考一下原因。

這一部份就留給大家去思考與實驗了吧！謝謝！

（待續）...

-------------

1. 改寫原廠的USB應用程式

2. 改寫原廠的USB應用程式(續一）

3.改寫原廠的USB應用程式(續二）

4.USB DIY-- 自學計畫（一）

5.USB DIY-- 自學計畫（二）

6.USB DIY-- 自學計畫（三）

8.USB DIY-- 自學計畫（五）
 

USB DIY-- 自學計畫（三）

當我們看過USB Enumeration 過程之後，接下來就要看USB Bulk Transfer部分。

一定很多人想急著進入所謂的HID Class，因為大家某種程度還是會畏懼PC 端

的USB Driver 問題。其實，大家都有點過渡緊張了...若要從USB 的基礎學起，

真的，除了基本的Control Token 之外，瞭解人家USB Controller 的基本架構，

應該是從USB Bulk 看起，而且就是因為也要瞭解整個USB 系統：

包括：USB 基本介面觀念外，PC 端的程式最好也稍微涉獵一下。

而從USB Control Token 再進入USB Bulk Transfer ...再進入HID 。

個人覺得會比較像循序漸進的方式。...原因很簡單：就是因為PC端的程式關係。

在USB 系統中：其實在PC 端的觀念，Bulk Transfer 是比較接近Control token 的。

因為：如果您扣掉Control Token 中的Setup Token與後面那組 之前的Zero Length In/Out 。

其實：他也就是Control Token 了...在PC 端的Driver 觀念：兩者也是比較接近的。

----

還有一點的是：這兩種程式架構：都是由PC 端的應用程式發起USB Transaction 的。

所以，您來解讀人家的程式時，會比較容易掌控一點。您PC 端不按"Start"...

USB 上面就是安安靜靜的...我們就以下圖為例來看：

現在PC 端的USB都已經到處插了一大堆周邊裝置：譬如滑鼠、鍵盤的...

結果您看：我們攔到USB 訊號時，已經一大堆低速裝置(HID) 來來回回的傳資料了。

而且還都是USB Device 端發起的...(圖中的Pre 就是低速裝置的PID...）

另外就是他已經先前一部佔據了USB Address 0x01 了...我們的USB只能從0x02 排起。

--------------------------------------------------------------------

以下的資料架構不是我定的...是人家原廠所附的範例程式：Bulk Transfer Example 。

我們看到了什麼？！...他全部都用Bulk In/Bulk out 來交換資料。

Endpoint 1 為Bulk In；Endpoint 2 為Bulk Out ，如果您瞭解我前文提到的觀念：

我們就應該從Bulk Out 部分先看起，因為由PC端第一發起，

而且可以全部都是Bulk Out Token。

（但是這個範例程式很不幸的：他還是在Bulk Out 過程中塞進了Bulk-in...

為什麼連寫範例程式都要整客戶呢？！存心讓別人覺得USB 真的很難的喔？！

-----

這種純Bulk Out/In 的東西有個東西很有名：就是隨身碟...他的Class 走的就是：

Bulk Only Transfer (BOT) 的 ...（當然也有所謂的CBI ...Control /Bulk/Interrupt )

但好像很少看到這一種-----這個就是我本文的前提啊！能單純使用Bulk 完成動作。

幹嘛還要拉個Interrupt 給自己寫程式麻煩呢？！...

我們看到了：他先利用一個短資料來發訊息給USB Device...

然後就批哩趴啦開始Bulk out 一大堆資料。

所以，很明顯的是：前面那個短資料：0x01 0x00 0x01 就是有點Command 的意思。

後面完整的就是真正要Bulk out 的資料。每一個Packet 均為64 bytes 。

這個範例中：他利用了一個簡單的Bulk -in (0xff) 來作資料Check ...

唉...真的脫褲子放屁...這不就是我們以前寫RS232 的觀念嗎？！

那USB裡面的那些 PID/Address/EndPoint/CRC....在幹什麼用？！...

就是幫我們處理這些是啊？！...在正常的Bulk Out 傳輸中...塞了這一個Bulk-In

 只會破壞USB DEVICE的韌體程序完整性，也讓PC 端程式複雜...

但對我們傳資料的準確性一點幫助都沒有...您看下圖中：他每傳完512 Bytes 時，

就要求Bulk-In 一個0xFF...幹嘛？！...只是讓整個USB Bus 的傳輸頻寬都在那傻傻的

回NAK.....NAK....Nak....Nak....Z..Z..Z..z..z..zz...（喔後面那個Z 代表我們睡著了！）

終於等到了....您看前面的Packet #...從2092 等到 11906...夠久了吧！（下圖中）

您不相信我說這個Bulk-in 一點都沒用的意思...我就最後一個Bulk Out/Bulk -in 來解釋：

您看下圖：當您Bulk- Out 完了之後...就回您的Bulk-In (0xFF)...

要幹嗎？！...Bulk Out 自己最後一個Token 不就是一個Ack 嗎？！...

那這個Bulk -in 0xFF 有要取代這個ACK 意味？！...

不好意思 ...人家那個ACK ...人家Microsoft 底層的Driver會幫您處理或重傳...

您這個BULK In 還要勞駕您的PC 軟體與USB Device 韌體耶...您也沒比微軟厲害啊？！

---

不過啦...這個程式鐵定傳輸效能很差的啦...這不是他的重點....

他只是要讓您瞭解什麼是純 Bulk Out/In 觀念。----

但您自己跑過一遍就可以很快的抓到訣竅了嗎？！.... ?! ... ???...?.. ?..

----

這個範例程式主要是用來Bulk 一些資料...但我要如何從Device 端驗證資料呢？！

答案就是：直接把傳輸資料寫進MCU 本身的Flash ROM裡面...

靠...直接韌體更新升級...太炫了...但很不幸的 ...原廠沒有提供快速的檢查、瀏覽工具程式。

對我們學他的USB Controller 又是一次的 Orz.....被打敗了！...

----

唉...幸好版主有先見之明...前兩天改寫了原廠的工具程式：

讓我們察看結果：快速又容易啊...學USB 真的是輕鬆上手啊。您說：是不是？！

（答案果然是我們所傳的固定格式的資料內容: 0x00 0x01 0x02.... 0x0F.....0xFF..）

----

不錯吧...跟版主學USB簡單容易吧... ....

（待續）！

----------------------

1. 改寫原廠的USB應用程式

2. 改寫原廠的USB應用程式(續一）

3.改寫原廠的USB應用程式(續二）

4.USB DIY-- 自學計畫（一）

5.USB DIY-- 自學計畫（二）

7.USB DIY-- 自學計畫（四）

8.USB DIY-- 自學計畫（五）

休假取代砍人 竹科未見大波裁員潮（轉載）

----最近發現去園區停車變得比較方便了...還有，

在強迫休假下，工程師們您真的有賺到了嗎？！...

還是您會擔心您在被迫休假下，您未來是否也有存在一定的風險啊？！

而且最近因為國際景氣的關係...連國外的一些常見的IC也出現所謂的『變現倒貨』。

更加使得國內一些IC設計公司面臨更嚴酷的價格毛利保衛戰！

所謂的以人為本至高表現...卻是一步一步無形中流失企業本身的競爭力，

結果往往造成公司內部所謂"大鍋飯文化"...唉...為難老闆啊。

-------------------------------------------------------------------------------

http://tech.chinatimes.com/2007Cti/2007Cti-News/Inc/2007cti-news-Tech-inc/Tech-Content/0,4703,12050902+122008120300123,00.html

工商時報 2008.12.03　
休假取代砍人 竹科未見大波裁員潮
李純君／新竹報導

    　全球景氣驟降，為避免大規模失業潮出現，竹科管理局長顏宗明近期以發公開信與逐一拜訪的方式，期勉企業主能以調整經營模式等替代方案取代大規模裁員，也因為管理局的道德勸說策略奏效，加上諸多科技業者心存仁慈，即使廠商苦撐至今、員工無薪假越休越長，但竹科尚無大波裁員潮出現。

    　在全球性的金融風暴持續擴散下，台灣科技產業首要重鎮的新竹科學園區也難逃衝擊，區內廠商遭遇史上最嚴苛的生存考驗，而竹科主管機關的管理局在察覺到市況的嚴重後，竹科管理局長顏宗明首先發出一封公開信給各公司董事長，以道德勸說方式希望廠商不要裁員，也在近幾週內逐一拜訪竹科業者，勞資雙方並能取得共體時艱的共識，更希望今年內竹科內都不要出現大規模裁員的案例。

    　也因為竹科管理局防範於未然的道德勸說策略奏效，加上竹科多數企業者以人為本的信念，即使竹科廠商急於降低成本、減少損失，但所採行的策略多以遇缺不補的人事凍結、鼓勵員工輪休或是休無薪假、鼓勵員工快點把特休假休完以減少員工以假期換薪水的頻率，甚至減薪等為主，即使有少數廠商以資遣、優退等方式讓員工自行離職，但至今竹科內還沒有大規模的裁員潮出現。

 

最近的網路笑話

如果依其原始的想法的話：應該有很多科技產業都可以套用此一邏輯!

您就自己加自己的吧！

----Chamber

---------------------------

真慘---不信你看
黑夜。一女遭遇劫匪。8
顫抖曰："大哥，我是賣DRAM的，兩個月沒發工資了，
還剛被裁員，你看報導就知道了……"劫匪聽後竟然痛哭流涕。
"妹子，同行，俺原來是賣的FLASH，後面那幫搶劫是做模組的，
你放心，我們絕不搶自己人.
對了，邊上那條路不要走，那邊是賣CD-Rom的。
....................................................
沒路可走了.另一條路還會遇到做LED的....
....................................................KQ-
妹子,以後還有面板的會加入我們的
....................................................
右邊巷也別走,他們是鴻海的mm

JPT ---您要加油 !

昨天以前公司同事正式發郵件告知版主說：J 罹患鼻咽癌末期，已經暫時離開工作，

返回老家作化療與養病了。這件事前幾天版主才輾轉聽到此消息，

也有在部落格提到此事。看到郵件內容所述的一切，讓版主不禁憶起昔日並肩作戰的情景。

J 是台清交大的高材生，一畢業就進入公司負責IC設計工作。

而版主負責驗證IC與系統架設與發展...當初因為市場產品方向都尚未沒明確。

公司也沒有投太多設計資源，結果J 就一肩扛起設計工作。

IC 設計本身本來就是相較於系統設計來說：就是比較枯燥與單純。

所以，以前在公司的專屬吸煙室裡，常常看到IC設計者們聚集吸煙解悶。

當然J 也是常客之一...雖然明知吸煙對身體不好，但您又何忍心剝奪他們生活上唯一的嗜好呢？！

當初公司內這條產品線的工程師們來來去去的改朝換代好幾批...（當然版主也是其中一位！）

但唯一從公司開始發展此一產品技術時，J 就一直堅持此一崗位到目前為止。

但畢竟人不是鐵打的...人也是有血有肉的軀體。J 病倒了...

J 成家立業都是在該公司完成的，老婆也是大家所熟悉的老同事。

連董事長都很支持這位自己的老學弟....實在是有太多的回憶都不禁一一的浮上心頭。

-----

J 您真的要加油啊...不是要您在IC設計工作上加油；而是要在您生命中加油。

在此真的要為您好好祈福...希望您要努力，堅強好好加油喔 ...

希望還有機會跟您合作！畢竟當初在我們合作之下，在別人不怎麼看好的條件下，

我們也交出一筆好成績，也希望您在戰勝病魔的過程中，也能交出一筆好成績。

---- 加油！ J....您要好好加油喔！...祝福您！...

USB 裝置的主從控制想法

這的議題是因為我今年主要的一個USB應用程式的成形讓我覺得USB DIY應用更上一層樓，

而這樣子觀念我個人覺得是可以延伸到其他應用領域：譬如PC 應用程式之機器人伺服馬達的即時控制。

然後，因為好友林老師他今年要玩機器人控制時，個人的一個小小意見：

http://chipware.myvnc.com/phpbb/viewtopic.php?p=1036#1036

或許大家會覺得這樣子的東西應該跟一般HID 有點像喔...

一般所謂的 回饋式的遊戲搖桿是這一種嗎？！....

我個人覺得應該還有一些不一樣...

第一：回饋是搖桿的PC 主控控制單元不多...只有一個直流馬達而已也不需做到精準的時間控制...

等您要控制的馬達多一點，而且是要作定位控制的！（USB DEVICE回傳多...下傳接收不多！）

第二：當您利用HID 把資料回傳PC 端時，您的上層的應用程式才會知道，

然後，再重新利用應用程式把更新資料在重新往下傳到OS 的驅動程式端....

在傳出時，您有可能要跟其他PC正在執行的其他應用程式搶作業系統的資源時，

發生時快時慢的時間間隔（就算是用常駐程式寫，也是一樣的！）。

-----

或許大家有更好的方法，我也不敢說我的方法最好。但畢竟我把他給實現了。

所以，我就可以把機器人調伺服馬達動作（就是要調整機器人整體動作！）

可以在PC 端即時的設定動作...然後可以完成預覽-->設定--->下載儲存--->脫機

--->完成機器人自行調整各個伺服馬達動作完成一連串動作！

就如同我在USB2DMX 的操作影片流程一般。

（謝謝影片中，連我那個念小學的兒子也可以輕鬆上手操作這樣子的軟體設定。

這不就是我們希望玩機器人可以普及化的想法嗎？！）

或許大家可以提出想法討論！...謝謝！...

-----------------------------------------------------------------------------------

原文的說明如下：

http://chipware.myvnc.com/phpbb/viewtopic.php?p=1036#1036

-----
我想這個東西有點像我今年寫的一個程式：USB2DMX...

http://www.youtube.com/watch?v=BcpXkgfyoJo

...
我稍微提一下這樣子的程式觀念：
主要就是所提到的如何利用程式中的『滑桿』的動作能做到Real time 控制Device 端的動作---原來的我LED應用中就是LED 節目與速度的改變！而若是伺服馬達的話，就是伺服馬達的作動。
這樣子的控制流程的最大問題是：明明是由PC程式端來下達Device 端動作的改變；但是呢？在時間控制軸上來說：應該由Device 來決定動作的改變。...
因為LED 什麼時候完成PC指定動作，可以在接受下一個PC指定動作。
（伺服馬達什麼時候完成PC指定動作，可以在接受下一個PC指定動作。)
只有Device自己最清楚的...否則，在時間控制上會亂了章法的...
會讓LED 跑起來時快時慢（伺服馬達也會一下子正轉...還沒定位又要反轉...)
----
而以目前PC 端的應用程式對於周邊裝置的驅動程式來說，
是很難精準的做到時間間隔一致---除非您要寫一支常駐程式。
（以現在龐大的視窗作業系統來說，常駐程式真的不容易寫也不容易維護的！
也容易發生掛平台兼容性問題！）
那更不說想用VB 來寫這種程式啦....（譬如利用VB ＋RS232 來寫！）
--
我當初唯一能想到的就是USB還有機會...
但又一定要USB Device 的Firmware 的強力支持，
在搭配PC 端的應用程式與底層驅動程式的相互搭配才有機會完成。
因為畢竟只有在Device 端才能精準的時間控制...
because 在Device 端的Firmware 只有服務本身功能，不像PC 作業系統這麼複雜。
而以USB裝置來說：明明USB裝置是一種被動的周邊裝置（以主從觀念來說！）
怎麼又可以做到USB 裝置來主控與PC 端應用程式之間的即時資料交換呢？！
---
這個就是我所要說的：如何利用USB Device 的Firmware 搭配USB
驅動程式與PC上層應用程式端的交互整合才可以完成這樣子的觀念。
---
其實，當初這個觀念在我動手作這樣子的系統規劃時，我自己也沒有把握可以完成?因為真的不容易達成的....但事實證明我的想法沒錯的！
所以就完成了這一組 USB2DMX的系統設計。
我想同樣的觀念是可以延伸到利用PC應用程式做到這種伺服馬達的即時（Real-time) 控制的！
---
個人的小小意見！