2008年12月30日 星期二

蘋果傳奇背後的影子創辦人(轉載)

上週網路找資料時,發現了這篇文章....
 
總覺得我們這些投身高科技的工程師,如果您還是有一點從中可體會到那一絲絲的研發精神的話,
 
我想您可以從這篇文章體會到一點認同感吧...
 
所以啦...週末我就跑到書局買這本Steve Wozniak 的傳記書(遠流出版社),
 
花一個週末假期就把他K 完了...
 
或許,您會覺得在高科技業裡,懂技術或與公司經營總是在天平的兩端的話,
 
我想您也可以從這本書內可以略知一二,只可惜的是:我們台灣沒有人家美國那種創業精神與
 
龐大市場吞吐量吧... 所以,相對的,也凸顯我們台灣高科技工程師的另一種宿命吧!
 
----如果,您有空的話,譬如無薪假時,或是元旦假時,您也可以翻翻這本書吧!
 
(註:書中他描述了當初如何一開始使用一棵現在看起來毫不起眼的單晶片 6502 只跑幾MHz 的情形下,
 
創造出第一台個人電腦...還有後來如何使用SRAM/DRAM....及磁碟片過程...蠻神奇的!
 
還有一段就是他當初很掙扎要不要離開大公司:惠普(HP)...他原本他是可以在HP呆一輩子的...
 
這也是他原本設定的人生目標...他在HP大公司過得很舒服...也還可以到處兼差...。
 
他當初跟創業金主問了一句話:"我為什麼不能繼續把這件事當成兼差,(註:設計蘋果一號)
 
把惠普的工作當成終身工作保障呢?!"
 
,他甚至直接拒絕了創業金主的邀約,放棄蘋果公司...最後卻是引他進入惠普的好友同事--鮑姆,
 
跟他說了一句蠻貼切的話....他還是離開HP而創業...----這一段過程是蠻精彩的!)
 
------------------------------------------------------------------------------------
http://www.businessweekly.com.tw/webarticle.php?id=27769&p=1
 
蘋果傳奇背後的影子創辦人

他發明了Apple電腦,他給iPhone打七十分

沃茲尼克,他是蘋果兩位創辦人之一,也是影響個人電腦歷史的關鍵人物,卻遠不如賈伯斯出風頭,他是一位天才,更是一位勇於「創造不同」的工程師……

文/鄭呈皇


談起蘋果(Apple)創辦人,你會想到誰?幾乎所有人都會異口同聲說:「史提夫‧賈伯斯(Steve Jobs)!」但這只答對一半。事實上,蘋果創辦人有兩位,另一位是史提夫‧沃茲尼克(Steve Wozniak)。

七月十九日,《商業周刊》獨家越洋專訪這位蘋果背後的隱形天才,撥到舊金山後第一句話是:「哈囉,我是沃茲尼克!」原來創辦人沒有專人轉接,毫無架子。

專訪中,談起賈伯斯主導、正當紅的iPhone他說:「是一個不錯的產品(product)。」但聊自己發明的蘋果二號,等不及記者問完立刻興奮說:「這真是一個好的發明(invention)!」

一九七六年,二十六歲的他與賈伯斯創立了蘋果,並發明當時全世界最暢銷的電腦:蘋果二號。超過一百萬台的業績,讓他三十歲就成了億萬富翁,媒體封他「電子奇才」。

然而,當年他頂著大鬍子、大鏡框眼鏡,外加一頭「飄逸」長髮,典型我行我素的「工程師」打扮外,加上不願曝光的個性,讓他對比愛出風頭的媒體寵兒賈伯斯,宛若太陽背後的影子般。

他與賈伯斯完美工程師碰上企業家工程師

當年「雙S」主政時,賈伯斯負責對外行銷業務,而沃茲尼克則負責對內研發工作。原本外界稱羨的絕佳拍檔,最後卻因為彼此理念不合,加上沃茲尼克打算發明「萬能遙控器」,創立新公司,於一九八五年人生顛峰之際離開蘋果。

如今,鉛華洗盡,他成為一位教電腦課超過十年的小學老師,並成立網頁,解決全世界任何關於電腦的問題。

這位「影子創辦人」,浮出檯面。全因一場排隊與一本自傳。

六月二十九日,正當蘋果迷湧至紐約市中心的蘋果專賣店,花了數日排成一圈圈、上千人的長龍搶購iPhone時,同時間位於加州,身穿白色T恤、戴鴨舌帽的沃茲尼克,凌晨四點半就到住家附近的專賣店,跟著人群排隊,終於在太陽露臉後買到手機,而這一幕恰好被媒體拍到。問他為何不直接打通「特權」電話,「我喜歡那種走入人群排隊的感覺。」他在電話中笑著回答。

另一方面,在八月推出的中文版自傳《科技頑童沃茲尼克》(遠流出版)裡,他自暴與賈伯斯的關係。兩個「史提夫」,雖是最好的朋友,卻也是最親密的敵人。「我們終究不是同一種人,從一開始就很不一樣。」

的確,和賈伯斯這位「企業家」相比,沃茲尼克就像一個要求完美、執著的工程師。他的第一任妻子形容他,是那種回家繼續研究電子到半夜的老公。然而,要求完美的工程師比比皆是,為何獨有他發明改變世界的個人電腦?「和絕大多數工程師比起來的最大差別,就是沃茲尼克有『夢想』,那種源自工程師的最單純渴望……,要『創造不同』(Make a difference)。」自傳的中文翻譯者、《環球商業評論》發行人王志仁如此評論他。

從蘋果創辦人到小學老師,沃茲尼克的人生同樣「創造不同」,與他發明蘋果電腦一樣的精彩。 最初,是從一間昏黃的木屋小房間,與一塊不過五十公分的小黑板,開始沃茲尼克的「夢想」。

他與電腦發明做到冒煙、爆炸仍不放棄

「我從小就想當一個改變全世界的工程師。」他說。一九五○年代,當別的小孩都在玩球、盪鞦韆時,不過小學二年級的沃茲尼克就會獨自窩在房間裡,研究電子學,並把家裡的電線拿來到處組合,遇到不懂,就會拉著在洛克希德(Lockheed)飛彈部門工作的父親問問題。而沃茲尼克的父親,利用每天下班後向他解釋什麼叫做電阻、電子。此外,更會把發電原理在他眼前實驗一遍。「我父親教我如何追根究柢,這個能力一直是我發明產品的動力。」沃茲尼克說。

這個階段持續到初中畢業,父親在木屋昏黃的燈光下,在小黑板上畫圖,替他開啟電子學的浩瀚探索。

直到他創立蘋果電腦前,他一直都沉浸在發明電腦的美夢中。當時電腦一台動輒數萬美元,一般家庭負擔不起,只有大企業會使用電腦。另外,電腦也相當不方便使用,必須要會各種程式語言,並且用打孔卡片輸進資料,再到旁邊的控制板上看結果。

「我每天滿腦子就是想做出一部『簡單』的電腦,改善人們的生活。」他說會想做蘋果一號,純粹是想改變現狀。

於是在高中、大學念書時,沃茲尼克只要有時間,就會拿著鉛筆在紙上畫電子線路圖,那時的沃茲尼克就想「有沒有辦法設計迷你電腦給一般人記帳?或者其他用途?」但當時光是處理器就要數百美元,等同一台車的價格,根本無法普及化。他心想,有無可能用最簡單、最少的零件,組好一台電腦呢?當他把這些想法跟同學講時,別人都當他「瘋子」。但他不在乎,在設計蘋果一號之前,他在車庫裡設計過不下十台個人電腦,幾乎都是一通電就冒煙、甚至小爆炸。

冒煙,爆炸,依舊阻止不了沃茲尼克的夢想。為了窮究答案,研發出個人電腦,一九七五年初開始,他白天在惠普(HP)上班,晚上畫設計圖,聽到哪裡有賣需要的零件,就請假開車去買。

終於在一九七五年六月二十九日,他累積上千張設計草圖後,成功組裝一台電腦,並能在螢幕上跑出程式結果。「這種感覺就像打高爾夫球時,在四十英尺外一竿進洞。」他在書上寫著。

而這也是他與賈伯斯一九七六年成立蘋果後的第一個產品:蘋果一號。一次成功已屬不易,但沃茲尼克卻不休息,依舊滿腦子想著如何用更少的零件,設計出「更簡單」的電腦,更符合人性。不到一年,蘋果二號的螢幕成了彩色,零件只有一號的一半,而且開機更快。這項產品也讓蘋果在一九八○年十二月,在美國那斯達克(Nasdaq)上市,並隨即躋身《財星》(Fortune)五百大企業。

「永遠要從人們的需求去瞭解、設計產品。」沃茲尼克說,這是蘋果創立時就存在的精神:「從人性出發。」但這精神隨著蘋果越來越大,開始轉以賈伯斯所重視的市場行銷為導向,而這也種下他們日後分道揚鑣的關鍵。

關鍵是一九八一年推出的蘋果三號。蘋果三號並非沃茲尼克所設計,「主要是上面的委員會與行銷部的想法開發出來。」沃茲尼克在書上表示,「這是一個極大的錯誤!」

他與蘋果公司反對行銷主導,終至出走

因為想要吸引所有消費者目光,於是蘋果三號將所有電腦的功能如印表機、試算表等各種軟體、記憶卡等所有附屬功能全都「內建」。如此的美意卻因為使用者不會開機,程式設計繁複,導致高維修率。「這個產品後來虧損至少十億美元。」沃茲尼克書上表示,當下他就明白這是一家「重行銷」的公司,與他創立之初那種創新精神背道而馳。

這也代表他和賈伯斯的立場不同,而開始出現爭吵。「我覺得賈伯斯最大的缺點就是脾氣很不好,常常對員工生氣。」沃茲尼克接受採訪時明白指出。最後在一九八五年二月,沃茲尼克離開蘋果,而當時的革命夥伴賈伯斯並沒有出面慰留。

之後他創立一家CL9公司,為的是發明一種「可以用一個遙控器操縱所有家電」的產品,這點子在二十年後的現在還是很先進。可惜三年後,因為沒有市場,與產品研發不順,其中,賈伯斯甚至要求自己合作的代工廠不准幫忙CL9,使這家公司關門大吉。這個改變電腦歷史的電腦奇才,並沒能繼續發明出「偉大」的電子產品。

「我發現自己以前可以很有生產力,但如今卻不一樣。」天才發現自己的極限,只好認輸。這時的沃茲尼克,轉而關心自己的小孩,開始教他的女兒電腦,並且開始在學校教書,一教就到現在。

問他會不會懷念以前創辦人呼風喚雨的日子,沃茲尼克想了想說:「我現在快樂多了!」但一談到現在當紅的iPhone,他不免又流露完美工程師性格,給它「七十分」的評價。「可以再做的更人性化一點!蘋果的精神就是要從人性出發。」他挑剔著賈伯斯引以為傲的產品的口吻,彷彿昔日那位創辦人又再度回來。

有能之士多如牛毛,多半只能改善歷史,極少能改變歷史。問他兩者的差別在哪?沃茲尼克沉思後說:「勇於思考不同,並能夢想。(think different and have a dream.)」

台灣有的是數不清的工程師,或者創業成功如賈伯斯般的「工程師企業家」,但是,「有夢想並敢不同」如同沃茲尼克的工程師,卻何在?

給年輕工程師的三個忠告

想要與蘋果創辦人沃茲尼克擁有同樣的發明熱情與成就嗎?在《科技頑童沃茲尼克》一書中,他給了以下幾個建議:

一、這個世界並不是黑白分明的。
首先你必須相信你自己,不要輕易動搖。大多數人看事情總認為他們是對的,其他人就是錯的。身為發明家,你必須用灰色的尺度來看事情,必須開放,不能隨波逐流。你必須絕對客觀,忘掉你曾經聽過的所有事情,把桌子清乾淨,像科學家一樣實事求是,探索真相。

二、成為工程師中的藝術家。
為什麼我說工程師很像藝術家呢?因為工程師通常都拚命想把事情做到盡善盡美,達到即使自己都認為不可能的完美境界。我們撰寫一段段電腦程式碼,就好像畫家以畫筆塗抹色彩,或音樂家編織音符一樣。追求完美並且用別人不曾嘗試過的方式,讓工程師成為真正的藝術家。

三、自己當家作主。
當你在組織嚴密的大公司上班時,比較沒有機會憑一己之力將聰明構想變成革命性的新產品。不幸的是,我們在這社會,資助你研發的都是些生意人,他們規定誰擁有什麼權利。因此要保護自己的心血,或應付一堆無聊企業文件,很不容易。如果你是個想要改變世界的年輕發明家,不要誤入企業的環境裡。一定要懂得獨自工作,而非只是團隊的一份子,才能設計出最好的革命性新產品。並利用公餘之暇,憑著有限的資金和資源進行自己的研究計畫。

2008年12月29日 星期一

劈腿 當心!》人中之龍?

喔...在整理電腦資料中,發現這一篇賈老師昔日的文章之一。
雖然是三年多前的文章了,但是如果套上今年不景氣的狀況來看,
似乎還有一點蠻貼切的......

2008年12月25日 星期四

8位元世界中的32位元MCU應用(轉載)

這也算是呼應我之前那篇32 位元MCU 的文章...

這其中應該有許多事值得我們用另類的思維....!...

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

http://tech.digitimes.com.tw/ShowNews.aspx?zCatId=111&zNotesDocId=0000102696_1BO7A4N18G52HA7JNWVH1

-----

8位元世界中的32位元MCU應用
(寄信給作者)2008/08/25
 
台北訊

全球MCU市場出貨量預估將在2010年超過150億顆,其中,32位元MCU的成長速度,更將是傳統8位元的三倍。許多目前採用8位元MCU的裝置,都將逐漸被32位元MCU所取代。32位元MCU裝置的成長,受到不同市場力量的驅動,其中包括重複使用程式碼的需求、應用複雜度的提升、裝置的逐漸匯整,以及系統的連結。然而,在此同時,廠商仍需考慮成本追加的限制及產品上市時程的控管。

由於8位元MCU移轉至32位元牽涉為數眾多的架構平台與協力廠商,因此在過去被視為不可能的任務。但由於現今程式碼密度與長度的演進,加上矽元件製程的改良,使架構平台匯整的目標得以實現,並使32位元裝置的版圖,能首度拓展至過去由8位元與16位元應用所主宰的低成本市場。




8位元與32位元MCU市況

32位元MCU跨足8位元與16位元的既有市場,原本就會面臨不少挑戰,再加上可預見的未來,將出現低於0.5美元的量產產品市場,或其他矽元件廠商無力觸及的超低成本應用領域,更讓32位元MCU的普及受到限制。雖然如此,市場上仍有為數可觀的應用,讓32位元MCU裝置有機可乘,開始挑戰既有的8位元及16位元市場。例如:Luminary Micro推出超過百款從1美元量購價起跳、搭載ARM® Cortex™-M3處理器技術的MCU。此外,包括Atmel、ADI、NXP、STMicro與TI等許多廠商,也紛紛推出一系列搭載ARM處理器技術的裝置。

上述廠商推出的32位元MCU裝置,提供了比其他平台更高的單位價格效能,並在數量上快速超越了傳統的8位元設計。這些32位元MCU被廣泛應用在無數的電子裝置中,包括遙控器、待機模式控制器、警報系統、電子投票機、家用電器、廚房用品控制器,以及整合許多8位元系統的汽車與資料登入應用。

程式碼長度

部分工程師在決定是否轉換至32位元處理器時,最主要擔憂就是轉換會使程式碼長度大幅增加。但是,許多案例顯示轉換事實上簡化並縮短了程式碼。此外,許多8051指令仍需2或3個位元組,而ARM Thumb®-2指令卻更簡短,且能完成更多工作。

ARM Cortex-M3處理器中的Thumb-2技術等32位元指令集應用,能夠提供更精簡的程式碼與更快的效能。舉例來說,經由Cortex-M3處理器編譯後,推動堆疊中的3個暫存器,以及將它們取出及置回的程式碼,總數僅不到原本的三分之一。

事實上,在最近幾個採用EEMBC業界標準程式碼所進行的獨立標竿測試中,證實了一組先進8051裝置的完整程式碼長度,較Cortex-M3處理器程式碼多出3.6倍。同時,Cortex-M3處理器所提供的效能,更高出該8051裝置有十倍之多。

資料格式的一致性,是比較程式碼長度時的另一個重要考量。在16或32位元指令中,一個指令的長度可能是2或4位元組,但ARM的工具會自動執行轉換,使程式碼長度永遠以位元組為單位。反之,Mircrochip等其他廠商將程式碼長度標示為指令字元,要開發業者自行將數據乘以指令長度,因而經常造成混淆。

MCU中斷處理能力

新一代32位元MCU的中斷能力遠勝於傳統MCU裝置,且提供遠超過傳統8位元裝置的簡易使用度與彈性。新一代的MCU系列,如採用Cortex-M3處理器的Luminary Stellaris與STMicro STM32,都提供超過32個中斷,並支援8或16個優先順序。此外,處理中斷的所有暫存作業都是由硬體自動處理,這不但提供了一個極為簡單、可靠,且可重複的解決方案,也意謂著所有中斷處理裝置都可撰寫成一般的C語言函式,而無須使用組譯程式。將中斷控制器整合至中央核心亦帶來許多其他先進的功能,包括無限制巢套、優先遮罩,與關鍵優先無遮罩中斷。

以Cortex-M3處理器為基礎的32位元MCU,其性能大幅領先8051架構裝置,甚至是效能高於標準8051架構八倍之多的最新一代「加速型」8051架構。雖然許多最新的8051裝置宣稱其中斷延遲僅有5或6個週期,但這並不包括開始處理中斷時所耗費的大量資源。

Cortex-M3處理器的12個週期中斷延遲,包括了將暫存器推入堆疊、取得特殊向量,及擷取ISR指令所耗費的時間。從下表的比較中,我們可看到Cortex-M3處理器的中斷延遲,比加速型8051裝置還要短,而這類加速型裝置的速度已經較標準型8051裝置快上8倍。在許多其他的8051系統中,這些延遲甚至會更長。



位元處理運用的重要性


在32位元與8位元MCU的比較之中,位元處理層面也必須被合理的考量。過去十年,大多數的32位元裝置都著重於資料封包處理,而忽略了真正控制工程所需的個別位元運用。然而,最新一代的32位元裝置已重新開始注重這塊領域,且能夠替個別位元與位元控制提供優異的效能。例如:Cotex-M3處理器定義兩類記憶體,一者是內部SPAM,而另一者為週邊記憶體,能夠提供個別位元達到類似自動化的效能。

此外,在加入支援位元處理作業的一組新指令後,僅須單一指令即可插入、清除或交換一組可編程位元。舉例而言,想要改變資料欄位中的3至5位元,8051架構裝置需要9個位元組與6個時脈週期,但若運用Thumb-2中的位元欄位插入(Bit Field Insert)指令,則僅須4個位元組與1個時脈週期。

工具整合優勢

儘管32位元MCU具備許多優勢,許多開發業者對於嘗試這些新裝置所需的巨額投資,仍存有疑慮。但事實正好相反,許多8位元開發業者所熟悉使用的工具,如:Keil和IAP工具套件,都已支援32位元裝置。(版主註:IAP 應該是誤植了...我想應該是IAR。)

由於整合了使用熟悉的開發環境,因此,改寫大部分的C語言程式碼變得十分簡單,整體開發也更容易。近來,隨著採用Cortex-M3處理器的32位元裝置陸續問市,為這些裝置撰寫程式碼所需的知識門檻也大幅降低。

應用的日趨複雜、裝置匯整,與連結MCU的興起等因素,都持續促使市場邁向效能更高的32位元MCU裝置。最初為了提升程式碼的重複使用性,並降低各部門的成本,而在業界興起平台整合趨勢,卻在最後無心插柳地將這些高效能裝置,帶向始料未及的發展境界,並直接挑戰了傳統的8與16位元裝置市場。(本文由ARM安謀科技股份有限公司資深行銷經理Hayden Povey提供)

 

2008年12月23日 星期二

再造一棵 USB Controller 的傳奇故事(一)

我個人覺得這是一個在這個高科技不景氣中的一個小故事!

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

今年年中我在我另一個網頁中有提到一個關於USB Controller ROM Code 的問題。

http://chamberplus.myweb.hinet.net/usb_bindex0.htm

我想當初一定很多人很好奇的想瞭解我到底葫蘆裡賣的事什麼藥呢?!

其實,這一個計畫想法當初在我腦中浮現時,我自己也沒有把握可以辦得到!

但是呢?!就衝著我們這一棵GT6816 USB Controller 長青樹說什麼也要挑戰一下。

最近有人偷偷的告訴版主說...這一棵IC 還在穩定出貨中,還蠻長壽(已經近九年了),

而且他所創造的經濟效益也蠻不錯的,當初所寫的USB Firmware...一路歷經WIN 98SE、

Window NT、Winodows ME、Windows 2000及 Windows XP...歷久不衰。

當然啊...Vista 不小心在WQHL 的測試跌了一跤,去年還幫現在的原廠出身解此問題!

http://chamberplus.blogspot.com/2007/04/usb-vista.html

http://chamberplus.blogspot.com/2007/04/usb-vista-part-ii.html

http://chamberplus.blogspot.com/2007/04/usb-vista_20.html

雖然,人家版主不是這一棵IC的設計者...但卻是他的著著實實的系統開發者,

也唯有好的系統開發者,才能真正的發揮SOC 的最大效益。

記得有位同在IC設計業的好友提及:他找人、用人...都不會想問他做過什麼計畫?!

只想問他說:您所參與或所開發的IC(或產品)賣過多少數量?!...

想一想也蠻有道理,有些人公司來來去去,所參與的開發案一大堆,

但卻沒有多少市場量產歷練...或是幾個成熟產品持續販售?!

----------------------------
好吧...我們就稍微談一下這樣的一棵USB Controller 還可以在USB系統應用中,

還可以激發出怎樣的新一代的產品應用?!

首先,以當初的設計理念是:考慮到說USB 產品,莫不一定跟PC 有關或是跟USB Host有關!

所對應的也一定有所謂的HOST USB Driver...所以啦...這顆IC 在出貨量產中,

根本不需要馬上燒錄程式到此IC 中...而當他與USB host 連線時,

再由USB Host依據系統應用條件規格,再下載系統應用韌體就可以了。

(意思就是說:業務先出貨收錢...工程上有問題,再留給FAE去慢慢解到『脫肛』吧...

業務馬上有業績...而工程部門呢?!卻被客戶屌到、罵到臭頭....您就知道這種生意多好作啊!)
 
理所當然的...此韌體也可以隨時更新的。就是一個這麼簡單的想法:

大家可以參考下圖中:此GT6816 中的8051 就是透過USB -->經DMA3 -->Data buffer

再經由DMA1 ---> Update 8051 的程式碼庫(8 KByte)。

而在DMA1 更新8051 的程式庫碼後,在硬體上他也會自動的重新Reset 8051。

跑所更新的8051韌體...

----
好了...因為這一棵的USB Controller 中的8051 是跑48MHz 中1T~2T 的8051...

意思就是說:他跑一個NOP 只有20.8333 nsec。又有USB 連線功能。

所以,以今日的許多系統應用角度來看:還是蠻好用的。

因為有USB DMA 的 USB Controller 還蠻少的!

好吧...既然要拿這一棵有USB 的8051 Controller來用的第一個問題就是:

我該如何反過來:讓他一開機時,是脫機(Stand-Alone)運行的? 因為沒有USB Host在!

更不會有 USB Driver 來幫我們來下載或是更新Controller 中8051 韌體?!

譬如說:一個我原本所開發的USB Based 的MCU 燒錄器,是不是可以轉換成脫機燒錄器呢?!

這樣子,一來可以利用PC 的USB 連線功能來隨時調整IC 燒錄功能,

當系統一切穩定,或是要加速燒錄IC 加工速度的話,我們只要把這個原本需要PC USB 連線功能的

系統裝置轉換成脫機燒錄器,而且啊,還可以隨時利用USB 連線功能再回到PC 端更新系統啊?!

所以啦...就延伸了我使用這一棵USB Controller 升級第一版:USB Controller 脫機運行。

成果就是真的完成了一台原本USB 連線的MCU 燒錄器,順利的轉換成脫機燒錄器!

(您看還可以USB 供電燒錄的哩...多有環保概念啊!)

圖中靠近USB 接口那一個就是需要跟PC連線時,只要輕輕一按就可以跟PC 連線了。

可以用來更新燒錄程式碼...或更新待燒的MCU 程式碼...

如此一來又方便又可以有效管控MCU 燒錄流程!

(當然啊...對於這一棵USB Controller ,版主第一個比較成功的產品就是USB ROM 模擬器啊!)

----
當然啊...當我完成這一個當初此IC 設計時,或是此USB Controller IC 開發時,
 
想都沒想得到的應用時,就讓版主想一直想挑戰這一棵USB Controller 的系統應用極限!

第一部完成脫機運行之後....總覺得只有8 Bytes的 ROM Size ,對於一些特殊應用還是不夠的...

所以啦...接下來,就是想挑戰超越 8kBytes ROM的限制,乃至於挑戰超越 8051 標準

64KBytes 的應用程式庫極限!

啊...那您們說:這個超級任務有成功嗎?!...那就拭目以待!

(待續!)

-----------------
後記:最近媒體一直在炒所謂的不景氣的高科技裁員風或是放無薪假...

當然,大家都可以秉持著一種看戲或是瞎其鬨的心態,但是呢?!

真的如果這件事情發生在自己身上的話?!

我自己該有何備案啊?!...我真的有獨立的一技之長嗎?!...我在高科技業裡真的有練就一身武藝,

可以獨善其身的以保全身而退嗎?!....還是我的生存之道非得靠人家大公司的庇蔭?!或是,

搭在別人的成就肩膀上?!...而樹倒會不會胡猻散?!...落得一身清(清貧的清)?!

而當我發現其實以前我們所經歷的許多成熟產品還是有許多附加價值的,

只是我們都沒有好好的去發揮,尤其是一些在系統應用上可以好好發揮的Good ideas。

當然啊...除了這種老而彌堅的好產品外,新的性能優異的產品我們也不用刻意的排斥。

您看版主也有留意到其他品牌的USB Controller...這就是基本的學習態度:溫故知新

管他景氣如何循環...我們還是在我們所擅長的一個領域裡耕耘...只有您讓老闆有機會Fire 您...

您可不能讓您自己的競爭力被這個社會給Fire 掉啊!...大家加油!

 



 

2008年12月18日 星期四

一個蠻不錯的網站

這是一個還不錯的網站!裡面有許多國際半導體廠CEO 的專訪,

http://www.eetrend.com/news/100000959   向“低科技”创新,提升利润空间

的確,也有一些比較獨特的見解。----

朋友跟我說連現在以前我們所熟悉的MP3/MP4 的方案也幾乎是大陸公司的天下了,

像是福州的瑞芯微、北京的君正...現在幾乎都已經取代以前的SigmaTel 、珠海炬力集成等...

那更不用說是台灣廠商了...其中像那家瑞芯微...人家就直接用ARM 399MHz直接解 rmvb 檔。

最近突然覺得ARM 越來越兇了...像現在ST 的 STM32 (Cortex-M3) ...真的當一般MCU 在賣!

從一般的 QFN36 pin ...LQFP48...到 144 pin 都有...還有包了一大堆"死人骨頭"都送給您!

http://www.st.com/mcu/inchtml-pages-stm32.html

36 pin 就包個 I2C.. SPI ...還有5x UART 的....有點太誇張了...還有CAN ...

最主要的是他是 32bits 的ARM Core 啊...因為人家客戶說:這種發展工具平台成熟,

客戶進入學習門檻低...(今年年初我也玩過STR912 ...也蠻順手的!這的確是!)

http://chamberplus.blogspot.com/2008/01/usb-jtag.html

最近也不知道是金融風暴呢?!還是不景氣缺錢?!...也越賣越便宜...

難怪,他們敢拿這顆32 bits 跟8/16 MCU 市場嗆聲!...好像像這種支持周邊的東西,

已經越來越不值錢了....像我之前玩過那顆STR912 還支持 DMA 耶...

這種周邊支持真的是比較少見的,卻是對於系統應用很好用。

當然啊...他的Flash /SRAM size 都很可觀,更何況他是32 bits 啊。

真的很誇張的MCU規格,現在終於有點體會到當初人家說ARM的發展潛能,

幾年後的今日也的確見識到了...跟幾位作系統的老師父聊起來也不禁感慨我們這些8051的LKK!

還有一位玩了好幾年Linux 的老友 -Mr.Robert 先生...他說他也決定放棄Linux 投靠Windows CE了。

因為他說:整個Linux 因為開放CODE的結果,市場莫衷一是...大家您一句,我一句的...

結果還不如人家微軟的一統天下來得簡潔,單純...看來系統的軟、硬體技術是越來越明朗了。

或許您不是這樣覺得?!...或許您也可以去市場上多跑跑...您大概就自然而然的體會得到了。

-----.......

2008年12月10日 星期三

IC 設計業裡一個前輩的話

今天因為合作機會又跟我昔日一踏進IC設計時的老長官,一起坐下來聊天。

以前剛進入IC設計業時,最喜歡聽老長官聊他們早期草創台灣這塊產業的風光歲月。

其實,因為這位老長官曾經待在美國一陣子,當年也從美國引進許多此一產業的觀念進台灣。

我以前總是對此一產業充滿著許多憧憬與夢想,而這位老長官的許多公司經營與產業趨勢,

總是有他一套獨特的見解...當然也是來自於他早年與台灣早期半導體業先驅共事的經歷。

事隔多年,竟然還有機會坐下來,再聽聽他的想法與看法...

竟然沒想到說的是:他竟然感慨的說:今非昔比了...以前他們在IC設計業裡,

要開一棵IC是一件多麼慎重與多麼專業的評估與設計工作。

包括市場評估與整體產業趨勢,外加上一些專業技術的評估與技術開發過程,

甚至還不惜與歐美先進國家交流與引進先進設計觀念,這裡面還包括了許多國際專業人士,

或顧問評估與技術指導....結果呢?!....這幾年來,這個行業既然已經變成是:

只是一種拼裝式的產品結合...沒有結合多少產品創意或是市場行銷觀念,

更談不上是什麼獨特技術創新或是先進設計理念,完全是一種純粹是勞力與平淡的時間累積而已。

所用的所有的設計元素都是人家稀疏平常,可能只是學校裡學生的一個專題?...

或只是在別人的公司裡曾經使用的技術經驗而已,再拿出來重置、複製而已。

---- 市場操作的就是千篇一律的殺價與卡位...拼的是我敢花的錢比您多...我找的人比您多...

用的是人海戰術,已經失去那種工程設計上的那種精緻與細膩感。

到處充滿著短線操作,或是粗糙速成的工程流程,結果呢?!....

我們真的留給我們新一代的工程師們怎樣的一個設計理念?...這樣子的設計理念真的

有為我們這個產業的未來留下或奠定了什麼樣子的基礎環境?!

------每次我這個老長官,一開講總是令我有不同思考與思維空間。

最後他還提到何謂我們人生的幸福感?!...難道就是這種日以繼夜的拼命,

還得受著未來的一股不安全感嗎?!而不懂得去真正的去作自己想作的事?!

而留給自己一片輕鬆自在卻也可以創造個人價值的空間呢?!....

他也舉了一個小例子給我聽:他去瑞士看了人家的系統公司,發現人家的公司規模

都是幾十個人,甚至更少...公司沒有亮麗的外牆與Lobby,也沒有顯著的產品包裝,

所開發的東西也不是什麼大型系統或是美美的產品外觀....他只是做著一個小小毫不起眼,

卻是精緻穩定的電子系統,他們只是淡淡的表示:他們的系統在歐洲各地都有其應用價值,

也可以常常看到他們的系統毫不起眼的躲在人家的產品內,但又不失其系統價值!

而我們這幾年下來,卻一直過渡強調產品包裝...股票資金市場所需要的浮華包裝產品形象。

但其中所隱含卻是一些食之無味,去之可惜的雞肋電子產品...

產品壽命都是短暫的一剎那,當然工程師們的價值也猶如蝴蝶般的一瞬間燦爛與短暫

(有沒有機會燦爛還很難講得來?!....)

---最後他只是淡淡的表示:他已經完成他該作的階段性任務了,接下來您們這些年輕人們,

您要如何往下走?您們真的要好好的坐下來,冷靜的思考一下...

他只是覺得這幾年真的很累了....他真的該退休了....

(喔,他有問我,還有沒有人有興趣去接他的位置?!很簡單,就是IC設計公司的專業CEO 而已!)

他給我的建議只是很簡單的一句話:不要去想那種全世界的想法...

您只要靜下來去想:您要在華人的世界裡,扮演怎樣的角色就好了,

因為未來華人世界將會扮演全球關鍵的因素...也不要過渡去爭取鎂光燈前的那個短暫炫麗。

只要好好的把您該做的事,穩紮穩打的把每一件您認為該做好的事做好...

您自然就有機會在華人世界裡...取得您的機會!....您除了善盡您在個人家庭所需要善盡的責任外,

您也該想想您該回報給社會什麼?!...因為您能有今天這個機會,是因為社會也給您過許多資源,

(好像講到我常講USB 技術的東西一樣....也要貢獻給這社會未來一點機會...)

-----

說真的...我想這裡面有許多觀點,或許您不是很贊同,或許您也笑這位老長官思想古板...

但對我來說:或許真的有許多值得我去思考的問題吧...

至少,以前作IC設計是一般人想都很難想得到的事...又要工作站...又要EDA Tools ....

現在的確...連學生的專題都可以是一個IC設計案...我想這位老長官只是差一句話沒講出口:

----現在的IC設計業,真的是賤業啊!....

 

2008年12月9日 星期二

USB DIY-- 自學計畫(五)


這一次所謂USB DIY 自學計畫並不是什麼USB 自修計畫,

而是以過去所熟悉的USB 觀念,來接受新的USB Controller 。

趁機也來檢視一下我們之前所討論的USB 的基本觀念,是否也可以延伸到別

的USBController 平台上。

當然啊,之前我們所提到的USB Controller 一般學習者也想躍躍欲試,

卻有點摸不著頭緒,也苦無學習機會,這回這個USB Controller 是比較大眾化一點。

相信會更引起更多人的興趣吧。...

------

好吧,我們前幾次已經探討了USB 基本的Setup Token 外,我們也先檢視了

Bulk Transfer中的Bulk-Out pipe 。我們也嘗試調整了一下整個Bulk- out 的原始範例程式。

這是都是一些很基礎的觀念,說真的,我說過:拿人家的範例程式來,不是照本宣科一下,

就代表我們對於USB 觀念就完全吸收了。說真的,如果搞技術只是如此的話,

那這種技術也沒什麼值得大家所學習的...我們要探討的是:從這種基本觀念中,

我們可以將此一普及化的通訊介面裡,可以發揮出多少系統應用?!

----這是我一直強調的:懂USB,學會USB...這沒什麼好值得稱讚的 ;

重點是:當您學會了這個系統應用介面之後,您可以拿此介面為您系統

創造什麼附加價值吧!

 不知大家能否體會這樣的呼籲與體會呢?!.... ...

其實我們看完Bulk Out 之後...大概就可以瞭解到單純的Bulk Transaction所

需具備的基本協定吧!

----

針對上回提到的Bulk -out ,我就對於他經由USB傳入8051之後的Buffer 感到好奇,

所以啦,就做一個小實驗,來察看一下他真正的傳輸路徑...

下圖是原廠的技術文件:我們發現他為了USB 傳輸保留 1K Bytes給USB傳輸Buffer之用。

而基本上的分配如下:基本的64 Bytes (For Endpoint 0)... 128/256/512...

很明顯就是為了支援USB 2.0 的...或是ISO Token ...

而在我們的第一範例中:他用到的便是 Bulk Out (endpoint 2 )...

雖然我們還是用了 64 Bytes ...的基本USB Lengths 的傳輸模式...我們就很好奇,

他的內部是如何處理的?!...因為同樣的Endpoint 是可以同時支援In/Out 的 ...

雖然我們在此宣告只是用到Bulk Out(Endpoint2 )!

但他還是會佔用整個Endpoint  2 的範圍的...但只是讓我比較好奇的是:依原廠資料來看:

他要讀此一FIFO Buffer,是要透過他的 USB Registers來依序讀取...

但他明明是8051的 xData範圍啊?!..那我可不可以用Movx 來讀是比較快一點呢?! 

於是啊...我就故意傳一個小小的Bulk out 資料...然後比對一下USB 傳輸前後在此

Endpoint 2的Buffer 內容情形:(0x0640 ~ 0x073F) 的內容如下:

我們就發現:其實,我們用8051的Movx 還是可以讀到此一FIFO 的...

只是他的排列方式有點奇怪?!...好像看起來有點像那種Ping-pong Buffer的觀念?!

他基本上還是真的切成上下兩組Buffer來使用的 ...而且因為是FIFO (先進先出) 的架構,

所以,整個資料排列是有點反過來的...看來您也可以用這招抓USB傳進來的資料...

只是您可能要自己稍微調整一下資料讀取的順序的...當然啊...如果您有宣告

Endpoint 2 同時支援 Bulk In/Out 的話...應該就不是如此了.,,.

請看他所謂的Split Mode的用法

這一點就留給大家作實驗看看!....真的 ...您一定要像我如此的去作個小實驗,

以避免下回在做使用不同模式時,發生一些奇怪的"靈異"現象時,可以很快的釐清問題。

不要屆時在來怪人家的IC 有問題?!或是怪人家IC 不好用?!...只能怪自己學藝不精啊!

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

接下來就來看Bulk-in 的範例了...有了Bulk-out 經驗後,再做Bulk-in 就簡單多了:

因為直覺想到的便是:利用Bulk-out 先下Command ...然後就Bulk-in 直接讀取

USB Device的上傳資料了:

跑了範例之後,才發現這個Bulk-in 範例程式更拙了...所以啦...大家就跑一跑範例就好了,

如果您有機會引用此一範例程式時,還是建議您最好修改一下再使用吧!

在上圖中我們發現那個Bulk-out Command 缺乏一點創意...只是跟USB Device 說:

我要來抓資料了...然後,卻要USB Device 自行回覆傳輸資料長度?!...

(您去看PC 端的應用程式...其實,Host PC 自己已經知道他要回傳的資料長度...

那為什麼不直接下Out Command 時,直接告訴USB Device 呢?!....

不好的範例程式想法...強烈不建議使用這種觀念...您寧願請USB Device 在回覆

一次以確認長度...但不可能以這種方式使用...在PC與USB 韌體之間太沒有彈性了...)

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

然後呢?!...我們接著看到說:當我們上傳兩筆很快的資料後...(Packet # 31/34)

整個USB 速度就會稍微慢下來了...(對不起喔...我還改寫了一下原始上傳資料處理,

以加速上傳速度...)所以啦...不管是上傳或下傳...以這種USB Firmware處理

USB 傳輸資料的架構,永遠是讓HOST PC 等我們USB Device 的份啦...

所以,您真的不要以為USB 2.0 對我們這些USB Device 應用程式來說 ,

真的有Gain 什麼好處的...(USB Bus 開始塞一些NAK了....您知道這個NAK 對於 此

USB Controller 是如何處理的嗎?....您真的可以很快的抓到說:在這個USB

Controller 中的那個Registers 是在控制這個NAK 機制的嗎?!....

這個才是我所要強調的USB學習要點...外面的書籍才不會這樣子教您呢!

我們很明顯的是:自從兩組Bulk -in 之後,就開始固定的產生NAK 的傳輸Latency ...

這個延遲對於這種Buffer不大,又處理速度不夠的USB Controller 中的8051來說:

就是有這種天生宿命...這個在我之前的USB DIY 講座中就有提到了...

這裡只不過再一次驗證給您看而已...

從下圖中:我們就可以看到這個Bulk-in 的Latency 就一路拖到最後....

(Packet # 765 跳到...826 ....再跳到871 ...最後跳到914...,注意喔...

我還因為故意傳固定的資料內容...代表我都沒有去處理傳輸內容的搬移呢!

若加上搬移之後....這個 Latency 鐵定還要加長的!....)

好吧 ...果然如我當初一開始要自學這顆 USB Controller 的想法一般...

在瞭解Bulk-out 之後,我們就很快的學到相對的 Bulk-in 方式。

您看我們還花不到十天工作天,就已經瞭解到大部分的USB上下傳輸的能力了。

您覺得學USB 真的很難嗎?!...只是您有沒有用對方法學而已! ...

接下來我們就可以進入所謂的 HID了 。

(待續)...

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

後記:注意,以原廠的Bulk-in 與Bulk-out 範例程式來說:是不可以像我這樣子分開

作實驗的,而且他是要先執行 Bulk-out 後,馬上執行Bulk-in才可以執行成功的...

這是原廠的所有文件資料都沒有提到的...否則的話...您要像我一樣稍微改寫一下

原廠所提供的範例程式(我指的是USB Device 端的韌體),至於PC 端的程式呢?!...

我覺得還好啦 ...只不過,能改寫一下是比較好,因為,您兩邊稍微察看一下,

您就可以發現原廠的範例程式有我所提到的這個問題.....

學習過程中,最難的還是錯誤發生的排除....,排除時間越短,您的學習效果就越彰顯吧!

好好加油喔。...

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

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


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

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

4.USB DIY-- 自學計畫(一)

5.USB DIY-- 自學計畫(二)

6.USB DIY-- 自學計畫(三)

7.USB DIY-- 自學計畫(四)

2008年12月8日 星期一

改寫原廠的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-- 自學計畫(五)

2008年12月5日 星期五

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-- 自學計畫(五)
 

2008年12月4日 星期四

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-- 自學計畫(五)

2008年12月3日 星期三

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

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

在強迫休假下,工程師們您真的有賺到了嗎?!...

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

而且最近因為國際景氣的關係...連國外的一些常見的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 
休假取代砍人 竹科未見大波裁員潮
李純君/新竹報導

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

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

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

 

2008年11月29日 星期六

最近的網路笑話

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

您就自己加自己的吧!

----Chamber

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

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

2008年11月28日 星期五

JPT ---您要加油 !

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-----

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

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

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

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

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

2008年11月27日 星期四

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) 控制的!
---
個人的小小意見!

2008年11月26日 星期三

USB DIY-- 自學計畫(二)

好吧,我們接下來就實際把原廠所附的USB原始程式給跑起來,

然後實際的操作一遍。....以利我們觀察一下結果。

原則上,我們都不對原廠所附的程式作任何修改,直接組譯下載。

結果呢,我們可以很快到的看到在電腦裝置裡,出現該USB 裝置。

(圖)

我們用的USB 驅動程式也是原廠所給的....不過呢?!原廠也有附上

驅動程式的原始碼,可以供使用者自行修改之。

只不過,使用者要有Window XP DDK 2600 ,才能完成組譯。

我把他所附的驅動程式組譯之後,竟然發現兩者之間的程式大小不一樣!!

先不管了...我們還是先採用原廠的驅動程式...

-----------------
當我們看到電腦出現USB 裝置時,一般的初學者,都會有一股小小的成就感,

覺得好像學USB 就是這麼簡單嘛!....我也會了....

這好像一般時下一些菜鳥工程師常犯的毛病,大陸工程師也是如此,

只不過,寫過一兩個程式,或是向這般跑一次範例程式,就到處炫耀跟別人說:

USB 這種東西很簡單啊... 我也做過....就是怎樣?怎樣的簡單啊....)

但事實真的如此嗎?!....我們把原廠所給的韌體程式所產生的Enumeration過程給抓下來看:

(圖)

乖乖....我們這種老鳥明眼人一看就發現不對勁?!

不對...缺一個ACK Token ...這鐵定有問題,跟您們說:別想騙Microsoft 的OS...

雖然微軟的OS常讓別人罵爽的...但是您也別想呼籠他...

這個原廠的韌體在回 Enumeration 是不對的....否則 OS 不可能不回ACK 的!

再仔細一看:人家系統USB 明明要 0x0A 個Bytes 資料,

USB 韌體竟然回個 32 Bytes ....而且還是亂碼....太離譜了!

雖然外表好像煞有其事的正常顯示出USB 裝置...但不代表您的USB 韌體是對的 !

夠詭異吧 ....這是要玩USB 要先有的心理建設,您不要以為原廠給的東西就是對的!

因為原廠的工程師也是人啊...也有菜鳥工程師啊...也有摸魚打混的人啊!

我們就查了一下:這個Setup Token 是要Device Description中的 Device Qualifier 。

這是USB 2.0 才有的東西 ...USB 1.1 沒有支持這個東西 。

但人家微軟的作業系統一定很清楚是USB 1.1 或是2.0 的東西 ...

人家OS 會來問,一定是USB 韌體本身自己搞的鬼....

往USB Enumeration前面一點看: 果然不錯...自己在USB 的宣告中:自稱USB 2.0 。

(圖)

這叫白癡啊...明明自己韌體程式不支援USB 2.0 的這個命令,

自己還擺爛的回人家說自己是 USB 2.0 !這不是找罪受?!耍白癡嗎?!

這果然跟我們台灣政治人物一般...只是喊爽的而已...又不是真正的 USB 2.0 !

又再一次的證明版主常掛在嘴邊的一句話:不是最好,最快的就是好東西!

只有適合自己用的,才是好東西---才更能凸顯自己的價值啊 !

(像我們這老鳥工程師們平時打屁時說的:在硬體設計時,

所有的元器件都用最好,最貴的...做出來的東西跟人家說自己多會設計電路...

我們常開玩笑說:他應該生在美國,長在美國才對啊! ...這樣的東西有什麼好炫耀的!)

----
好吧 ...我們就原廠的程式把他修改宣告為 USB 1.1 後,再試一次!

(圖)

從上圖中我們發現我們已經回USB 1.1了 !

我再看一次相關的 USB Enumeration 過程.....

(圖)

看到沒?!...漂漂亮亮的完成 USB Get Device Description...

再 Set Configuration....完成整個USB Enumeration 。

完美的Touch-down !--- USB 2.0 有什麼用?!錯的啦...

人家USB1.1 雖然笨一點,老一點...但人家微軟給一百分滿分啊...

------
沒想到,才一開始想用原廠的 程式來修改USB 的應用程式,竟然一開始就發生這種烏龍事件。

當然啊...如果是您呢?!...只要電腦Show出您的 USB 裝置時,

您就高興的非常有成就感?!....您在被陷害您不知道而已. !

等下回人家微軟嚴謹的抓您的USB Bug 時,您該不會一句說:不會啊!

以前我都用得很順利啊...怎麼會有問題呢?!這是一些工程師常慣用的藉口啊

您我捫心自問....我們真的有真正的去面對這種類似的問題嗎?! ...我們真的很有用心的去學習嗎?!

這真的需要花您好幾天的時間嗎?!....而您卻想百般的逃避與不想面對他?!...

這真的不是學技術好的態度的....

-----
接下來呢?!...很不幸的,我RUN 原廠的應用程式,來實際 USB Bulk In/Out...

答案想當然爾---- 也是不對的啦....唉...這到底我比較賤手呢?!

還是真的原廠也是在耍白癡嗎?!...要讓學習者從抓他們的Bug 來學習嗎?!

雖然學技術,是從抓Bug 基礎扎根起來的....這的確是不諱言的。

但看樣子...接下來還有得玩呢!....

(待續)
-------------------

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


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

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

4.USB DIY-- 自學計畫(一)

6.USB DIY-- 自學計畫(三)

7.USB DIY-- 自學計畫(四)

8.USB DIY-- 自學計畫(五)