NetHubArchitecture:修订间差异
创建页面,内容为“= NetHub 架构说明 = 本文档面向需要理解模块边界和 API 的开发者。 == 1. 当前架构结论 == * 当前物理主路径是 '''SDIO''' * <code>USB / SPI</code> 目前仍保留 backend 骨架,不作为当前推荐 bringup 路径 * device 侧 Wi-Fi backend 支持 <code>fhost / wl80211</code> * 控制通道和 <code>USER virtual channel</code> 都是当前 host link 上的逻辑通道,不是独立物理接口 * host 控制 backend 运行…” |
小 Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25) |
||
| (未显示同一用户的5个中间版本) | |||
| 第1行: | 第1行: | ||
= NetHub | = NetHub Architecture = | ||
This document summarizes the current NetHub architecture across the device-side module, the optional host control stack, and the current support boundaries. | |||
== 1. | == 1. High-Level Model == | ||
NetHub runs on the device and bridges already-available Wi-Fi capability onto one selected host interface. | |||
[[文件:Nethub_arch.gif | NetHub Architecture Overview]] | |||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
Wi-Fi backend + lwIP | |||
| | |||
v | |||
nethub | |||
+-----------+ | |||
| data-path | | |||
+-- | | filter | | ||
| ctrlpath | | |||
| vchan | | |||
| | +-----------+ | ||
| | |||
v | |||
| | host interface | ||
+-- | (SDIO / USB / SPI) | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Important boundary: | |||
* | * <code>nethub</code> core does not directly depend on <code>ATModule</code> | ||
* <code>ATModule</code> is an optional example consumer of the NetHub control path | |||
* | |||
== | == 2. Current Support Matrix == | ||
{| class="wikitable" | |||
|- | |||
! Area !! SDIO !! USB !! SPI | |||
|- | |||
| Device-side interface backend || yes || yes || yes | |||
|- | |||
| Device-side data-path || yes || yes, through <code>USB ECM</code> || no | |||
|- | |||
| Device-side control transport plumbing || yes || yes, through <code>USB ACM</code> || no | |||
|- | |||
| Current in-tree host Linux stack || yes || not yet the main host path || no | |||
|- | |||
| End-to-end USER virtual channel || yes || not yet aligned in-tree || no | |||
|- | |||
| Default interface today || yes || no || no | |||
|} | |||
== | == 3. Device-Side Layers == | ||
Public headers: | |||
* <code>components/net/nethub/include/nethub.h</code> | * <code>components/net/nethub/include/nethub.h</code> | ||
| 第85行: | 第58行: | ||
* <code>components/net/nethub/include/nethub_filter.h</code> | * <code>components/net/nethub/include/nethub_filter.h</code> | ||
Internal layers: | |||
* <code>bootstrap/</code> | |||
* <code>core/</code> | |||
* <code>profile/</code> | |||
* <code>backend/wifi/</code> | |||
* <code>backend/host/sdio/</code> | |||
* <code>backend/host/usb/</code> | |||
* <code>backend/host/spi/</code> | |||
Main public APIs: | |||
* <code>nethub_bootstrap()</code> | * <code>nethub_bootstrap()</code> | ||
| 第97行: | 第80行: | ||
* <code>nethub_set_wifi_rx_filter()</code> | * <code>nethub_set_wifi_rx_filter()</code> | ||
== 4. Data-Path == | |||
The data-path is the main NetHub function. | |||
<syntaxhighlight lang="text"> | |||
host payload -> host interface backend -> nethub -> active Wi-Fi endpoint | |||
Wi-Fi RX -> nethub filter -> local / host / both | |||
</syntaxhighlight> | |||
Device-side Wi-Fi is already owned by the Wi-Fi backend. NetHub mainly wires the selected host interface to that Wi-Fi backend. | |||
== 5. Control Path == | |||
NetHub exposes a stable control path facade: | |||
<syntaxhighlight lang="c"> | |||
int nethub_ctrl_upld_send(uint8_t *data_buff, uint32_t data_size); | |||
int nethub_ctrl_dnld_register(nethub_ctrl_rx_cb_t dnld_cb, void *cbpri_arg); | |||
</syntaxhighlight> | |||
That facade is implemented per interface. | |||
Current interpretation: | |||
* <code>SDIO</code>: implemented in-tree | |||
* <code>USB</code>: device-side ACM transport plumbing implemented | |||
* <code>SPI</code>: not implemented | |||
Main build-time switches related to this area: | |||
* <code> | * <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</code> | ||
* <code> | ** the example enables <code>ATModule</code> plus host <code>bflbwifid / bflbwifictrl</code> | ||
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code> | |||
** <code>ATModule</code> does not participate in the build | |||
<code>CONFIG_NETHUB_AT_USE_VCHAN</code> should be documented carefully as an example or legacy SDIO-specific control path convention, not as a finished transport-wide selector. | |||
== 6. Virtual Channel == | |||
NetHub also exposes a logical virtual channel layer for message-style traffic such as <code>USER</code>, <code>AT</code>, and internal coordination payloads. | |||
* <code> | Architecture role: | ||
* <code> | |||
* <code> | * device side uses <code>components/net/nethub/include/nethub_vchan.h</code> | ||
* <code> | * host side uses <code>bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h</code> | ||
* < | * the API is intentionally transport-neutral across host interfaces | ||
Current implementation boundary: | |||
* the current in-tree end-to-end USER virtual channel path follows the default <code>SDIO</code> interface | |||
* the device-side implementation is still centered on the SDIO backend | |||
* the host userspace <code>nethub_vchan</code> library is also SDIO-based today | |||
* USB device-side ACM transport exists, but the host-side wrapper is not yet aligned as a finished end-to-end virtual channel path | |||
For prerequisites, detailed APIs, usage order, and limits, read [[NetHubVirtualChannel|NetHubVirtualChannel.md]]. | |||
== 7. Host-Side Optional Stack == | |||
When the optional AT control solution is used, the typical host-side stack is: | |||
<syntaxhighlight lang="text"> | |||
bflbwifictrl -> bflbwifid -> libbflbwifi -> tty or vchan backend | |||
</syntaxhighlight> | |||
Notes: | |||
* this stack is not mandatory for NetHub data-path-only products | |||
* the in-tree host Linux stack is still centered on the SDIO path | |||
== 8. Low-Power Scope == | |||
Current low-power support is <code>BL618DG</code> only. | |||
The example configuration automatically disables <code>CONFIG_NETHUB_LOWPOWER_ENABLE</code> on other chips. | |||
== | == 9. Recommended Reading == | ||
* | * [[NetHub|NetHub.md]] | ||
* | * [[NetHubQuickBringup|NetHubQuickBringup.md]] | ||
* [[NetHubVirtualChannel|NetHubVirtualChannel.md]] | |||
2026年4月24日 (五) 17:12的最新版本
NetHub Architecture
This document summarizes the current NetHub architecture across the device-side module, the optional host control stack, and the current support boundaries.
1. High-Level Model
NetHub runs on the device and bridges already-available Wi-Fi capability onto one selected host interface.
Wi-Fi backend + lwIP
|
v
nethub
+-----------+
| data-path |
| filter |
| ctrlpath |
| vchan |
+-----------+
|
v
host interface
(SDIO / USB / SPI)
Important boundary:
nethubcore does not directly depend onATModuleATModuleis an optional example consumer of the NetHub control path
2. Current Support Matrix
| Area | SDIO | USB | SPI |
|---|---|---|---|
| Device-side interface backend | yes | yes | yes |
| Device-side data-path | yes | yes, through USB ECM |
no |
| Device-side control transport plumbing | yes | yes, through USB ACM |
no |
| Current in-tree host Linux stack | yes | not yet the main host path | no |
| End-to-end USER virtual channel | yes | not yet aligned in-tree | no |
| Default interface today | yes | no | no |
3. Device-Side Layers
Public headers:
components/net/nethub/include/nethub.hcomponents/net/nethub/include/nethub_vchan.hcomponents/net/nethub/include/nethub_filter.h
Internal layers:
bootstrap/core/profile/backend/wifi/backend/host/sdio/backend/host/usb/backend/host/spi/
Main public APIs:
nethub_bootstrap()nethub_shutdown()nethub_get_status()nethub_set_active_wifi_channel()nethub_ctrl_upld_send()nethub_ctrl_dnld_register()nethub_vchan_user_send()nethub_vchan_user_recv_register()nethub_set_wifi_rx_filter()
4. Data-Path
The data-path is the main NetHub function.
host payload -> host interface backend -> nethub -> active Wi-Fi endpoint
Wi-Fi RX -> nethub filter -> local / host / both
Device-side Wi-Fi is already owned by the Wi-Fi backend. NetHub mainly wires the selected host interface to that Wi-Fi backend.
5. Control Path
NetHub exposes a stable control path facade:
int nethub_ctrl_upld_send(uint8_t *data_buff, uint32_t data_size);
int nethub_ctrl_dnld_register(nethub_ctrl_rx_cb_t dnld_cb, void *cbpri_arg);
That facade is implemented per interface.
Current interpretation:
SDIO: implemented in-treeUSB: device-side ACM transport plumbing implementedSPI: not implemented
Main build-time switches related to this area:
CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y- the example enables
ATModuleplus hostbflbwifid / bflbwifictrl
- the example enables
CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=nATModuledoes not participate in the build
CONFIG_NETHUB_AT_USE_VCHAN should be documented carefully as an example or legacy SDIO-specific control path convention, not as a finished transport-wide selector.
6. Virtual Channel
NetHub also exposes a logical virtual channel layer for message-style traffic such as USER, AT, and internal coordination payloads.
Architecture role:
- device side uses
components/net/nethub/include/nethub_vchan.h - host side uses
bsp/common/msg_router/linux_host/userspace/nethub/virtualchan/nethub_vchan.h - the API is intentionally transport-neutral across host interfaces
Current implementation boundary:
- the current in-tree end-to-end USER virtual channel path follows the default
SDIOinterface - the device-side implementation is still centered on the SDIO backend
- the host userspace
nethub_vchanlibrary is also SDIO-based today - USB device-side ACM transport exists, but the host-side wrapper is not yet aligned as a finished end-to-end virtual channel path
For prerequisites, detailed APIs, usage order, and limits, read NetHubVirtualChannel.md.
7. Host-Side Optional Stack
When the optional AT control solution is used, the typical host-side stack is:
bflbwifictrl -> bflbwifid -> libbflbwifi -> tty or vchan backend
Notes:
- this stack is not mandatory for NetHub data-path-only products
- the in-tree host Linux stack is still centered on the SDIO path
8. Low-Power Scope
Current low-power support is BL618DG only.
The example configuration automatically disables CONFIG_NETHUB_LOWPOWER_ENABLE on other chips.
