在現(xiàn)代計(jì)算機(jī)體系結(jié)構(gòu)中，尤其是在筆記本電腦等移動(dòng)平臺(tái)中，存在一個(gè)至關(guān)重要的組件，它默默無(wú)聞地工作，卻主導(dǎo)著系統(tǒng)的功耗、穩(wěn)定性和用戶交互體驗(yàn)。這就是嵌入式控制器（Embedded Controller, EC）。

嵌入式控制器（EC）

EC 是什么？

EC 是一種專(zhuān)用的低功耗微控制器（MCU），集成在主板上，負(fù)責(zé)處理大量與主處理器（Application Processor, AP）解耦的系統(tǒng)級(jí)任務(wù)。其最顯著的特點(diǎn)之一是“始終在線”（always-on）的運(yùn)行模式：只要主板持續(xù)供電，即便電腦休眠或關(guān)機(jī)，它依然在工作，隨時(shí)準(zhǔn)備響應(yīng)你的喚醒、開(kāi)機(jī)等指令。

為什么需要 EC?

EC 的誕生源于計(jì)算機(jī)系統(tǒng)設(shè)計(jì)中的一個(gè)基本原則：功能分工。主處理器（CPU）擅長(zhǎng)執(zhí)行高性能的復(fù)雜計(jì)算任務(wù)，但若同時(shí)承擔(dān)大量低速、瑣碎且需實(shí)時(shí)響應(yīng)的硬件控制工作，將嚴(yán)重影響系統(tǒng)整體效率。

EC 正是為此誕生的一種專(zhuān)用低功耗控制器，用于分擔(dān)這類(lèi)任務(wù)。它的職責(zé)也因此不斷演進(jìn)：

▲

在 PC 發(fā)展早期，為避免 CPU 被鍵盤(pán)頻繁的中斷和掃描操作所干擾，工程師引入了微控制器（即 EC 的前身）來(lái)專(zhuān)門(mén)監(jiān)控鍵盤(pán)矩陣，并將處理后的按鍵信號(hào)上傳至主機(jī)。

▲

隨著筆記本電腦普及，EC 的角色顯著擴(kuò)展，它接管了電源管理、散熱風(fēng)扇控制和快捷鍵響應(yīng)等功能。

▲

如今，EC的控制已深入系統(tǒng)底層，其職責(zé)已涵蓋復(fù)雜的充電協(xié)議（如USB PD）、多樣的傳感器管理，以及“開(kāi)蓋喚醒/啟動(dòng)”等功能。

總的來(lái)看，EC 的存在使得許多對(duì)時(shí)效性和功耗有嚴(yán)苛要求的底層任務(wù)從 CPU 中解耦，顯著提升了系統(tǒng)的響應(yīng)效率、穩(wěn)定性與能效表現(xiàn)。

EC 的職責(zé)

EC 覆蓋的職責(zé)范圍非常廣泛，涉及多個(gè)與底層硬件緊密交互的實(shí)時(shí)控制任務(wù)。其核心功能涵蓋電源管理、熱控制、人機(jī)交互、傳感器協(xié)同等多個(gè)方面，是保障系統(tǒng)穩(wěn)定運(yùn)行、降低功耗、優(yōu)化用戶體驗(yàn)的關(guān)鍵組成部分。

下表對(duì) EC 的主要職責(zé)進(jìn)行了分類(lèi)整理，以便更直觀地展現(xiàn)其在系統(tǒng)中的角色分工。

表1：EC功能與職責(zé)

主機(jī)與 EC 的橋梁

EC與主機(jī)之間需要一條穩(wěn)定高效的物理通道來(lái)交換命令和數(shù)據(jù)。隨著技術(shù)的演進(jìn)，連接EC的總線也經(jīng)歷了一次重要的升級(jí)換代，從傳統(tǒng)的LPC總線演進(jìn)到了現(xiàn)代PC架構(gòu)的新標(biāo)準(zhǔn)——eSPI總線。

過(guò)去，這種連接主要依賴(lài)LPC（Low Pin Count）總線。LPC以其結(jié)構(gòu)簡(jiǎn)單、兼容性強(qiáng)的特點(diǎn)服務(wù)了多年。然而，隨著筆記本電腦向著更輕薄、更長(zhǎng)續(xù)航、功能更復(fù)雜的方向發(fā)展，LPC在帶寬、功耗和引腳數(shù)量上的局限性日益凸顯，已無(wú)法滿足現(xiàn)代系統(tǒng)的需求。

為此，Intel推出了LPC的繼任者——eSPI（Enhanced Serial Peripheral Interface）總線，并迅速成為現(xiàn)代PC平臺(tái)的新標(biāo)準(zhǔn)。eSPI針對(duì)PC體系結(jié)構(gòu)進(jìn)行了全面優(yōu)化：

▲

更少的引腳：顯著減少了物理引腳數(shù)量，簡(jiǎn)化了主板布線。

▲

更低的電壓：工作電壓降至1.8V，降低了功耗，并更好地適配主流SoC。

▲

更高的頻率：提升了時(shí)鐘頻率，并支持雙通道和四通道模式，大幅提升了數(shù)據(jù)吞吐量。

這些技術(shù)進(jìn)步為現(xiàn)代輕薄型筆記本的設(shè)計(jì)帶來(lái)了顯而易見(jiàn)的益處。更少的引腳和更低的電壓，意味著主板設(shè)計(jì)可以更簡(jiǎn)潔、功耗更低、續(xù)航更長(zhǎng)。

而eSPI提供的更高帶寬，則為EC承擔(dān)更復(fù)雜的任務(wù)提供了堅(jiān)實(shí)的基礎(chǔ)，使其能夠從容應(yīng)對(duì)高頻的傳感器數(shù)據(jù)讀取、復(fù)雜的USB-C Power Delivery協(xié)議協(xié)商等對(duì)通信速率要求高的功能。

表2：LPC vs. eSPI 總線對(duì)比

深入x86平臺(tái) EC

深入x86平臺(tái) EC，首先聚焦其廣泛應(yīng)用于 Windows 平臺(tái)筆記本和臺(tái)式機(jī)中的EC生態(tài)。

x86平臺(tái) EC

‘x86平臺(tái)EC’ 并非指 EC 本身采用 x86 指令集，而是指其用于配合搭載 Intel 或 AMD x86 架構(gòu)處理器的 PC 系統(tǒng)平臺(tái)。事實(shí)上，EC 通常基于 ARM、RISC-V 或其他 RISC（精簡(jiǎn)指令集）架構(gòu)的 MCU，這類(lèi)架構(gòu)以低功耗、快速響應(yīng)為優(yōu)勢(shì)，更適合處理實(shí)時(shí)性強(qiáng)、資源受限的底層任務(wù)。

這種設(shè)計(jì)與主處理器所采用的 CISC（復(fù)雜指令集計(jì)算機(jī)）架構(gòu)形成了互補(bǔ)關(guān)系：前者專(zhuān)注于任務(wù)調(diào)度和狀態(tài)管理，后者承擔(dān)高性能的應(yīng)用處理。

基于這樣的設(shè)計(jì)定位，x86 平臺(tái)逐漸發(fā)展出一套成熟的 EC 生態(tài)系統(tǒng)，芯片方案主要由幾家廠商提供并廣泛應(yīng)用于主流 PC 產(chǎn)品中。其中較為常見(jiàn)的供應(yīng)商包括新唐科技（Nuvoton）、聯(lián)陽(yáng)半導(dǎo)體（ITE Tech）和微芯科技（Microchip）等。

這張簡(jiǎn)化系統(tǒng)框圖描繪了基于 Intel Kaby Lake U MCP 平臺(tái)的核心組件連接。圖中央的 Intel KABYLAKE_U MCP 是主處理器，它通過(guò) eSPI 接口與 SMSC KBC MEC1505 這個(gè)EC緊密連接。

EC 負(fù)責(zé)直接管理鍵盤(pán)/觸摸板和系統(tǒng)散熱風(fēng)扇。這張圖是系統(tǒng)主要模塊連接的概覽，因此沒(méi)有展示所有詳細(xì)的電路和元件，實(shí)際上和EC相連接的還有SPI Flash、LED燈等模塊。

主機(jī)與EC通信方式

在Windows操作系統(tǒng)中，EC與系統(tǒng)的交互深度整合在ACPI（高級(jí)配置與電源接口）框架之內(nèi)。我們可以將這種復(fù)雜的交互分解為三個(gè)邏輯層面來(lái)理解：上層的ACPI抽象接口、中層的系統(tǒng)核心驅(qū)動(dòng)以及底層的硬件通信協(xié)議。

1. 上層：ACPI抽象接口 (The "API" Layer)

系統(tǒng)固件（BIOS/UEFI）會(huì)提供一系列ACPI表（如DSDT和SSDT），這些表中用ACPI機(jī)器語(yǔ)言（AML）定義了EC所支持的功能。這些功能被封裝成一個(gè)個(gè)標(biāo)準(zhǔn)化的“控制方法”（Control Methods）。

操作系統(tǒng)只需調(diào)用這些抽象的、如同API般的方法，即可命令EC工作，而無(wú)需關(guān)心其底層的硬件實(shí)現(xiàn)細(xì)節(jié)。

取自ACPI-spec6.5 4.8節(jié)

2. 中層：Acpi.sys 核心驅(qū)動(dòng) (The "Translator" Layer)

Windows內(nèi)置的Acpi.sys驅(qū)動(dòng)程序是連接操作系統(tǒng)與EC等硬件的核心橋梁。它的主要職責(zé)是：在系統(tǒng)啟動(dòng)時(shí)解析BIOS提供的ACPI表，將硬件功能呈現(xiàn)給操作系統(tǒng)；并在運(yùn)行時(shí)，將操作系統(tǒng)發(fā)出的標(biāo)準(zhǔn)請(qǐng)求（如獲取電池信息）翻譯成EC能懂的底層硬件命令。

3. 底層：硬件通信協(xié)議 (The "Physical" Layer)

這是Acpi.sys實(shí)際與EC進(jìn)行“對(duì)話”的方式。這個(gè)通信過(guò)程遵循ACPI規(guī)范，包含兩種方向的通信：

▲

主機(jī)到EC的通信（命令/查詢(xún)）： 當(dāng)Acpi.sys需要執(zhí)行一個(gè)ACPI方法時(shí)，它會(huì)通過(guò)I/O端口與EC通信。

檢查狀態(tài)：首先查詢(xún) 命令/狀態(tài)寄存器 (Port 0x66)，等待輸入緩沖（IBF）標(biāo)志位清空，表示EC已準(zhǔn)備好接收命令。

發(fā)送命令/數(shù)據(jù)：向 命令/狀態(tài)寄存器 (Port 0x66) 或 數(shù)據(jù)寄存器 (Port 0x62) 寫(xiě)入相應(yīng)的字節(jié)。

獲取響應(yīng)：等待輸出緩沖（OBF）標(biāo)志位置位，表示EC已將響應(yīng)數(shù)據(jù)準(zhǔn)備好，然后從 數(shù)據(jù)寄存器 (Port 0x62) 讀取結(jié)果。 這個(gè)“檢查-發(fā)送-等待-讀取”的握手過(guò)程確保了主機(jī)與EC之間的同步。

▲

EC到主機(jī)的通信（事件通知）： 當(dāng)EC需要主動(dòng)報(bào)告一個(gè)事件時(shí)，它無(wú)法直接向CPU發(fā)送復(fù)雜數(shù)據(jù)。

觸發(fā)中斷：EC會(huì)向CPU發(fā)送一個(gè)系統(tǒng)控制中斷（System Control Interrupt, SCI）。

系統(tǒng)響應(yīng)：Acpi.sys捕獲到這個(gè)SCI中斷，但它只知道“有事發(fā)生”，并不知道具體是什么事。

查詢(xún)事件：因此，Acpi.sys會(huì)立即通過(guò)上述的主機(jī)到EC通信方式，向EC發(fā)送一個(gè)“查詢(xún)事件”的命令（例如，讀取EC的特定狀態(tài)字節(jié)）。

執(zhí)行方法：EC返回一個(gè)事件代碼（如0xBA代表合蓋），Acpi.sys根據(jù)這個(gè)代碼，去執(zhí)行ACPI表中預(yù)定義好的相應(yīng)方法（如_QBA），從而完成整個(gè)事件的上報(bào)和處理。

總結(jié)一下這個(gè)流程：

用戶合上筆記本蓋子，EC 檢測(cè)到該物理事件。

EC 向主機(jī)發(fā)送 System Control Interrupt（SCI）中斷，通知系統(tǒng)有事件發(fā)生。

Acpi.sys 捕獲 SCI 中斷后執(zhí)行標(biāo)準(zhǔn)查詢(xún)流程：

通過(guò)0x66端口發(fā)送命令0x84（EC Query）。

然后從0x62端口讀取返回的 “查詢(xún)碼”（如0xBA）。

Acpi.sys 根據(jù)返回碼0xBA映射到 ACPI 表中對(duì)應(yīng)的_QBA控制方法并執(zhí)行。

例如，_QBA方法中可能定義“執(zhí)行屏幕關(guān)閉”、“掛起”等動(dòng)作，系統(tǒng)根據(jù)_QBA方法執(zhí)行相應(yīng)電源或UI邏輯。

EC固件：隱藏的軟件層

EC 固件是實(shí)現(xiàn) EC 功能的軟件核心，但對(duì)最終用戶而言通常是“看不見(jiàn)的”。其更新一般不會(huì)單獨(dú)發(fā)布，而是與系統(tǒng) BIOS/UEFI 一同打包，由設(shè)備制造商（OEM）提供。

x86平臺(tái)EC整個(gè)系統(tǒng)圍繞 ACPI 架構(gòu)構(gòu)建，ACPI定義了操作系統(tǒng)與 EC 的交互規(guī)范。這一高度標(biāo)準(zhǔn)化的模型保障了與 Windows 等主流操作系統(tǒng)的良好兼容性，成為 PC 平臺(tái)穩(wěn)定運(yùn)行的基礎(chǔ)。

然而，隨著計(jì)算生態(tài)不斷演化，特別是基于ARM、RISC-V等非x86架構(gòu)筆記本電腦的出現(xiàn)，催生了對(duì)不同EC實(shí)現(xiàn)方案的需求。對(duì)于那些希望在多樣化硬件平臺(tái)上實(shí)現(xiàn)統(tǒng)一底層控制、或?qū)で蟛灰蕾?lài)傳統(tǒng)ACPI模型的方案的系統(tǒng)構(gòu)建者而言，一種新的設(shè)計(jì)應(yīng)運(yùn)而生。這正是谷歌為其Chromebook打造ChromiumOS EC的背景。

深入ChromiumOS EC

下文將詳細(xì)探討 ChromiumOS EC 的設(shè)計(jì)理念、通信模型與其在 ChromeOS 生態(tài)中的具體實(shí)現(xiàn)。

ChromiumOS EC

自2012年左右，ChromiumOS EC的代碼始終是開(kāi)源的。其完整的源代碼托管在chromiumos/platform/ec Git倉(cāng)庫(kù)中，倉(cāng)庫(kù)地址如下，供全球開(kāi)發(fā)者查閱、使用和貢獻(xiàn)。

https://chromium.googlesource.com/chromiumos/platform/ec

主機(jī)與EC通信方式

在ChromeOS設(shè)備中，主機(jī)與EC之間的通信遵循一套定義清晰、分層明確的協(xié)議，其核心是一個(gè)標(biāo)準(zhǔn)的“請(qǐng)求-響應(yīng)”機(jī)制。其通信模型包含兩個(gè)層面：

▲

邏輯協(xié)議層 (Host Command Protocol)：定義了AP與EC之間“說(shuō)什么”，即數(shù)據(jù)包的格式、命令的ID和參數(shù)。

▲

物理傳輸層 (Physical Transport Layer)：定義了“怎么說(shuō)”，即使用哪種物理總線（如eSPI, I2C, SPI等）來(lái)傳輸這些數(shù)據(jù)包。

為了更好地理解，我們來(lái)看一次完整的通信事務(wù)是如何在這兩個(gè)層面協(xié)作下完成的。通信總是由主機(jī)發(fā)起，遵循一個(gè)標(biāo)準(zhǔn)的“請(qǐng)求-響應(yīng)”模型。

第1步 - 主機(jī)側(cè)：構(gòu)建邏輯請(qǐng)求包

主機(jī)上的軟件——無(wú)論是Linux內(nèi)核中cros_ec系列驅(qū)動(dòng)（位于drivers/platform/chrome/），還是用戶態(tài)的ectool等工具——首先會(huì)構(gòu)建一個(gè)標(biāo)準(zhǔn)的二進(jìn)制請(qǐng)求包。這個(gè)包在邏輯上由兩部分組成：

一個(gè)struct ec_host_request結(jié)構(gòu)體，其中包含命令I(lǐng)D、參數(shù)長(zhǎng)度和校驗(yàn)和。

緊跟其后的、該命令所需的具體參數(shù)數(shù)據(jù)。

第2步 - 物理層：發(fā)送請(qǐng)求

主機(jī)驅(qū)動(dòng)程序?qū)?gòu)建好的邏輯請(qǐng)求包，通過(guò)選定的物理總線（如eSPI, I2C, SPI等）發(fā)送給EC。具體使用哪種總線取決于硬件設(shè)計(jì)。

第3步 - EC側(cè)：接收與處理命令

EC上的固件從物理總線上接收到數(shù)據(jù)。數(shù)據(jù)首先由芯片特定的驅(qū)動(dòng)代碼處理，然后傳遞給通用的主機(jī)命令處理任務(wù)（HOSTCMD）。該任務(wù)會(huì)根據(jù)包中的命令I(lǐng)D，調(diào)用相應(yīng)的處理函數(shù)來(lái)執(zhí)行具體任務(wù)（如讀取溫度、設(shè)置鍵盤(pán)背光等）。

第4步 - 物理層：處理“忙碌”狀態(tài) (握手關(guān)鍵)

EC執(zhí)行命令需要時(shí)間（通常是微秒到毫秒級(jí)）。在這段時(shí)間里，主機(jī)不能連續(xù)發(fā)送新命令，必須等待。EC通過(guò)物理層的特定機(jī)制來(lái)告知主機(jī)“請(qǐng)等待”。這是不同總線實(shí)現(xiàn)差異的核心所在：

LPC：EC會(huì)在其命令狀態(tài)寄存器中設(shè)置一個(gè)“處理中”的狀態(tài)位（如EC_LPC_STATUS_PROCESSING），主機(jī)通過(guò)輪詢(xún)?cè)撐粊?lái)判斷EC是否忙碌。

I2C：作為I2C總線上的從設(shè)備，EC會(huì)將SCL時(shí)鐘線拉低，強(qiáng)制主機(jī)暫停傳輸，直到命令處理完畢。

SPI：在EC準(zhǔn)備好響應(yīng)之前，它會(huì)持續(xù)返回一個(gè)特定的前導(dǎo)字節(jié)（preamble）。主機(jī)則不斷讀取，直到收到特殊的“幀起始”字節(jié)（EC_SPI_FRAME_START），才知道有效的響應(yīng)數(shù)據(jù)來(lái)了。

UART：主機(jī)發(fā)送完命令后立即等待。EC處理完畢后，通過(guò)UART異步發(fā)回響應(yīng)。

第5步 - EC側(cè)：封裝邏輯響應(yīng)包

命令執(zhí)行完畢后，EC會(huì)構(gòu)建一個(gè)邏輯響應(yīng)包。其結(jié)構(gòu)與請(qǐng)求包類(lèi)似，包含一個(gè)struct ec_host_response結(jié)構(gòu)體（內(nèi)含執(zhí)行結(jié)果碼、返回?cái)?shù)據(jù)長(zhǎng)度和校驗(yàn)和）以及可選的返回?cái)?shù)據(jù)。

第6步 - 物理層：返回響應(yīng)與完成

EC將響應(yīng)包通過(guò)同一物理總線發(fā)送回主機(jī)。主機(jī)在正確處理了第4步的等待后，接收到完整的響應(yīng)包。至此，一次通信事務(wù)結(jié)束。

案例研究：鍵盤(pán)事件處理流程對(duì)比

前文從生態(tài)、架構(gòu)與通信協(xié)議層面，闡述了傳統(tǒng)x86平臺(tái)EC與ChromiumOS EC的宏觀差異。為了更具體地理解這些差異如何體現(xiàn)在實(shí)際功能中，本部分將以最常見(jiàn)的人機(jī)交互——鍵盤(pán)按鍵——為例，解析一個(gè)按鍵事件從物理觸發(fā)到被操作系統(tǒng)響應(yīng)的完整鏈路，方便理解兩種體系在設(shè)計(jì)和實(shí)現(xiàn)上的不同。

x86平臺(tái)的鍵盤(pán)事件處理

在傳統(tǒng)x86平臺(tái)，鍵盤(pán)處理流程與ACPI和經(jīng)典的鍵盤(pán)控制器（KBC）模型緊密結(jié)合。

處理流程：

EC硬件響應(yīng)：用戶按鍵后，EC內(nèi)部兼容8042 KBC的模塊捕獲信號(hào)，生成原始掃描碼。

數(shù)據(jù)就緒與中斷：EC將掃描碼放入“輸出緩沖寄存器”（I/O 0x60），并在“狀態(tài)寄存器”（I/O 0x64）中設(shè)置標(biāo)志位，然后通過(guò)專(zhuān)用的IRQ1向主CPU發(fā)送硬件中斷。

主機(jī)驅(qū)動(dòng)讀?。翰僮飨到y(tǒng)的i8042控制器驅(qū)動(dòng)響應(yīng)中斷，直接訪問(wèn)I/O端口0x60，讀取原始掃描碼。

翻譯與上報(bào)：i8042驅(qū)動(dòng)將掃描碼交由上層鍵盤(pán)驅(qū)動(dòng)進(jìn)行翻譯，轉(zhuǎn)換為操作系統(tǒng)可識(shí)別的標(biāo)準(zhǔn)化鍵碼，并送入輸入子系統(tǒng)。

ChromeOS EC 的鍵盤(pán)事件處理

在ChromeOS平臺(tái)，EC在其中扮演了更主動(dòng)的事件處理和封裝角色。

處理流程：

EC軟件掃描：EC內(nèi)的RTOS任務(wù)（keyboard_scan_task）掃描鍵盤(pán)矩陣，感知到按鍵變化。

生成MKBP事件：EC固件將整個(gè)鍵盤(pán)矩陣的狀態(tài)打包成一個(gè)結(jié)構(gòu)化的MKBP（Matrix Keyboard Protocol）事件，并將其放入內(nèi)部事件隊(duì)列。

通用事件通知：EC通過(guò)一個(gè)通用的主機(jī)事件中斷（非專(zhuān)用于鍵盤(pán)）通知主機(jī)“有事件發(fā)生”。

主機(jī)協(xié)議查詢(xún)：主機(jī)驅(qū)動(dòng)（cros_ec）響應(yīng)中斷后，通過(guò)主機(jī)命令協(xié)議發(fā)送一個(gè)EC_CMD_GET_NEXT_EVENT（獲取下一個(gè)事件）的請(qǐng)求給EC。

EC響應(yīng)事件：EC從隊(duì)列中取出MKBP事件，將其作為響應(yīng)數(shù)據(jù)打包，通過(guò)總線返回給主機(jī)。

解析與上報(bào)：主機(jī)驅(qū)動(dòng)接收響應(yīng)，解析出鍵盤(pán)矩陣數(shù)據(jù)，計(jì)算出具體按鍵變化，再生成標(biāo)準(zhǔn)鍵碼送入輸入子系統(tǒng)。

當(dāng)EC遇上RISC-V：進(jìn)迭時(shí)空的探索

自研eSPI控制器

在任何一個(gè)現(xiàn)代計(jì)算平臺(tái)中，主處理器與EC之間都需要一條高效、穩(wěn)定的數(shù)據(jù)通道。為了讓即將發(fā)布的芯片無(wú)縫融入并支持主流EC生態(tài)，進(jìn)迭時(shí)空在其中集成了自研的eSPI控制器。

這為進(jìn)迭時(shí)空即將發(fā)布的芯片提供了與現(xiàn)代 EC 進(jìn)行通信所必需的、符合行業(yè)標(biāo)準(zhǔn)的物理接口。透過(guò)這條高速、低功耗、低引腳數(shù)的標(biāo)準(zhǔn)通道，進(jìn)迭時(shí)空的 RISC-V 平臺(tái)能夠高效地處理來(lái)自EC的各類(lèi)底層硬件交互，為上層應(yīng)用的穩(wěn)定運(yùn)行提供硬件保障。

進(jìn)迭時(shí)空的 eSPI 控制器完整實(shí)現(xiàn)了eSPI協(xié)議規(guī)范，支持所有標(biāo)準(zhǔn)通道類(lèi)型：

外設(shè)通道(Peripheral Channel)：支持I/O空間和內(nèi)存映射訪問(wèn)，替代傳統(tǒng)LPC接口。

虛擬線通道(Virtual Wire Channel)：支持GPIO狀態(tài)、系統(tǒng)中斷、電源管理事件等控制信號(hào)傳輸。

帶外通信通道(OOB Channel)：支持SMBus/I2C協(xié)議轉(zhuǎn)換，實(shí)現(xiàn)對(duì)溫度傳感器等外設(shè)的訪問(wèn)。

Flash訪問(wèn)通道(Flash Access Channel)：提供對(duì)共享Flash存儲(chǔ)的訪問(wèn)能力，允許EC訪問(wèn)主處理器端的Flash存儲(chǔ)器。

AP與EC連接示意圖

軟件策略

基于標(biāo)準(zhǔn)的eSPI接口，進(jìn)迭時(shí)空對(duì)EC生態(tài)的支持分為兩個(gè)階段。

▲

初期階段：支持ChromiumOS EC框架

芯片發(fā)布初期不支持ACPI。在此階段，平臺(tái)將支持ChromiumOS EC通信框架。采用此框架，開(kāi)發(fā)者可利用Linux內(nèi)核的cros_ec驅(qū)動(dòng)程序，有助于降低軟件開(kāi)發(fā)成本、加速產(chǎn)品上市。

▲

未來(lái)規(guī)劃：兼容ACPI并提供選項(xiàng)

未來(lái)，平臺(tái)計(jì)劃增加對(duì)ACPI規(guī)范的支持，以兼容傳統(tǒng)的PC生態(tài)。屆時(shí)，基于eSPI控制器的設(shè)計(jì)，平臺(tái)將同時(shí)支持ACPI EC生態(tài)與ChromiumOS EC框架，合作伙伴可根據(jù)產(chǎn)品需求選擇相應(yīng)的方案。

結(jié)語(yǔ)：演進(jìn)與未來(lái)

從經(jīng)典的鍵盤(pán)控制器演化至今，EC已成為負(fù)責(zé)電源、散熱、交互等關(guān)鍵底層任務(wù)的復(fù)雜微控單元。

本文所探討的兩種EC實(shí)現(xiàn)——x86平臺(tái) EC和ChromiumOS EC——代表了兩種不同的設(shè)計(jì)哲學(xué)和生態(tài)模式，兩者并無(wú)絕對(duì)的優(yōu)劣之分，而是分別服務(wù)于不同的技術(shù)背景與市場(chǎng)需求。x86平臺(tái)EC的模式支撐了當(dāng)今PC世界，而ChromiumOS EC在非傳統(tǒng)PC架構(gòu)（如RISC-V或ARM平臺(tái)）上，提供了另一種強(qiáng)大的、可定制的實(shí)現(xiàn)思路。

EC技術(shù)的持續(xù)發(fā)展，無(wú)論是遵循哪種模式，都在不斷提升設(shè)備的能效、用戶體驗(yàn)和系統(tǒng)可靠性。未來(lái)，EC或其演進(jìn)形態(tài)將繼續(xù)在各類(lèi)智能設(shè)備中扮演著不可或缺的核心角色。