Zircon 提供功能完整的 USB 子系統，方便您開發 USB 主機和周邊裝置。支援低、全速、高速度和超速的裝置，並支援各種標準自動交涉機制。
在主機角色中，Zircon 的 USB 子系統採用分層式方法，將裝置連接或從匯流排移除時，方便管理裝置的生命週期。在裝置角色中，子系統會將 USB 封包傳入或傳出類別專屬驅動程式庫 (或驅動程式階層)。
目標硬體平台可能包含多個 USB 控制器。因此，Zircon 可以是各實體公車的主機或裝置。不過，每個角色都專屬於特定公車拓撲。除非另有註明，否則本文件會假設只有一輛公車存在。
USB 子系統元件的摘要如下：
- 類別專屬的硬體驅動程式
- USB 集線器驅動程式庫 (適用於類別專屬驅動程式庫的特殊案例)
- 匯流排驅動程式庫
- 主機或裝置控制器介面驅動程式庫
主機角色
以 USB 主機身分操作 Zircon 時，會擔任權威公車仲裁者。連接的 USB 裝置的樹狀結構是根層級的 USB 中樞裝置。無論是否存在實際的中樞硬體，都必須顯示這個根中樞。如果系統包含支援主機的控制器，但沒有實際的中樞硬體，則必須在軟體中模擬這個根中樞。
為協助公車進行仲裁，Zircon 會運作下列驅動程式：
- USB 根中樞驅動程式庫
- 匯流排驅動程式庫
- 主機控制器介面 (HCI) 驅動程式庫
這些驅動程式會彼此一起運作，以回應匯流排，並管理連接裝置的生命週期。
裝置角色
以 USB 裝置形式運作時，Zircon 會在公車和類別專屬驅動程式庫 (或驅動程式階層) 之間傳輸 USB 封包資料。在這個角色中，匯流排驅動程式有助於在 DCI 驅動程式庫與類別特定驅動程式的上層之間進行通訊。
類別專屬的驅動程式庫
類別專屬驅動程式會實作執行特定 USB 函式 (例如 HID 類別裝置) 所需的邏輯，同時未取得實際匯流排讀取和寫入實體封包所需的硬體詳細資料。
一般而言，USB 裝置驅動程式會將轉移要求編碼為 usb_request_t 結構。這些要求結構體通常具有與這些要求相關聯的非同步回呼，會在移轉完成後執行。大致上來說，USB 堆疊會依照優先順序較高的裝置驅動程式將要求發布至待處理的要求佇列。當這些要求提供服務時，系統會叫用其各自的回呼，通知高層要求已完成。
中樞驅動程式庫
中樞驅動程式庫的用途是根據 USB 2.0 規格 的 CH11 管理中樞裝置。簡單來說，USB 中樞裝置經過了裝置列舉，因此使用兩個介面達到其功能：
- 通訊埠狀態變更事件的輸入中斷端點
- 通訊埠狀態查詢的 IN 類型控制轉移
Zircon USB 堆疊 (屬於中樞驅動程式庫的一部分) 會發出要求，等待通訊埠狀態變更中斷事件。USB 中樞裝置，使用 N 位元點陣圖回報通訊埠狀態變更事件，其中位元-1 對應連接埠#1、bit-2 通訊埠#2 等等...請注意，bit-0 是保留用於中樞狀態變更事件的事件，因此目前不受支援。因此，4 個通訊埠中樞使用 IN 類型中斷端點，為每個通訊埠寫入 5 位元值。
當中樞裝置偵測到其中一個通訊埠發生變更時，就會發出中斷傳輸作業，對通訊埠編號進行編碼。這項中斷傳輸作業會解除封鎖中樞驅動程式庫，進而讀取通訊埠狀態變更點陣圖，並判斷哪些通訊埠具有相關活動。
考量到通訊埠狀態變更事件，USB 堆疊會使用中樞裝置的控制介面查詢個別通訊埠狀態，並根據規格繼續進行。舉例來說，如果通訊埠的狀態因連線事件而變更，通訊埠就會處於開機、重設，並列舉繼續。
如要進一步瞭解中樞生命週期的具體細節，請參閱 USB 2.0 規格的 CH11 部分。
匯流排驅動程式庫
匯流排驅動程式的用途是宣布 (或拆除) 匯流排裝置，以及註冊中樞裝置與 USB 堆疊的其餘部分。大多數情況下，匯流排驅動程式只會用於促進 USB 堆疊不同部分之間的通訊。
HCI 驅動程式庫 (僅限主機)
以主機模式操作時，主機控制器介面 (HCI) 驅動程式庫位於 USB 堆疊的底層。這個實體負責將待處理的 usb_request_t 轉譯為能夠為要求提供服務的必要硬體指令。
HCI 驅動程式庫與 DCI 驅動程式庫不同，後者內含可協助裝置列舉的功能。如果一般列舉分成兩個階段：
- 公車列舉 (透過
set_address指令向上)。 - 裝置列舉 (對應可定址裝置的所有內容)。
HCI 驅動程式庫會執行前半部，而 USB 堆疊會接手並執行裝置列舉的其餘部分。
DCI 驅動程式庫 (僅限裝置)
在裝置模式下操作時，裝置控制器介面(DCI) 驅動程式庫位於 USB 堆疊的底層。這個實體負責將待處理的 usb_request_t 轉譯為能夠為要求提供服務的必要硬體指令。
DCI 驅動程式庫與 HCI 驅動程式庫不同，這個驅動程式會向裝置顯示傳入的 OUT 類型轉移要求，以及設定匯流站的外送要求。在這兩種情況下，個別傳輸作業都可能導致多個封包往各個方向進。