NetHubArchitecture:修订间差异
小 Sync NetHub docs from local Markdown (2026-04-24 wording update) |
小 Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25) |
||
| (未显示同一用户的2个中间版本) | |||
| 第1行: | 第1行: | ||
= NetHub Architecture = | = NetHub Architecture = | ||
This document summarizes the current NetHub architecture across the device-side module, the optional host control stack, and the current support | 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 == | == 1. High-Level Model == | ||
NetHub runs on the device and bridges already-available Wi-Fi capability onto one selected host | 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"> | ||
| 第20行: | 第22行: | ||
| | | | ||
v | v | ||
host | host interface | ||
(SDIO / USB / SPI) | (SDIO / USB / SPI) | ||
</syntaxhighlight> | </syntaxhighlight> | ||
| 第35行: | 第37行: | ||
! Area !! SDIO !! USB !! SPI | ! Area !! SDIO !! USB !! SPI | ||
|- | |- | ||
| Device-side | | Device-side interface backend || yes || yes || yes | ||
|- | |- | ||
| Device-side data-path || yes || yes, through <code>USB ECM</code> || no | | Device-side data-path || yes || yes, through <code>USB ECM</code> || no | ||
| 第41行: | 第43行: | ||
| Device-side control transport plumbing || yes || yes, through <code>USB ACM</code> || no | | Device-side control transport plumbing || yes || yes, through <code>USB ACM</code> || no | ||
|- | |- | ||
| Current in-tree host Linux | | 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 | | End-to-end USER virtual channel || yes || not yet aligned in-tree || no | ||
|- | |- | ||
| | | Default interface today || yes || no || no | ||
|} | |} | ||
| 第83行: | 第85行: | ||
<syntaxhighlight lang="text"> | <syntaxhighlight lang="text"> | ||
host payload -> host | host payload -> host interface backend -> nethub -> active Wi-Fi endpoint | ||
Wi-Fi RX -> nethub filter -> local / host / both | Wi-Fi RX -> nethub filter -> local / host / both | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Device-side Wi-Fi is already owned by the Wi-Fi backend. NetHub mainly wires the host | 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 == | == 5. Control Path == | ||
NetHub exposes a stable control | NetHub exposes a stable control path facade: | ||
<syntaxhighlight lang="c"> | <syntaxhighlight lang="c"> | ||
| 第98行: | 第100行: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
That facade is implemented per | That facade is implemented per interface. | ||
Current interpretation: | Current interpretation: | ||
| 第113行: | 第115行: | ||
** <code>ATModule</code> does not participate in the build | ** <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 control | <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 == | == 6. Virtual Channel == | ||
NetHub also exposes a logical virtual- | NetHub also exposes a logical virtual channel layer for message-style traffic such as <code>USER</code>, <code>AT</code>, and internal coordination payloads. | ||
Architecture role: | |||
API | * device side uses <code>components/net/nethub/include/nethub_vchan.h</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 == | == 7. Host-Side Optional Stack == | ||
| 第144行: | 第146行: | ||
Notes: | Notes: | ||
* this stack is not | * this stack is not mandatory for NetHub data-path-only products | ||
* the in-tree host Linux | * the in-tree host Linux stack is still centered on the SDIO path | ||
== 8. Low-Power Scope == | == 8. Low-Power Scope == | ||
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.
