大陸對台開放個體戶

大陸對台開放個體戶
2007-02-16 01:53╱賀靜萍╱綜合報導  

 

為進一步吸引台資前往大陸投資，擴大台灣人在大陸經濟活動範圍，中國國家工商管理局宣布，繼二○○四年一月一日對港澳解禁之後，目前正研究對台灣開放赴大陸設立個體戶政策。預料此一政策推行後，可能再掀起一波台灣人西進創業潮。

 

香港「文匯報」報導，根據大陸與香港及澳門簽署的CEPA協議，中國大陸允許港澳居民到大陸開設個體戶。

 

中國國家工商總局副局長鍾攸平表示，到二○○六年底，港澳居民在內地設立個體工商戶達到二七四六戶。目前，工商總局正在認真研究開放台灣居民在大陸設立個體工商戶的有關建議和措施，積極推動兩岸經貿往來。

 

他表示，今年的工作之一，是落實中國政府加強與台灣地區經貿往來的政策措施，大力促進海峽西岸等台商投資相對集中地區經濟發展。

 

事實上，在中國政府對港澳解禁之後，福州、廈門、泉州等地已先行對台商解禁。而福建允許台資申請經營的行業包括：零售業、餐飲業、洗浴、攝影、汽車、摩托車、家用電器修理及其他日用品修理，貨物、技術進出口。

 

為了方便台資申請，福州各工商局還特別開闢「綠色通道」，為台灣人提供政策諮詢、投資指導和一站式的申請、受理、審批等各便捷服務。到去年底為止，已有近百名灣人在福建各地辦理個體戶工商營業登記。

 

台灣專研大陸私營企業的專家表示，申請登記為個體戶，一來不用註冊資本，對一些有心要去大陸創業的人有很大的吸引力；再者，大陸不再對個體戶的資格有所侷限，或多或少有擴大對台經濟活動的政策意味。

 

而根據資料顯示，大陸的個體私營經濟發展十分迅速，到去年底，私營企業達到四九四．七萬戶，註冊資本（金）七．五兆元人民幣（以下同），個體工商戶二五七六萬戶，資金數額六五一五．四億元。

 

而二○○五年和二○○六年，個體工商戶數量分別比上年同期增長四．八％及四．六％，目前個體私營經濟創造的GDP已經佔到內地經濟總量的四○％左右。

Yahoo新推Pipes工具 讓網友自創應用

Yahoo新推Pipes工具 讓網友自創應用

雅虎公司(Yahoo)7日發佈Yahoo Pipes視覺開發工具，讓使用者操縱擷取自網站的data feeds，以便打造新的應用程式。

混搭程式(mashup)結合擷取自不同網路服務(Web services)的資料，有些熱門混搭程式的資料擷取自單一來源，例如不動產物件刊登，然後在網路地圖服務上展示。

Yahoo Pipes目前仍是測試版，雅虎希望藉這項程式賦予程式開發人員及科技玩家更強大的工具，以整合結構化data feeds。通常這項任務是用Really Simple Syndication (RSS)或Atom協定來達成。

雖然這項服務目前只支援RSS和Atom feeds，雅虎有意擴充使用者可擷取的資料來源數目，也打算讓第三方建立外掛模組，並擴充這項服務的資訊產出組成元素，把地圖等規格也納入其中。

舉例來說，使用者可用Yahoo Pipes把多重的網路行事曆feeds結合起來，以單一面貌展示。使用者也可將新聞提醒訊息客製化，以便在幾個新聞feeds中去蕪存菁。也可以打造一種個人化的eBay拍賣價格監看工具，時時監看RSS，在某個價位區間尋找有興趣標購的品項。

開發Yahoo Pipes的技術靈感源起於Unix。任職於雅虎平台工程事業部的部落客Jeremy Zawodny說，程式設計師可用Unix作業系統建立互相連結的資料來源管道。

不過，Zawodny說：「在全球資訊網上，這就比較困難。雖然有資料來源和資料feeds，但直到最近，我們一直還沒有管道(pipes)! 用JavaScript把資料來源集結並整合起來，在用戶端上呈現，不是容易的事。」

Zawodny說，Yahoo Pipes的重要性是賦予使用者更強的工具，以連結為數日益增多的結構化資料來源。

科技部落格作者的初步反應是躍躍欲試。

Web 2.0一詞創始者O'Reilly Media Publisher的Tim O'Reilly說，Yahoo Pipes標誌「網際網路史上的里程碑」。

這項服務的測試網站8日早晨可存取，但時斷時續。(唐慧文/譯)

除濕機 2007

嵌入式系統設計中串列匯流排的選擇策略

嵌入式系統設計中串列匯流排的選擇策略
上網時間: 2003年02月08日

串列通訊是嵌入式系統設計中的一個重要部份，選擇恰當的串列介面時要考慮多方因素。本文描述了RS-232、RS-422、RS485、I²C、SPI、Microwire及1-Wire等七種常用的串列匯流排，並分析了各自的優缺點，以幫助嵌入式系統設計工程師選擇適用於其設計的串列介面匯流排。

在嵌入式設計中，從顯示器、記憶體到周邊的通訊都藉由串列介面進行。目前有多種串列通訊介面可用於嵌入式系統，但在選擇時要考慮到多個因素。以下將講述表1所示七種最為常用的串列介面，以幫助設計工程師進行正確選擇。

串列介面的優點

在多種情況下需要使用串列介面，最為常見的則是在開發或現場使用時必須與PC進行介面。多數PC帶有與周邊相接的串列介面匯流排，只有少數例外。對於必須與通用電腦介面的嵌入式系統而言，使用串列介面常常比ISA或PCI擴展匯流排更為方便。

串列通訊只需一個I/O引腳便可進行通訊，而平行通訊則需要8個或更多。許多通用嵌入式系統周邊(如類比／數位轉換器和數位／類比轉換器、LCD和溫度感測器)均支援串列介面。

串列匯流排還可用於內部處理器通訊(例如網路)，從而可用若干價格低廉的小處理器來完成通常需要大處理器完成的任務。藉由串列介面，處理器通訊無需共享記憶體和旗語，進一步避免了可能引起的問題。

不過，對於讀取匯流排、地址匯流排和數據匯流排以及其它微程式控制而言，平行匯流排永遠是首選。‘記憶體映射’外部設備已成為一種專門技術，用於帶地址和數據匯流排的系統中。藉由這一技術可平行存取片外設備。不過，由於許多8位元微控制器(更不用說8引腳的了)不帶外部地址／數據匯流排，因此通常不使用記憶體映射。

基本術語

在詳細講述每種介面方式之前，我們先定義以下幾個術語：

(1) 在非同步匯流排中數據發送無需時脈信號；而在同步匯流排中則需要。

(2) 在全雙工方式中，數據的發送和接收可同時進行。而在半雙工方式中，可分別進行數據發送和接收，但不能同時收發。

(3)

主／從關係指的匯流排連接一個主設備和若干從設備。主／從匯流排通常是同步的，在雙向數據發送中，均由主設備提供時脈信號。

(4) 多主匯流排也是主／從匯流排，不過它的主設備不止一個。這種匯流排必須具有仲裁方案，以便在多個主設備企圖同時控制匯流排時避免衝突。
(5) 點對點或對等(peer)介面指的是兩個設備間具有一種對應關係；但無主從關係。對等介面通常是非同步的。

(6) 當一個介面具有多個接收器和一個發送器時，我們用‘點對多點(multi-drop)’來進行描述。(7) 當一條匯流排中的對等收發器多於兩個時，用‘多點(multi-point)’來描述。這與‘點對多點’介面並不一樣，它可在同一組連線中進行雙向通訊。

RS-232介面

幾乎所有的電腦都採用TIA/EIA-232-F(通常稱為RS-232)介面方式。RS-232是一種完整的標準，除了電氣特性外，還規範了物理及機械特性，如連接硬體、輸出引腳及信號名稱。RS-232是一種點對點介面，適用於中等長度的通訊，速率可高達20Kbps。儘管在規範手冊中並未標出，但在連接距離較短且正確接地的情況下，其速率可超過115.2Kbps。通常RS-232傳輸距離為30英尺，採用低電容電纜時，可達200英尺。

RS-232是一種非平衡式匯流排，可在兩對接收／發送器(稱為數據終端設備(DTE)及數據電路終端設備(DCE))間進行全雙工通訊。每一端的傳輸信號均與另一端的接收信號相連。因此，兩端的引腳有所不同。

每個發送器都藉由改變線路的電壓來發送數據。高於3V的電壓用二進制數‘0’表示，而低於-3V的電壓則用二進制數‘1’表示。這兩個閥值間的電壓未定義。可採用RS-232轉換IC，如1488、1489或十分常見的MAX232，來進行邏輯電平(0V和5V)與這些電壓的轉換。

通常RS-232通訊包含有起始位元、數據位元、奇偶校驗位元(如果有的話)和停止位元(有時多位元)。與PC通訊的典型格式為八個數據位元、無奇偶校驗位元、一個停止位元。此外，七個數據位元、一個偶校驗位元和一個停止位元這種模式也很常用。通常起始位元為0、停止位元為1，如圖1所示。在正式的規範中沒有描述RS-232的通訊協議，包括起始位元和停止位元的使用。

許多嵌入式系統藉由RS-232與PC或PC周邊(如數據機)進行介面。而其它系統則使用RS-232，再配合較為便宜的協議分析儀或帶有兩個串列口的PC來監控匯流排通訊量。

幾乎所有的微控制器廠商都有支援RS-232的硬體產品，稱為通用非同步收發器(UART)。通常UART都是中斷驅動，速度可高達115.2Kbps，軟體附加費用較少。但不同架構的UART會稍有不同。

RS-422和RS-485

TIA/EIA-422-B(通常稱為RS-422)及TIA/EIA-485-A(通常稱為RS-485)是平衡式、雙絞線介面，速度可高達10Mbps，傳輸距離長達4,000英尺。RS-422和RS-485均為差分匯流排，採用±1.5V到±6V的信號來進行數據傳輸。與RS-232等單端非平衡式匯流排相比，差分平衡式匯流排中的抗噪音能力有所提高。

RS-422是一種點對多點介面，在一對雙絞線上進行單向通訊，從一個發射器將信號發送到多個接收器，最高可有10個單元負載(UL)。如果接收元件需要與發射器進行通訊，則必須在每個接收器和發射器間連接一條獨立的專有匯流排(採用這種回路匯流排可進行全雙工通訊)。正是因為這一點，RS-422通常很少用於兩個節點以上。

RS-485介面則藉由一對雙絞線在多個收發器間進行雙向通訊。規範顯示，該匯流排可包括多達32個等同於收發器的單元負載(UL)。一些製造商生產分支式(fractional)UL收發器，從而將可連接的元件數目增加到100個以上。

RS-422和RS-485使用的起始位元、數據位元和停止位元格式通常與RS-232一樣。實際上，現有的多種轉換器都可在RS-232和RS-485之間進行數據轉換。不過切記，RS-232是全雙工介面，而RS-485則是半雙工。

多數微控制器製造商提供嵌入式UART，並聲稱具有特殊的RS-485性能。

I₂C匯流排

內部積體電路匯流排(I₂C)是由飛利浦半導體公司開發的一種專用介面。它是一種半雙工同步多主設備匯流排，只需要兩條信號線：串列數據線(SDA)及串列時脈線(SCL)。在一個‘與’連線介面中，這些信號線的電壓藉由升壓電阻拉高，並藉由開漏驅動器由硬體進行控制。

I₂C採用可尋址通訊協議，主設備可與採用7位元或10位元地址的從設備進行通訊。每一元件均有一個地址，此地址由飛利浦半導體公司向元件生產商分配。此外還有多個特殊地址，包括‘總呼叫’地址(它可對匯流排內的每一地址進行尋址)及高速起始地址。

在與從設備進行通訊時，所有與從設備通訊的時脈信號(包括去和回)均由從設備產生。每次通訊開始時，主設備均會產生一個開始信號、一個8位元數據字、一個應答位元，然後是一個停止信號或重覆的開始信號。除開始信號和停止信號外，每個數據位元的傳送都在SCL為低電平時進行。當SCL為高電平時，SDA線從高電平變成低電平，產生開始信號，開始數據傳送。當SCL為高電平時，SDA線從低電平變成高電平，產生結束信號，結束數據傳送(見圖2)。資訊接收設備藉由將SDA線的電平拉低來產生應答位元，此時主設備釋放該線路，使之保持高電平。如果主設備讀到的應答位元為高電平時，它認為最後的通訊數據尚未收到，並採取相應的行動─如果可能則重發該數據。

I₂C有個十分有趣的特徵稱為時脈伸展(clock stretching)，產生在從設備無法處理數據位元並要求更多時間時。這種情況下，從設備將SCL線的電平拉低。由於信號表現為‘與’連線，因此當主設備釋放SCL線而從設備正在‘伸展’時脈時，主設備會注意到該線路仍處於低電平。此時，主設備等待，直到從設備處理完數據位元並釋放該線路。一旦從設備釋放線路後，SCL線恢復高電平，指示主設備可發送下一個數據位元。

I₂C有慢(小於100Kbps)、快(400Kbps)及高速(3.4Mbps)三種速率，每一種均可向下相容。如果需要將信號發送出電路板外可參照飛利浦公司規範的建議連線方法。

儘管傳聞有人曾使用I₂C匯流排在大於50英尺的距離內成功通訊，不過它的通訊距離通常僅限於同一電路板內。限制I₂C通訊距離的是匯流排的比特率和傳輸量。因此，對於板外通訊，I₂C實際常限制在10英尺內，屬於中等速率。

SPI匯流排

串列周邊介面(SPI)是由摩托羅拉開發的一種同步串列匯流排，用於該公司的多種微控制器中。

SPI匯流排由四路信號組成，分別是主出從入(MOSI)、主入從出(MISO)、串列時脈(SCK)及主動低電平從設備選擇(/SS)。SPI是一種多主／從設備通訊協議，主設備與選定的從設備間使用單向MISO和MOSI線進行通訊，速率超過1Mbps，為全雙工模式。主設備產生一個SCK脈衝，數據被同步到主設備和從設備間中。SIP協議有四種不同的時脈類型，視SCK信號的極性和相位而定。必須確保這些信號在主設備和從設備間相互相容。

除了1Mbps的速率外，SIP還有另一優點：當僅使用一個從設備時，/SS線路電平會被拉低，/SS信號可以不藉由主設備產生。不過，這一性能要依賴於SCK的相位選擇。

SPI的一個缺點是每個從設備都需要獨立的/SS線路。如果具有外部I/O引腳，或者外部電路板有足夠的位置配置多路選擇輸出器IC，這並不成問題。但對於體積小、管腳數少的微控制器來說，具有多個從設備的SPI介面並非理想之選。

Microwire匯流排

Microwire是由美國國家半導體公司開發的一種三線同步介面，用於該公司的COP8處理器系列產品。

與SPI相似，Microwire是一種主／從匯流排，包括主設備發出的串列數據(SO)、主設備接收的串列數據(SI)及信號時脈(SK)等三路信號，分別對應於SPI的MOSI、MISO及SCK。此外還有一個片選信號，其功能與SPI的/SS相似。Microwire是一種全雙工匯流排，速度可達到或超過625Kbps(由其電容決定)。

針對不同的數據需求，Microwire元件遵循不同的協議。與基於8位元組的SPI不同，Microwire的數據長度可變，同時還規定了一種‘連續’位元流模式。

由於Microwire也具有多個從設備，需要多條片選線，因此它像SPI一樣同時兼具優缺點。有時候，SPI元件可工作於Microwire匯流排，同樣，Microwire元件也可以工作於SPI匯流排，儘管只能在單元件情況下。

儘管在電容配置得當且速率較低時SPI和microwire通訊距離可長達10英尺，但它們通常都局限於板內通訊，距離不超過六英寸。

1-Wire匯流排

Dallas Semiconductor的1-Wire是一種非同步主／從式匯流排，沒有用於多個主設備的協議。與I₂C相似，1-Wire採用半雙工通訊，在單一連線上採用一種開漏拓樸結構進行雙向數據傳輸。不過，1-Wire匯流排的數據線也可以向從設備傳輸功率，儘管比較有限。1-Wire的最高速率僅達16Kbps，但在升壓電阻配置得當時，傳輸距離可達1,000英尺。

位元碼監測

如果沒有支援以上匯流排的硬體，可以使用通用的I/O引腳。用軟體控制串列通訊通常稱作‘位元碼監測(bit banging)’，因為軟體的確在‘串列口’上實施‘監測’作用。

位元碼監測要求軟體可識別每個位元碼的正確時序，因為它必須監測每個輸出位元碼的變化(在全雙工介面中還要監測接收數據的情況。)不過，令嵌入式開發者慶幸的是，不少位元碼監測程式都可從網際網路上找到，用於以上述串列匯流排以及幾乎所有的微控制器結構。實際上，一些微控制器廠商已開發並公佈了它們自己的程式。

本文小結

如上所述，面對大量串列通訊匯流排標準。在選擇一種串列匯流排時，不應只考慮到滿足產品的當前需要，而且還應考慮到是否能用於產品的整個生命周期。希望這些有助於工程師選擇最適合其當前嵌入式設計的串列介面。

作者：

John Patrick

L-3 Communications/Electrodynamics, Inc.

Email: j.s.patrick@ieee.org

此文章源自《電子工程專輯》網站：
http://www.eettaiwan.com/ART_8800300535_617717,676964.HTM.6e8b9920 http://www.eettaiwan.com/ART_8800300535_617717,676964.HTM.6e8b9920

返回文章頁 | 返回主頁

[學習] 麻省理工學院的「開放式課程網頁」

這是一個免費、開放的教育資源，供給全世界各地的機構、學生和自學者使用。開放式課程系統代表麻省理工學院提升知識和教育水準的願景，並且為二十一世紀的世界服務。這個網站的目的正與麻省理工學院對於追求卓越、創意和領導的價值觀不謀而合。

[Book] Writing Solid Code

程式設計的箴言──擷取自《Writing Solid Code》

1. 啟動所有編譯器中的預警功能。
2. 利用lint找出那些編譯器所找不到的錯誤。
3. 如果您有單元測試工具，請好好利用。
4. 請同時保有“偵錯版”及“上市版”。
5. 請利用assert維護巨集來確認函式引數的正確性。
6. 避免讓程式產生未定義的行為，不然就在這些地方加上維護敘述，以免有人誤用了這些未定義的結果。
7. 適時地加上註解，以免浪費別人的時間來看懂您的維護敘述。
8. 不要直接利用假設的狀況，否則請加上維護敘述來檢查這些條件。
9. 利用維護敘述找出不該在正常情況下發生的現象。
10. 不要為求包容意外的狀況而忽略了潛在的錯誤。
11. 利用不同的演算法來協助您確認程式的結果。
12. 避免產生隨機行為，並且讓錯誤無所遁形。
13. 清除不能使用的記憶體空間，以免誤用了它的資料而不自知。
14. 程式中如果有些行為太少發生了，就強迫它多發生幾次。
15. 多保留一些系統資訊，有助於進行更嚴謹的除錯。
16. 徹底建立子系統的檢查程序，並且盡可能地去使用它。
17. 小心地設計測試條件，從各種可行的方法中慎選最好的。
18. 致力寫出無形的，而且完整的測試。
19. 不要以發行時的標準來苛求偵錯版本，偵錯能力是必須犧牲速度及程式大小換來的。
20. 不要等到錯誤發生，才被迫去逐步追蹤程式。
21. 逐步追蹤您的程式。
22. 逐步追蹤程式的時候，請多注意資料的流向及內容。
23. 以原始程式指令為單位無法知道所有執行的細節，面對重要的程式碼最好以組合語言指令為單位來逐步測試。
24. 讓程式的介面為程式師把關，使他們不至於忽略錯誤的情況，更不要因為傳回值的設計不良而造成錯誤。
25. 不時地檢查、並且去除函式介面裡的缺失。
26. 不要以一個函式來包含多項功能；盡可能讓每一個函式只完成一項獨立的功能，這樣有助於我們做更完整的引數檢查。
27. 清楚地定義函式的引數，不要弄得模稜兩可。
28. 確定函式的輸入值都是正確的，以避免函式傳回“輸入錯誤”的訊息。
29. 讓一般的程式師都能由函式的定義看出函式的呼叫方法，並且避免使用布林值來當引數。
30. 用註解來強調函式中潛在的危機。
31. 利用定義明確的資料型別。
32. 隨時注意變數會不會產生溢位或不足位的現象。
33. 寫程式的時候要盡量依照原始的設計，任何無心的偏差都可能造成始料未及的錯誤。
34. 盡量使每一個步驟都只用一段程式來完成。
35. 盡量不用if敘述來處理例外的狀況。
36. 避免層層疊疊的使用?:運算子。
37. 盡量使同一類的特殊狀況只用一段程式處理──將相同的條件敘述合成一條。
38. 避免採用程式語言的危險慣例。
39. 若非必要，不要任意將不同類的運算混在一個式子裡。萬一必須將不同的運算放在一起使用，就用括號來標明運算的順序。
40. 避免呼叫會傳回錯誤碼的函式。
41. 不屬於自己的記憶體，就不要使用。
42. 不要去使用已經被我們釋放的記憶體空間。
43. 不要把用來傳輸出結果的記憶體拿來當成作業時的暫存空間。
44. 不要以 static（或整體性）的空間來傳資料。
45. 不要讓我們的函式變成“寄生蟲”。
46. 不要濫用程式語言的特性。
47. 將 Ｃ 的原始程式寫短，編譯出來的執行碼不見得就會有效率。
48. 寫程式要盡量讓一般人看懂。
49. 錯誤不會自己“跑掉”。
50. 發現錯誤立即修正，莫待將來付出更慘痛的代價。
51. 不能只是解除錯誤的表象，要除掉病因才能真正解決問題。
52. 除非為了讓軟體更成功，非修改不可。否則不要隨便“整理”程式。
53. 不要增添沒有必要的功能。
54. 任何一項功能都要付出代價。
55. 不要容許沒有必要的彈性。
56. 不要盲目地從一堆“嘗試”中去找答案；將時間用來找尋“最正確”的方法。
57. 每完成一小部份，就先回頭測試一遍。不管進度是不是落後，一定要徹底地將程式測試過。
58. 不能只靠測試小組來除錯。
59. 不要錯怪測試人員存心找麻煩。
60. 建立自己適用的優先順序，並確實地依照這個標準來做取捨。
61. 不要讓同一個錯誤有再次出現的機會。

好了，總共六十一條，終於整理出來了，希望對各位有所幫助。想要知道更詳盡內容的話，強力建議諸位直接去翻閱本書。
http://yukuan.blogspot.com/2001/01/writing-solid-code.html

[Book] Practice of Programming

Table of Contents (事前的良好習慣,比日後發生問題來的好)
1. Style.
Names.
Expressions and Statements.
Consistency and Idioms.
Function Macros.
Magic Numbers.
Comments.
Why Bother?


2. Algorithms and Data Structures.
Searching.
Sorting.
Libraries.
A Java Quicksort.
O-Notation.
Growing Arrays.
Lists.
Trees.
Hash Tables.
Summary.


3. Design and Implementation.
The Markov Chain Algorithm.
Data Structure Alternatives.
Building the Data Structure in C.
Generating Output.
Java.
C++.
Awk and Perl.
Performance.
Lessons.


4. Interfaces.
Comma-Separated Values.
A Prototype Library.
A Library for Others.
A C++ Implementation.
Interface Principles.
Resource Management.
Abort, Retry, Fail?
User Interfaces.


5. Debugging.
Debuggers.
Good Clues, Easy Bugs.
No Clues, Hard Bugs.
Last Resorts.
Non-reproducible Bugs.
Debugging Tools.
Other People's Bugs.
Summary.


6. Testing.
Test as You Write the Code.
Systematic Testing.
Test Automation.
Test Scaffolds.
Stress Tests.
Tips for Testing.
Who Does the Testing?
Testing the Markov Program.
Summary.


7. Performance.
A Bottleneck.
Timing and Profiling.
Strategies for Speed.
Tuning the Code.
Space Efficiency.
Estimation.
Summary.


8. Portability.
Language.
Headers and Libraries.
Program Organization.
Isolation.
Data Exchange.
Byte Order.
Portability and Upgrade.
Internationalization.
Summary.


9. Notation.
Formatting Data.
Regular Expressions.
Programmable Tools.
Interpreters, Compilers, and Virtual Machines.
Programs that Write Programs.
Using Macros to Generate Code.
Compiling on the Fly.


Epilogue.


Appendix: Collected Rules.


Index. 020161586XT04062001

數位學習-財團法人自強工業科學基金會

財團法人自強工業科學基金會

http://edu.tcfst.org.tw/E_learning/semiconductor.asp?etype=de14

http://edu.tcfst.org.tw/E_learning/semiconductor.asp?etype=de12

Driver Development

This section provides links to helpful resources for Driver Development.

Architecture Independent Articles

• Introduction to Device Drivers
• Linux Driver Model
• Device Classes
• Basic Char Driver
• Basic Open / Close Functions
• Basic Read / Write Functions
• Basic Driver Completion
• Basic Driver Configure and Build
• Advanced Device Driver Topics
• Network Device Drivers
• uClinux 2.6.x Kernel API
• Basic Block Drivers
• Block IO Subsystem
• IO Schedulers
• Kernel Objects

Frameworks / Peripherals

• DMA Systems
• GPIO Framework
• I2C Framework
• Interrupts
• PPI
• SPI Framework

Sample Drivers

• Sample DMA SPI Driver
• Sample GPIO Driver
• Sample PPI Driver

CMMI / TSP / PSP為相輔相成的機制

CMMI / TSP / PSP為相輔相成的機制

財團法人資訊工業策進會 林栩傑 整理

一、前言

CMMI是一個致力於組織流程改善的架構，由於CMMI並未提供有關實施CMMI各流程領域所需的知識和技能，因此美國Carnegie Mellon大學軟體工程研究所(CMU/SEI) 以W. S. Humphrey為首主持研究開發了個人軟體流程PSP（Personal software process）和團隊軟體流程TSP(Team Software Process)，形成CMMI/PSP/TSP體系。根據近年來國際軟體流程理論與實踐的發展，目前著重在CMMI、PSP和TSP以及ISO軟體流程標準等方面的研究工作，根據專家學者建議，軟體流程的改善應該從三方面著手進行：

n 能力成熟度整合模式CMMI(Capability Maturity Model Integrated)

n 個人軟體流程PSP (Personal Software Process)

n 團隊軟體流程TSP(Team Software Process)

二、CMMI、PSP、TSP為相輔相成的機制

CMMI、PSP和TSP組成的軟體流程架構

n CMMI是流程改善的第一步，它可評鑑組織的能力、識別優先改善需求和追蹤改善進展的管理方式。企業只有開始CMMI改善後，才能接受需要規劃的事實，認識到品質的重要性，才能注重對員工經常進行培訓，合理分配專案人員，並且建立起有效的專案小組。然而，其實施的成功與否與組織內部有關人員的積極參與密不可分。

n PSP能夠指導程式設計師如何確保自己的工作品質，估計和規劃自己的工作，度量和追蹤個人的表現，管理自己的軟體流程和品質。經過PSP學習和實踐的正規訓練，程式設計師們能夠在他們參與的專案工作之中充分運用PSP，從而有助於CMMI目標的實現。

n TSP結合了CMMI的管理方法和PSP的工程技術，告訴程式設計師如何將個人流程結合進團隊軟體流程，並將後者與組織的整個管理系統相聯繫；告訴管理層如何支援和授權專案小組，堅持高品質的工作，並且依據資料進行建構管理，向組織展示如何應用CMMI的原則和PSP的技能去生產高品質的產品。

n CMMI/TSP/PSP代表了目前國際上軟體流程工程研究方面最先進的成果，它們對促進軟體產業的科學化管理，與提高軟體生產力意義重大。

n 要使一個軟體流程對軟體生產的改善真正有所幫助，其架構應是由CMMI、TSP和PSP組成的一個完整體系，即從組織、團隊和個人三個層次進行良好的軟體工程管理模式。換言之，單獨實施CMMI，無法真正做到能力成熟度的升級，只有將CMMI與PSP和TSP有效的結合，才能發揮最大的效力。

三、PSP概述

　　個人軟體流程（Personal Software Process ,PSP）是在1995年由美國Carnegie Mellon大學軟體工程研究所(CMU/SEI) Watts s. Humphrey領導開發；W. S. Humphrey同時也是SEI研發CMMI團隊的主持人。PSP是一種可用於控制、管理和改進個人工作方式的自我改善過程，是一個包括軟體發展表格、說明的結構化架構。 PSP為基於個人和小型團隊軟體流程的最佳化提供了具體有效的途徑，如制訂計畫、控制品質、其他人合作等等。在軟體設計階段， PSP的著眼點在於軟體缺失的預防，其具體辦法是強化設計的準則，而不是設計方法的選擇。根據對大陸參加PSP培訓的104位元軟體人員統計資料，在應用了PSP後軟體中總缺失減少了58.0％，在測試階段發現的缺失減少了71.0％，生產效率提高了20.0％。PSP的研究結果還發現，絕大多數軟體缺失是由於對問題的錯誤理解或簡單的錯誤所造成的，很少是因為技術問題而產生的。而且根據多年來的軟體工程統計資料發現，如果在設計階段埋下一個缺失，則這個缺失在程式設計階段引會發3到5個新的缺失，要修復這些缺失所花的費用要比修復這個設計缺失所花的費用增加了相當的成本。因此實施PSP為確保軟體品質的一個重要途徑，尤其是要提高軟體設計的品質。

3.1 PSP的現況

n 從1993年開始，美國、歐洲、澳洲等地已先後有20多所大學開設PSP課程。

n 在產業界，PSP也先後被Motorola、 HP、 AIS等公司採用，以Navy and Marine Corps為例，使用PSP進行以CMM為基礎的流程改善，從成熟度第一級到第四級只花30個月，而大部分的機構需要72個月的時間。SEI協助ABB導入PSP，在第一個應用PSP的專案中，交付時程提前6.9%，系統測試每千行只發現44個缺失，比原先系統減少10倍缺失。

n 中國大陸北航軟體工程研究所於1997年開始，在北航電腦科學與工程系率先開辦了PSP課程，並成立PSP的實驗應用。

3.2 PSP的內容

　　PSP與工程的技術（程式設計語言、工具或者設計方法等）沒有直接的關係，幾乎能應用到所有軟體工程的工作中。PSP能提供：

1. 個人軟體流程原則的說明

2. 程式設計師作出準確的計畫

3. 程式設計師在改善產品品質所需採取的步驟

4. 度量個人軟體流程改善的基準

5. 流程的改變對程式設計師能力的影響

3.3 PSP的效益

n 使用由下而上的方法來改進流程，讓每個程式設計師了解流程改進的原則，使其了解如何有效生產高品質的軟體

n 為個人和小型團隊軟體流程最佳化提供了具體有效的途徑。彌補在實施CMMI各流程領域所需知識與技能的空白。

n 幫助程式設計師在個人的基礎上運用流程的原則，借助PSP提供的度量和分析工具，瞭解自己的技能水準，控制和管理自己的工作方式，使自己日常工作的估計、規畫和預測更加準確更有效率，進而改進個人的工作表現，提高個人的工作品質和產量。

四、總結

　　CMMI如同軟體廠商的一面鏡子，用來衡量組織以反映出組織發展的水準及能力，改進軟體發展流程。建議組織在推動流程改善的同時，以CMMI為基礎架構，從PSP先做起，然後在此基礎上逐漸轉換到TSP，循序漸進以確保基礎的穩定，對於日後CMMI高成熟度的提升有正面的幫助。

產測前須知

產測前須知:(S/W) 2007/2/3 09:51下午

硬體:
1.DUT的介紹/目前的硬體狀況(全部/部份)
2.GPIO/BUS/I2C/SPI EEPROM
3.硬體提供甚麼.

軟體:
1.該資料的DATA STRUCT
2.軟體如何最做?


會議:
1.記錄該產品在產測使的任何有關事情
2.會議記錄檔 txt/doc/pdf files
3.取得最後該DUT產測的動作. (沒有共識再下次討論)

自己想法:
一個產品不管重頭到尾,都應該有一次以上,大家做在一起,以該階段的工作事情內容來討論
以確保該產品的一致性.

不要太隨便/也不能僵硬

CMMI 是甚麼？

CMMI 是甚麼？

能力成熟度整合模式（CMMI）是由Carnegie Mellon 大學的「軟件工程學院」(Software Engineering Institute) 發展出來的一套有組織的流程改善方法，用以管理專案、部門以至整個機構。CMMI 幫助整合傳統上分開的機構功能、訂立流程改善目標和優先次序、為推行優質流程提供指引、及為評估現行流程提供參考。

CMMI 受全球認可，現時集中在 4 個知識領域上：系統工程、軟件工程、整合的產品及流程發展、和供應商管理。CMMI 為不同的機構提供一個作同等比較的基準，亦為整個機構的流程改善提供一個有組織的展望。

CMMI 模式分連續式（continuous）或階段式（staged）表述。推行 CMMI 時，機構需選擇採用哪種表述方式外，還需決定哪些知識領域會受覆蓋。

http://www.ul.com.hk/b5/news_nl/2006-Issue18/page8.htm

有人對我說：妳的英文只能講給老外聽，寫給老外看

有人對我說：妳的英文只能講給老外聽，寫給老外看

　　今天跟一位下學期打算邀我去演講的高中英文老師聊天，她看過

我許多本書，聊著聊著，她竟然說：「像妳這樣的英文深度，只能

講給老外聽，寫給老外看！」

　　她解釋道：「妳的英文只適合 native speaker, 台灣人不會

懂的。」

　　她還說，連英文老師恐怕也不知道要如何改我的英文作文。她

居然認為我用的是高級知識份子的英文，在台灣是行不通的！

　　那我該怎麼辦？刻意降低程度，使用淺薄的英語，以適應台灣

環境？我當場愣了一下。約愣了三秒鐘，我忽而醒了過來，回答她：

　　「可是，我們學英文本來就是要跟老外溝通的，又不是要講給

自己人聽，或寫給自己人看的。」

　　如果我要跟台灣人講話，我一定說國語，才不會故意說英語呢！

只有上周到 AIT 辦簽證，看那官員一臉華人長相，我一時不知該說

英語或國語好。可是，當他開始問問題：「妳去美國做什麼？」雖然

他說的是國語，我卻很自然的用英語回答：

　　"Just visiting."

　　我為什麼會這樣？

　　因為整個話題都是關於美國，一定會用到英文字彙，我的直覺

自然轉變成英文思維，這時候就不可能再說國語了。而我一向很不

習慣說話中英夾雜，所以要講英語就講英語，或要說國語就說國語；

我不喜歡〔半中半英〕或〔不中不西〕。

　　我想到有一回在台北君悅飯店用餐，在座有外交官陸以正等人。

陸以正編過字典，學養豐富，英文一流，然而用餐中，他也沒有講過

半個英文單字，可見當時他也是中文思維。

　　而且，我平常談版權，遣辭用字不可能太隨便，不然他們會以為

台灣人沒有什麼知識水平，這樣是要不到版權的。而我平常更沒機會

跟教育程度較低的老美來往，所以說一口有內容的英語，或寫優雅的

文章是有必要的。但老實說，我所用的英文都不是冷僻的英文，在電

視影集裡也常聽到劇中人這樣講話－－而美國電視影集不就是給一般

人看的？可見我使用的英語就是一般英語而已。

　　學英文，本來就應該學到像個受過高等教育的人，如果只是簡單

幾句哈啦，用的都是草包英語 simple sentences, 那又何必學呢？反正

又派不上用場。而我的讀者，不少人的英文日益進步，他們都可以跟優秀

的老外共事，或到外商公司爭一席之地，這樣不是很好嗎？

　　反過來想，若一個學生按照正常語言學習方法，在高中畢業時，

英文聽讀說寫，早該綽綽有餘，像我在北歐碰到的青少年都是如此。

哪需要畢業以後重頭學英文呢？