本文分享的是基于Zerphyr的WiFiBLE通道芯片集成方案，分为以下几个部分为大家进行讲解：
- 本文分享使用的CSK6芯片概况
- WiFi/BLE方案设计与选择
- 基于Zephyr的方案实现
- 基于CSK6芯片的Zephyr网络应用实践
csk6芯片概况
对照语音/视觉AI芯片CSK6基础信息可以看到一些普通MCU上面该有的外设CSK6芯片都有，但是没有WiFi以及BLE相关的外设的，那么因此在AIOT的场景，通常都需要额外接一块无线的SOC，怎么实现MCU+SOC的集成方案就是本文分享的重点。
CSK 芯片基础信息
三核异构AI处理器
- ARM Star MCU：最高300MHz主频
- HIFI4 DSP：最高300MHz主频
- NPU：128GOPS算力
大容量内存资源
- 1MB SRAM
- 最高 8MB PSRAM
- 内置最高支持8MB Flash，可选外置
完整的音视频接口
- DVP摄像头接口：支持VGA
- 4路麦克风输入
- 2路扬声器输出
- 支持SPI驱屏
丰富接口
- 多达33个可灵活配置的GPIO
- USB、UART、SDIO、I2C、I2S、SPI、PWM等外设接口
- 2个定时器，8个独立通道
- 支持4路LEDC与8路PWM输出
- 内置6路触控按钮检测
- SWD、JTAG调试接口
其他特性
- 内置硬件乘法器、硬件除法器
- 内部集成DC-DC，支持2.7V-5.5V供电
- 支持硬件VAD，满足低功耗场景
WIFI/BLE方案设计与选择
方案一：业务交互型
- 所有网络/蓝牙协议都运行在从机
- 需要在两个MCU上开发业务
- 网络相关功能通常与具体业务耦合
这种方案是最容易想到的，也是最简单的一种方案。它有一个比较大的特点，就是所有的网络蓝牙相关的协议都运行在从机，也就是WiFiSOC上面，在开发上它需要在两个MCU上面去开发业务，两边都需要开发相应的固件。那么网络相关的功能通常也会与具体的业务进行耦合。
- 优点：在特定的场景下它的设计与实现都比较简单
- 缺点：它的应用开发的工作量比较大，我们需要去熟悉两套开发环境，以及去开发并维护两套固件，通用性以及扩展性都是相对较差的。
方案二：AT协议型
- 所有网络/蓝牙协议都运行在从机
- 主机对应用层/传输层协议进行接口封装
- 开放通用单点能力
这种方案也算是比较常见的一种方案，我们通常使用的网络模块都是使用AT协议来进行交互的，这种方案它的所有网络跟蓝牙协议也都运行在从主机，一般都会对应用层或者传输层的协议进行接口的封装，并且同时提供一些单点能力，像MQTT、 HTTP这些都是主机这边会进行封装能力。
优点：
- 应用程序的通用性会比较好，使用上灵活性也比较高，因为它都是针对单点能力来进行封装，从软件分层的角度来看，它会更加的解耦。
缺点：
- 协议开发以及维护的工作量非常大，性能也比较一般，因为需要针对每一个网络协议以及蓝牙的协议来进行封装，工作量会非常大，一般都会芯片原厂来提供这一部分的软件但需要学习。
- 学习成本高，你需要学习它的AT指令集才可以使用它。
方案三：通道型
- 主机包含网络/蓝牙协议
- 网络功能完全开放给应用层
这种方案区别于前两种方案，它有一个比较大的特点，就是主机这边通常会包含有协议栈，像网络方面它通常会有TCP IP协议栈，蓝牙方面通常都会有hosted的协议栈。它的网络功能就完全开放给应用层了。
优点：
- 应用程序的通用性会比较强，灵活度也比较高，且性能比较好。
- 因为所有网络功能都已经暴露给应用层了，提供的都是socket的接口，因此对一些熟悉网络编程的开发者来说也是比较友好的，因为使用socket编程可以直接移植PC上面使用的网络程序到单片机上
- 框架开发成本也比较低，通用性也比较强，只需要维护底层的通信协议就ok了
缺点:
- 需要增加协议账的一些消耗，像网络的TCP IP协议站以及蓝牙的后手协议上都是消耗对应的内存以及flash.
基于Zephyr的方案实现
Zephyr Net子系统
Net子系统拥有完整的传输层协议以及非常众多的应用层协议，像一些常见的mqtt、CoAP、HTTP这些应用层协议基本上都支持，同时支持ipv4以及ipv6，并且支持多种链路层技术。
上图可以看到Zephyr的协议站的分层设计，基本上也是按照OSI模型来进行分成的，主要的工作重点就是去实现一个链路层，也就是Zephyr的L2 Network driver去适配Zephyr的net子系统里面。
Zephyr的蓝牙子系统
那么转发蓝牙子系统的协议栈同时支持host与controller了，然后他的host层协议栈完全兼容Bluetooth v5.3SPEC，也就是蓝牙的COSPAC 5.3版本。并且他支持非常多的profile，并且也支持LEaudio。
蓝牙通常是按照上图结构来进行分层的，host和controller中间使用HCI来进行通讯，而我们适配的重点也是去实现一个HCI driver，也就是一个hci的驱动去沟通host以及controller.
前面提到过CSK6芯片如果需要使用无线功能，必须要再接一颗芯片来解决，按照可选择芯片的种类来区分，可以衍生出两种不同的方案。
方案1：CSK6+ESP32-C3方案
ESP32在开源社区是比较流行的，它是一款单核160160M Risc-V的处理器，内置flash跟SRAM，WiFi跟BLE，并且支持一众基础外设，例如SPI、I2C等外设接口的基本上都支持。也就是说如果我们要使用它，也是要在上面进行二次开发的。
如图所示，C3方案架构的硬件上使用全双工的SPI通信，然后通过DateReady来实现一个全双工的通信。SPI的每一次通信都需要master来主动发起，如果slave需要往master发送消息，他也必须需要master来发起。因此这里是使用一个data ready的GPS信号来通知master来实现一个对等的通信。Handshake的引脚更像是一个流控的引脚。如果slave接收能力不足，可以通过把这个引脚拉到指定的电平来通知master暂缓SPI传输。
固件程序会对主机发送过来的包进行解包分拆输进不同的协议在里面，然后主机会抽象出三个链路：、WiFi的数据电路、WiFi的控制电路、HCI的链路，然后对接进Zephyr的Net子系统以及蓝牙的一个子系统里面去。
第二种方案，差819S方案
这种方案会在Linux的主板上面会比较常见，X819S本质上就是一个WiFi和BLE的一个传输芯片，是一个简单收发器，同时支持WiFi跟蓝牙，并且留出SDIO跟UART接口来跟主机通信。跟ESP32 C3不同的地方在于它不可以进行二次开发，并且他也没有处理器和Flash来存储固件，它的固件都是在运行时通过主机来加载进去的。
这个方案架构中硬件上使用SDIO接口来进行通讯，然后SDIO接口负责WiFi方面的一些通讯，然后UART是用来作为蓝牙的HCI，data ready信号是用来做SDIO的双向通信的。与SPI类似，SDIO也是每一次传输都要由master来发起，slave来响应。819S内部的WiFi跟蓝牙子系统都是非常独立的，因此他在运行的时候也是分别通过SDIO以及UART来把WiFi以及蓝牙的固件传输给它。与ESP32 C3方案不一样的地方在于819S方案的WiFi协商运行在csk6芯片上，像802.11、Supplicant、hostapd，相关的协议都会运行在CSK6芯片这一侧，因此它也会带来相应的一些内存的消耗。其他部分与ESP32的方案几乎一样，也同时抽象出三个链路来，一个是数据通路，控制通路以及HCI的通路，分别对应Zephyr的Net子系统、蓝牙子系统。
基于CSK6芯片的Zephyr网络应用实践
初始化与逆初始化 |
int csk_wifi_init(void); |
添加事件回调与删除回调 |
int csk_wifi_add_callback(csk_wifi_event_cb_t *wifi_event_cb); |
扫描附近的API |
int csk_wifi_scan_ap(csk_wifi_scan_info_t**ap_info, csk_wifi_result_t*result, k_timeout_t_timeout): |
连接/断开连接 |
int csk_wifi_sta_connectcsk(wifi_sta_config_t*sta_config, csk_wifi_result t *result, k_timeout_t_timeout): |
WIFI MGR |
int wifi_mgr_storage_save_ap(wifi_mgr_sta_config_t*ap_info); |
表格中是我们基于Zephyr开发的一些WiFi相关的API，无论前面使用的是何种方案，在驱动这一层使用的API都是一样的。WiFi MGR用来提供WiFi的账号密码管理以及一些自动连接相关的功能来辅助应用开发。
上图为我们提供的基于Zephyr 的WiFi实例，包含WiFi相关的一些 sample，感兴趣的同学也可以去我们的文档中心下载SDK做进一步了解。如果你有更多的实用需求，或者想要了解更多有关CSK6与Zephyr的信息，也可以联系我们的开发小助手。
更多学习资源
如果需要获取本教程相关的学习资源、代码，
或者了解更多与嵌入式开发、AI芯片相关的其他课程，可以点击查看 目录导航。