物聯智慧夯 32位元低功耗MCU用量增
- DIGITIMES企劃
-
在物聯網、智慧電網、遠端控制與自動化設計…等應用場合，微控制器(Micro Control Unit；MCU)也加速自8/16位元微控制器移轉至32位元MCU，並針對低功耗、高效能應用需求持續強化微控制器的應用效益…
在多數MCU微控制器應用場合，尤其是在低功耗相關應用的MCU，多數都習慣採用8位元MCU為主，這是因為8位元MCU本身在核心應用的邏輯閘相對較少、設計也較精簡，對於整體元件運行或是洩漏電流極低，加上元件本身就與16位元、32位元產品相較為相對低價，因此在低成本、低功耗的自動控制或是微控制器應用多半首選8位元MCU產品。
但隨著基本的微控制器自動控制應用逐漸往智能控制應用移轉，像是熱門的物聯網、智慧電網甚至是家庭自動化智能控制等應用，原有在自動化控制領域使用大宗的8位元MCU在基本智能處理性能表現即出現使用瓶頸，若採行低成本MCU進行產品開發，反而會在系統整合與開發成本耗費過多資源，在進階的智能控制應用反而會以16/32位元MCU較具使用優勢。
MCU功耗表現不是選擇微控制器核心考量
顯而易見的是，不管是16位元還是32位元MCU，在整體元件使用的邏輯閘數量是明顯高於8位元產品甚多，不僅處理核心更大，在運行功耗與低位元的MCU相比反而呈現弱勢。即便是高位元微控制器在整體功耗方面略顯劣勢，但基本上目前市場在高階應用需求方面已逐步朝向高位元微控制器解決方案進行系統整合，而解決方案對應的功耗改善設計已逐步將高/低位元微控制器的功耗差距越拉越近。
基本上使用高位元微控制器在整合智能應用還是明顯較低位元產品來得更具優勢！因為智能控制應用的運行條件、效能要求，已經遠超過低位元微控制器可以應付的程度，即便是為了維持低功耗要求進行系統整合，也會因為耗費過多整合資源使得導入低位元、低功耗微控制器的效益越來越低，甚至也會拖累了智能應用的使用體驗。
智能化應用漸增 考驗MCU運算處理能力
不只是智慧電網、物聯網與家庭自動化應用正逐步朝向高位元微控制器應用，就連工業控制應用產品，也逐步朝高位元微控制器整合邁進，一方面是高位元微控制器的系統整合軟硬體資源越來越豐富，透過更高效能的應用整合，自動化設備也能快速與前/後台系統進行更緊密的系統整合，尤其在因應數位化、網路化應用需求，低功耗高位元MCU已經足以用來建構一智能控制平台，完成不同系統或是應用環境需求的整合開發目的。
而在2009年由ARM發表的32位元的Cortex-M0運算核心，已提供相關MCU開發廠商一個高效益的整合開發平台，加上近年SoC封裝製程技術成熟，開發者可以在不同的處理核心IP間組構出適用於對應導入智能控制領域的特殊設計架構，另可依需求定義元件的記憶體容量、類比/數位介面、I/O接腳數，甚至是同質或是異質處理核心數量都可以視需求自行定義，透過晶片級的整合製作方式，已提供原有離散型微控制器應用開發一個更有效率的產品設計方式。
利用封裝整合製程調整 提升高位元MCU使用效益
透過SoC或是晶片整合的設計方式，使得智能工控或是進階應用可以使用極小晶片進行整合，高位元微控制器透過整合設計優勢，除將周邊電路或多種應用功能積極整併，提升導入高位元微控制器的附加價值外，也讓低位元與高位元微控制器的成本差異逐漸縮小，相對也刺激高性價比的高位元、低功耗MCU市場用量。
再來檢視高位元微控制器的功耗改善問題，若單純比較低位元與高位元微控制器的功耗損失現況，基本上低位元微控制器使用相對少的邏輯閘、晶片面積也相對較小，本來在整體運行功耗就低許多，但若從晶片本身的運算能力與開發成本總體考量，其實高位元的微控制器在使用效益並不會比低位元產品來得差，若加強功耗控制後，也能與低位元微控制器一較長短。
微控制器功耗改善 需從整體應用評估考量
評估微控制器主要的功耗來源，其實可以從最核心的處理器開始檢視，處理核心會產生的功耗主要來自運算時的運作功耗、與硬體閒置時的靜態功耗，在進行比較之前要先對微控制器的使用場合了解其使用情境後，再來決定整體微控制器的性能與功耗指標，才能有效估算出更具參考價值的平均功耗數據。
早期的自動控制應用需求，由於系統複雜度不高，大多會選擇採用8位元或更低位元的微控制器來進行系統開發，但實際上目前的應用環境，自動化系統或智能系統要對應銜接的後端平台，在I/O與處理資料方面已經越來越複雜，需要的實時分析運算需求也更高，甚至還要能直接對接網路化、智能化應用，銜接雲端應用服務或是整合物聯網等複雜應用需求，這種使用情境若選擇低位元微控制器不是說行不通，而是會花在整合的成本過高，整體運行效能也不見得能滿足開發需求，為了顧及整體系統開發效益，選用高位元微處理器是產業趨勢。
選用MCU運算核心 需全面權衡得失
至於在選用微控制器的運算核心方面，多數開發需求可能會以該核心的功耗表現進行選擇，但實際上處理核心固然是考量重點，像是自外部頻率反推的單位耗電流量外，還需考量許多產品因素才能找到較佳的解決方案。例如，該處理器核心所對應的開發資源是否豐沛、第三方開發商多不多，也會影響到導入該處理器方案之後的開發難度、耗時與成本。
以目前業界常用的ARM微控制器核心為例，以ARM Cortex-M0核心觀察，其所使用的邏輯閘(gate count)總數不到約30K上下，驅動電壓在1.8v、超低洩漏(Ultra Low Leakage)約在50μA/MHz，目前使用ARM Cortex-M0核心擴展相關應用方案的成功案例也相當多，ARM自2009年發表了32位元Cortex-M0核心以來，包括 NXP、新唐科技、ST、Freescale等多家國內外CPU大廠相繼投入Cortex-M0CPU開發，不論供貨或者品種的齊全度都已十分成熟，投入Cortex-M0的CPU開發商也在持續增加中。
當然，除了目前主流的ARM外，也有相當多的微處理器核心可供選擇，對業者而言評估這些處理核心，分別可從晶片成本、效能、單位功耗、開發資源、運行系統等多方面進行整體評估，同時也需考量開發端所擁有的開發人員專攻領域，避免選了不容易導入的應用平台，耽誤整體開發案進程。在晶片成本方面，在該處理核心所使用的gate count量與晶片需客製化的程度，或在內嵌Flash快閃記憶體與RAM隨機存取記憶體容量、速度等，都會直接影響到整體方案的建構成本。
在效能評估方面，多數MCU運行時脈會低於100MHz，而DMIPS/MHz(每單位MHz的Dhrystone MIPS)會是最務實的評估指標。而在晶片本身的單位功耗執行效率(DMIPS/mW)方面，一般會以每毫瓦(mW)可執行多少Dhrystone MIPS為參考依據。而在開發資源部份，先前也提過相關開發用的環境、功能函式庫是否充沛，該領域開發人員的專業素質是否具備，開發環境是否有提供圖形化的整合性開發環境(Integrated Development Environment；IDE)，同時，也能在開發階段可搭配便捷、低成本的ICE偵錯電路工具參與測試與驗證設計，加速功能開發速度。而運算核心所運行的作業系統(OS)，也會直接牽動開發資源可用的函式庫、應用程式甚至是可再利用的多元開發資源。
