基于Zephyr网络功能构建的WIFI&BLE无线芯片集成方案

目录

CSK6芯片概况

WIFI/BLE方案设计与选择

方案一:业务交互型

方案二:AT协议型

方案三:通道型

基于Zephyr的方案实现

方案一:CSK6+ESP32-C3方案

方案二:X819S方案

基于CSK6芯片的Zephyr网络应用实践

视频讲解

其他学习资源

关于聆思


本文分享的是基于Zerphyr的WiFiBLE通道芯片集成方案,分为以下几个部分为大家进行讲解:

  1. 本文分享使用的CSK6芯片概况
  2. WiFi/BLE方案设计与选择
  3. 基于Zephyr的方案实现
  4. 基于CSK6芯片的Zephyr网络应用实践

CSK6芯片概况

三核异构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,满足低功耗场景

大家可以看到像一些普通MCU上面该有的外设CSK6芯片都有,但是没有WiFi以及BLE相关的外设的,那么因此在AIOT的场景,通常都需要外挂一块无线的SOC,怎么实现MCU+SOC的集成方案就是本文分享的重点。

WIFI/BLE方案设计与选择

方案一:业务交互型

所有网络/蓝牙协议都运行在从机

需要在两个MCU上开发业务

网络相关功能通常与具体业务耦合

这种方案是最容易想到的,也是最简单的一种方案。它有一个比较大的特点,就是所有的网络蓝牙相关的协议都运行在从机,也就是WiFi SOC上面,在开发上它需要在两个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.3 SPEC,也就是蓝牙的COSPAC 5.3版本。并且他支持非常多的profile,并且也支持LE audio。

蓝牙通常是按照上图结构来进行分层的,host和 controller中间使用HCI来进行通讯,而我们适配的重点也是去实现一个HCI driver,也就是一个hci的驱动去沟通host以及controller.

前面提到过CSK6芯片如果需要使用无线功能,必须要外挂一颗芯片来解决,按照外挂芯片的种类来区分,可以衍生出两种不同的方案。

方案一: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子系统以及蓝牙的一个子系统里面去。

方案二:X819S方案

这种方案会在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_deinit(void);

添加事件回调与删除回调

int  csk_wifi_add_callback(csk_wifi_event_cb_t *wifi_event_cb);
int  csk_wifi_remove_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):
int csk_wifi_sta_disconnect(csk_wifi_result t *result, k_timeout_t_timeout);

WIFI MGR

int wifi_mgr_storage_save_ap(wifi_mgr_sta_config_t*ap_info);
int wifi_mgr_storage_search_ap(wifi_mgr_sta_config_t **matched_list, wifi_mgr_storage_search_mode_t search_modes, void* target);
int wifi_mgr_auto_connect_start(wifi_mgr_autoconn_config_t *autoconn_config);

表格中是我们基于Zephyr开发的一些WiFi相关的API,无论前面使用的是何种方案,在驱动这一层使用的API都是一样的。WiFi MGR用来提供WiFi的账号密码管理以及一些自动连接相关的功能来辅助应用开发。

上图为我们提供的基于Zephyr 的WiFi实例,包含WiFi相关的一些 sample,感兴趣的同学也可以去我们的文档中心下载SDK做进一步了解。如果你有更多的实用需求,或者想要了解更多有关CSK6与Zephyr的信息,也可以直接联系沟通。

视频讲解

Zephyr系统对无限网络的支持如何? 如何通过Zephyr的无线协议栈接入WIFI与蓝牙芯片?

这个视频给你答案!

基于Zephyr的WIFI&BLE通道芯片集成方案

其他学习资源


Zephyr系列相关分享 | CSDN
环境搭建 | 聆思文档中心
芯片介绍 | 聆思文档中心
支持简介 | 聆思文档中心
更多视频课程

关于聆思

聆思科技是一家专注提供智能终端系统级(SoC)芯片的高科技企业,目前推出的CSK6系AI芯片已适配Zephyr RTOS。

希望了解更多有关CSK6 AI芯片信息的伙伴也可以+V:listenai-csk 

欢迎各位同学联系我们进行技术相关的探讨,也可以在评论区进行提问,大家一起进步吧!

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值