NetHubArchitecture:修订间差异

来自Bouffalo Lab Docs
跳转到导航 跳转到搜索
张良留言 | 贡献
Sync NetHub docs from local Markdown (2026-04-24)
张良留言 | 贡献
Reduce overlap between NetHubArchitecture and NetHubVirtualChannel (2026-04-25)
 
(未显示同一用户的3个中间版本)
第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 limits.
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-link profile.
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">
第13行: 第15行:
     nethub
     nethub
   +-----------+
   +-----------+
   | data path |
   | data-path |
   | filter    |
   | filter    |
   | ctrlpath  |
   | ctrlpath  |
第20行: 第22行:
       |
       |
       v
       v
host-link profile
host interface
(SDIO / USB / SPI)
(SDIO / USB / SPI)
</syntaxhighlight>
</syntaxhighlight>
第35行: 第37行:
! Area !! SDIO !! USB !! SPI
! Area !! SDIO !! USB !! SPI
|-
|-
| Device-side profile || yes || yes || yes
| 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
|-
|-
| 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 reference path || yes || not yet the main reference path || 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
| End-to-end USER virtual channel || yes || not yet aligned in-tree || no
|-
|-
| Recommended today || yes || evaluation only || no
| Default interface today || yes || no || no
|}
|}


第78行: 第80行:
* <code>nethub_set_wifi_rx_filter()</code>
* <code>nethub_set_wifi_rx_filter()</code>


== 4. Data Plane ==
== 4. Data-Path ==


The data plane is the main NetHub function.
The data-path is the main NetHub function.


<syntaxhighlight lang="text">
<syntaxhighlight lang="text">
host payload -> host-link backend -> nethub -> active Wi-Fi endpoint
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-link side to that Wi-Fi backend.
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-path facade:
NetHub exposes a stable control path facade:


<syntaxhighlight lang="c">
<syntaxhighlight lang="c">
第98行: 第100行:
</syntaxhighlight>
</syntaxhighlight>


That facade is implemented per profile.
That facade is implemented per interface.


Current interpretation:
Current interpretation:
第106行: 第108行:
* <code>SPI</code>: not implemented
* <code>SPI</code>: not implemented


Optional AT solution:
Main build-time switches related to this area:


* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</code>
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y</code>
** example enables <code>ATModule</code> plus host <code>bflbwifid / bflbwifictrl</code>
** the example enables <code>ATModule</code> plus host <code>bflbwifid / bflbwifictrl</code>
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code>
* <code>CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n</code>
** data-plane-only products can omit the example control chain
** <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-path convention, not as a finished transport-wide selector.
<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-channel API:
NetHub also exposes a logical virtual channel layer for message-style traffic such as <code>USER</code>, <code>AT</code>, and internal coordination payloads.


<syntaxhighlight lang="c">
Architecture role:
int nethub_vchan_user_send(const void *data, uint16_t len);
int nethub_vchan_user_recv_register(nethub_vchan_recv_cb_t recv_cb, void *cb_arg);
</syntaxhighlight>


API intent:
* 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


* stable logical message API across host-link types
Current implementation boundary:


Current backend reality:
* 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


* the in-tree implementation is still SDIO-backed
For prerequisites, detailed APIs, usage order, and limits, read [[NetHubVirtualChannel|NetHubVirtualChannel.md]].
* the host userspace <code>nethub_vchan</code> library is also SDIO-based today
* therefore the current end-to-end USER virtual-channel story is the SDIO reference path


== 7. Host-Side Optional Stack ==
== 7. Host-Side Optional Stack ==
第144行: 第146行:
Notes:
Notes:


* this is not required for NetHub data-plane-only products
* this stack is not mandatory for NetHub data-path-only products
* the in-tree host Linux reference stack is still centered on the SDIO path
* 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.

NetHub Architecture Overview

Wi-Fi backend + lwIP
       |
       v
     nethub
  +-----------+
  | data-path |
  | filter    |
  | ctrlpath  |
  | vchan     |
  +-----------+
       |
       v
host interface
(SDIO / USB / SPI)

Important boundary:

  • nethub core does not directly depend on ATModule
  • ATModule is 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.h
  • components/net/nethub/include/nethub_vchan.h
  • components/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-tree
  • USB: device-side ACM transport plumbing implemented
  • SPI: not implemented

Main build-time switches related to this area:

  • CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=y
    • the example enables ATModule plus host bflbwifid / bflbwifictrl
  • CONFIG_NETHUB_CTRLCHANNEL_USE_ATMODULE=n
    • ATModule does 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 SDIO interface
  • the device-side implementation is still centered on the SDIO backend
  • the host userspace nethub_vchan 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.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.

9. Recommended Reading