diff --git a/docs/API_reference/zh/stdlib/uzlib.md b/docs/API_reference/zh/stdlib/uzlib.md index 008ca54269d6b2b67add692c216a5f3d259014eb..c001c501178dd5f13d39040153c93736bdf4cc5f 100644 --- a/docs/API_reference/zh/stdlib/uzlib.md +++ b/docs/API_reference/zh/stdlib/uzlib.md @@ -1,4 +1,4 @@ -# class uhashlib - zlib解压缩 +# uzlib - zlib解压缩 该模块解压缩用[DEFLATE算法](https://en.wikipedia.org/wiki/DEFLATE)压缩二进制数据 （通常在zlib库和gzip存档器中使用）。该模块实现相应CPython模块的子集，更多信息请参阅CPython文档：[zlib](https://docs.python.org/3.5/library/zlib.html#module-zlib) diff --git a/docs/Application_guide/zh/background/about-qpy.md b/docs/Application_guide/zh/background/about-qpy.md index cbafbef1ffd46178ee07ca107b2639459de0b490..4b6539b84a08e7e4612a344030ba78e22e591f26 100644 --- a/docs/Application_guide/zh/background/about-qpy.md +++ b/docs/Application_guide/zh/background/about-qpy.md @@ -11,10 +11,10 @@ Python 是一个高层次的结合了解释性、编译性、互动性和面向 .. tabset:: 读取并显示键盘输入 ## 使用 C 语言 - + ```c #include - + int main(){ int number; float decimal; @@ -22,22 +22,22 @@ Python 是一个高层次的结合了解释性、编译性、互动性和面向 scanf("%d", &number); scanf("%f", &decimal); scanf("%s", string); - + printf("%d\n", number); printf("%f\n", decimal); printf("%s\n", string); - + return 0; } ``` - + ## 使用 Python 语言 - + ```python number = int(input()) decimal = float(input()) string = input() - + print(number) print(decimal) print(string) @@ -46,10 +46,10 @@ Python 是一个高层次的结合了解释性、编译性、互动性和面向 .. tabset:: 简单的 for 循环 ## 使用 C 语言 - + ```c #include - + int main() { for(int i = 0; i < 10; i++){ @@ -57,9 +57,9 @@ Python 是一个高层次的结合了解释性、编译性、互动性和面向 } } ``` - + ## 使用 Python 语言 - + ```python for i in range(0, 10): print(i) @@ -80,7 +80,7 @@ MicroPython 是 Python 语言的精简高效实现，可理解为一个可以运 .. details:: 关于解释器 解释器（Interpreter）是一个和编译器（Compiler）相对的概念。作为一种解释型语言，Python 的源码是在运行中（而非运行前）被转换为机器可识别和执行的二进制形式。实现这一流程的工具称为解释器。 - +

@@ -88,23 +88,23 @@ MicroPython 是 Python 语言的精简高效实现，可理解为一个可以运 解释型语言和编译型语言的执行流程差异
- + 对于初学者而言，解释器可以粗略地理解为 Python 脚本的运行环境。目前，在电脑端，CPython 是最为常用的 Python 解释器。绝大部分资料和工具中涉及的“Python”默认指的就是 CPython。在嵌入式领域，除了 MicroPython，CircuitPython、PikaPython 等解释器也受到国内开发者的欢迎。 - + 关于 Python 代码执行机制的更多讲解，可以参考 [编译器与解释器的区别和工作原理](https://zhuanlan.zhihu.com/p/39141067)、[浅谈字节码 + 虚拟机](https://blog.csdn.net/qq_39478403/article/details/106298611) 等在线资料，或是阅读 Python 的专业书籍。 .. details:: 关于 REPL REPL，全称 Read-Eval-Print Loop，即“读取-求值-输出”循环，是一种简单的交互式编程环境。REPL 通常会提供一个 CLI（Command-Line Interface，命令行界面），接收用户的输入，解析并执行后，再将结果返回给用户。从功能和使用方法上，它类似于 Windows 的命令提示符（CMD）或 macOS / Linux 的 Shell。 - +

Python 的 REPL 环境
-
- + + REPL 的优势在于可以使得探索性的编程和调试更加便捷，因为“读取-求值-输出”循环通常会比经典的“编辑-编译-运行-调试”模式要更加方便快捷。REPL 对于学习一门新的编程语言具有很大的帮助，因为它能立刻对初学者的尝试做出回应。
diff --git a/docs/Application_guide/zh/background/hardware-platform.md b/docs/Application_guide/zh/background/hardware-platform.md index be15137d36a314979f6070edc7aee39457c8a797..92ca632888be2dc14d963525b6dd6175fd65f91b 100644 --- a/docs/Application_guide/zh/background/hardware-platform.md +++ b/docs/Application_guide/zh/background/hardware-platform.md @@ -1,83 +1,141 @@ # QuecPython 硬件平台支持 -## 原厂介绍 +在前面的 [无线通信模块简介](./wireless-modules.md) 章节中，我们介绍了主芯片的概念。在实际应用中，基于同一厂商生产的同一系列芯片而制造的各种型号的模块往往具有相似的功能和特性，通常也使用着相同的开发工具和驱动程序。为了便于表述和分类，我们引入了平台（platform）的概念，用于代指这些基于相似的主芯片制造的不同型号的模块。 -### 上海移芯通信科技有限公司（Eigencomm） +## 芯片原厂及产品介绍 -上海移芯通信科技有限公司成立于2017年2月，专注于蜂窝移动通信芯片及其软件的研发和销售，致力做世界上最好的蜂窝物联网芯片。公司团队在蜂窝通信芯片上有着辉煌历史和丰富经验。在全球范围内，移芯通信是除高通、海思、三星、MTK、展锐这些世界级大公司之外极少数有能力独立研发蜂窝通信芯片的公司。 +目前，QuecPython 所支持的各个型号的蜂窝通信模块，其主芯片通常来自移芯、展锐、高通和 ASR 这四大厂商。 -作为全球首款基带、射频、电源实现一体化设计的高集成度 Cat.1bis 芯片，EC618 内部集成电源管理芯片，外围器件数量减少30%以上，支持WiFiScan，支持无外部32K晶体工作模式，以更低成本支 持客户多样化的功能需求。尺寸仅有6.1mm*6.1mm。PSM 功耗低至1.3uA，连接态功耗下降50% 以上。EC618 采用双核架构，充分满足场景算力需求。丰富的外设接口：UART，IC，SPI，USB，PWM，ADC，PCM/IS ，Keypad，OneWire 等适配 Cat.1各种典型应用；专用 Camera 接口，更好地支持金融支付中的扫码解码应用。 +### 移芯通信（Eigencomm） -![Alt text](../media/background/hardware-platform/3.png) +上海移芯通信科技有限公司（Eigencomm）成立于 2017 年 2 月，是一家专注于蜂窝移动通信芯片及其软件的研发和销售的高科技企业，致力于打造世界上最好的蜂窝物联网芯片。公司团队在蜂窝通信芯片领域有着辉煌的历史和丰富的经验，曾参与过多个国际标准的制定和多款芯片的开发。在全球范围内，移芯通信是除了高通、海思、三星、MTK、展锐等世界级大公司之外，极少数有能力独立研发蜂窝通信芯片的公司之一。 + +#### LTE Cat.1 物联网芯片 EC618 + +EC618 是移芯通信推出的首颗 Cat.1bis 芯片，也是全球首款基带、射频、电源实现一体化设计的高集成度 Cat.1bis 芯片。EC618 内部集成了电源管理芯片，外围器件数量减少了 30% 以上，支持 WiFiScan，支持无外部 32K 晶体工作模式，以更低的成本满足客户多样化的功能需求。EC618 的尺寸仅有 6.1x6.1mm，是目前市场上最小的 Cat.1bis 芯片。EC618 的功耗表现也非常出色，PSM 功耗低至 1.3uA，连接态功耗下降了 50% 以上。EC618 采用了 Cortex-M3 双核架构，充分满足场景算力需求。EC618 还具备丰富的外设接口：UART，I2C，SPI，USB，PWM，ADC，PCM/I2S ，Keypad，OneWire 等适配 Cat.1 各种典型应用。 + +
+ +
+
+ EC618 芯片功能框图 +
+
### 紫光展锐（Unisoc） -成立于2004年的锐迪科微电子有限公司（RDA）是国内的一面旗帜，其致力于射频及混合信号芯片和系统芯片的设计、开发、制造、销售并提供相关技术咨询和技术服务。展讯和RDA（锐迪科）合并成展锐，实现了强强联手，扛起了中国芯片设计产业的大旗。展锐的崛起，将打破国外垄断，领跑 5G 芯片，成为中国芯片设计行业的标杆。 +紫光展锐（上海）科技有限公司是中国领先的集成电路设计企业，也是全球少数掌握 2G/3G/4G/5G、Wi-Fi、蓝牙、电视调频、卫星通信等全场景通信技术的企业之一。2018 年，展讯通信（上海）有限公司和锐迪科微电子有限公司合并成为紫光展锐，实现了强强联合，扛起了中国芯片设计产业的大旗。紫光展锐的崛起，将打破国外垄断，领跑 5G 芯片，成为中国芯片设计行业的标杆。 -#### Cat.1bis物联网芯片8910DM +#### LTE Cat.1 物联网芯片 8910DM -紫光展锐首款 LTE Cat.1bis 物联网芯片8910DM支持 GSM 双模，上行速率达5Mbps，下行速率达10Mbps，同时集成蓝牙、Wi-Fi 室内定位，连接更稳定，还支持VoLTE，相比 NB-IoT、2G 模组在网络覆盖、速度和延时上具有优势，相比传统 LTE Cat.4模组则拥有更低的成本和功耗，同时适配当前国内的 4G 网络，适用于对性价比、时延性、覆盖范围、通信速度有要求的应用场景。 +紫光展锐公司的 8910DM 芯片是一款 LTE Cat.1bis 物联网芯片，它采用了 28nm 成熟工艺，支持 LTE Cat.1bis 和 GSM 双模，上行速率达 5Mbps，下行速率达 10Mbps。此外，它还集成了蓝牙通讯和 Wi-Fi 室内定位，可实现更稳定的连接，支持 VoLTE，并通过系统优化设计实现显著的低功耗优势 。8910DM 的推出解决了目前物联网连接中的痛点，填补了低功耗窄带物联网与传统宽带物联网之间的蜂窝通信方案空白。其相比 NB-IoT、2G 模组在网络覆盖、速度和延时上具有优势，相比传统 LTE Cat.4 模组则拥有更低的成本和功耗，同时适配当前国内的 4G 网络，非常适用于对性价比、时延性、覆盖范围、通信速度有要求的应用场景。 -![Alt text](../media/background/hardware-platform/4.png) +
+ +
+
+ UIS8910DM 芯片功能框图 +
+
-#### Cat.1bis芯片V8850 +#### LTE Cat.1 物联网芯片 V8850 -V8850是展锐在蜂窝物联网领域推出的业界首个融合室内外定位的安全可信Cat.1bis芯片，在上一代产品基础上进行了智能化升级，具备高集成度更小尺寸、室内外融合定位、更强 Open CPU 能力、更低功耗、工规宽温、安全可信等六大亮点，适用于定位、共享、支付、监控、工业控制等诸多行业。 +紫光展锐公司的 V8850 芯片是业界首个融合室内外定位的安全可信 Cat.1bis 芯片。它在上一代产品基础上进行了智能化升级，具备高集成度更小尺寸、室内外融合定位、更强 Open CPU 能力、更低功耗、工规宽温、安全可信等六大亮点。V8850 高度集成了 BB/RF/PMIC/GNSS，拥有更小尺寸 8.2x8.2mm, 可使模组尺寸较上一代减小 30%, 最小可至 16x18mm，适合对于设备尺寸要求较高的更广泛应用场景。V8850 支持多种卫星定位系统（GPS/北斗/GLONASS/Galileo），并且通过与 Wi-Fi 室内定位技术融合，实现室内外无缝切换定位。 -![Alt text](../media/background/hardware-platform/5.jpg) +
+ +
+
+ UIS8850DG 芯片功能框图 +
+
-#### NB-IoT芯片春藤8908A +#### NB-IoT 芯片春藤 8908A -展锐NB-IoT芯片春藤8908A作为一款高度集成的 NB-IoT 单模单芯片，综合具备中央处理器，调制解调器，射频收发机、电源管理功能，ROM/RAM存储单元等功能；同时支持 3GPP Release 14 协议，拥有窄带物联网（NB-IoT）所具备的超低功耗、超大容量和超强覆盖范围的特点；此外，其的频率覆盖范围为690~2200MHz，可以同时适配国内和国外运营商网络，是智能电表，跟踪设备，智能可穿戴等产品类型的理想选择。 +紫光展锐公司的春藤 8908A 芯片平台是一款超低功耗、超大容量、超强覆盖的 NB-IoT 芯片解决方案。它采用 40nm 工艺，在定点场景和移动场景下的业务成功率、业务时延、功耗等关键性能上表现优异。频率范围覆盖 690~2200MHz 宽频段，可以适配全球主流运营商网络。春藤 8908A 支持多种电源管理模式，并且具有超低待机功耗，在 eDRX 模式下待机电流仅为 1.2uA。此外，春藤 8908A 还支持多种安全特性，包括硬件安全引擎、安全启动、安全调试和安全存储等。 -![Alt text](../media/background/hardware-platform/6.png) +
+ +
+
+ RDA8908A 芯片功能框图 +
+
-### 高通公司（Qualcomm） +### 高通（Qualcomm） -高通（Qualcomm）公司是一家全球领先的半导体和无线通信技术公司。公司总部位于美国加利福尼亚州圣地亚哥，成立于1985年。高通以其在移动通信领域的创新技术而闻名，是全球最大的无线通信芯片供应商之一。公司的产品包括移动处理器、调制解调器、射频前端、无线充电技术等，广泛应用于智能手机、平板电脑、物联网设备等各种移动终端和通信设备。高通也在5G技术研发和标准制定方面发挥重要作用，推动了全球移动通信的发展和创新。 +高通（Qualcomm）公司是一家全球领先的半导体和无线通信技术公司。公司总部位于美国加利福尼亚州圣地亚哥，成立于 1985 年。高通以其在移动通信领域的创新技术而闻名，是全球最大的无线通信芯片供应商之一。公司的产品包括移动处理器、调制解调器、射频前端、无线充电技术等，广泛应用于智能手机、平板电脑、物联网设备等各种移动终端和通信设备。高通也在 5G 技术研发和标准制定方面发挥重要作用，推动了全球移动通信的发展和创新。 -以物联网（IoT）应用及一系列可穿戴跟踪器提供支持可靠、优化的蜂窝连接为宗旨，高通推出 Qualcomm 9X05 LTE 调制解调器，其在单芯片上集成了支持蜂窝物联网产品及服务所需的关键创新，包括全球多模 LTE category M1（eMTC）和 NB2（NB-IoT）以及2G/E-GPRS连接、应用处理、地理定位、基于硬件的安全、云服务支持及配套开发者工具,同时内部集成高通第9代 GNSS 引擎系统，支持 GPS/GLONASS/BeiDou/Galileo。 +#### 多模 LTE 物联网芯片 MDM9X05 -![Alt text](../media/background/hardware-platform/7.png) +以物联网应用及一系列可穿戴跟踪器提供支持可靠、优化的蜂窝连接为宗旨，高通推出 Qualcomm 9X05 LTE 调制解调器，其在单芯片上集成了支持蜂窝物联网产品及服务所需的关键创新，包括全球多模 LTE category M1（eMTC）和 NB2（NB-IoT）以及 2G/E-GPRS 连接、应用处理、地理定位、基于硬件的安全、云服务支持及配套开发者工具，同时内部集成高通第 9 代 GNSS 引擎系统，支持 GPS/GLONASS/BeiDou/Galileo。 -### 翱捷科技股份有限公司（ASR） +
+ +
+
+ MDM9205 芯片功能框图 +
+
-翱捷科技（ASR）是一家提供无线通信、超大规模芯片的平台型芯片企业。公司自设立以来一直专注于无线通信芯片的研发和技术创新，同时拥有全制式蜂窝基带芯片及多协议非蜂窝物联网芯片设计与供货能力，且具备提供超大规模高速 SoC 芯片定制及半导体IP授权服务能力。 +### 翱捷科技（ASR） + +翱捷科技（ASR）是一家提供无线通信、超大规模芯片的平台型芯片企业。公司自设立以来一直专注于无线通信芯片的研发和技术创新，同时拥有全制式蜂窝基带芯片及多协议非蜂窝物联网芯片设计与供货能力，且具备提供超大规模高速 SoC 芯片定制及半导体 IP 授权服务能力。 公司各类芯片产品下游应用场景广阔，可应用于以手机、智能可穿戴设备为代表的消费电子市场及以智慧安防、智能家居、自动驾驶为代表的智能物联网市场。 -#### Cat1 物联网芯片ASR1603 +#### LTE Cat.1 物联网芯片 ASR1603 + +ASR1603 是一款高性价比、超低功耗的多模蜂窝芯片，采用 22nm 工艺制造。与其前身相比，ASR1603 减少了 14% 的面积，降低了 20%~25% 的功耗，并丰富了外围接口。此外，ASR1603 还是一款高集成度的片上系统（SoC）设备，集成了应用程序处理子系统、通信子系统、音频编解码器和嵌入式 pSRAM + Flash，能够支持最紧凑的单芯片 LTE/GSM 多模数据模块、POC、POS 和其他物联网解决方案。 -ASR1603作为新一代 LTE Cat.1平台，ASR1606带来了更高的集成度的单芯片SoC方案，集成了一颗主频高达624MHz的 Cortex-R5处理器，以及 Modem 通信单元、Codec 音频单元、PSRAM+Flash 存储单元和 PMIC，封装尺寸更小、性能更强大：ASR1603 采用了先进成熟的22nm 制程工艺，在芯片短缺的背景下能够提供更加稳定的产能保障；ASR1603继承了上一代 ASR160x 系列亿级稳定出货的软件基线，并通过丰富的外围接口实现广泛的兼容性。该芯片可广泛应用于各种标准数据模块，在跟踪器、共享设备、电网、V2X、各种智能硬件等市场中具有出色的性能。 +
+ +
+
+ ASR1603 芯片功能框图 +
+
-![Alt text](../media/background/hardware-platform/8.png) +#### LTE Cat.1 物联网芯片 ASR1606 -#### Cat1 物联网芯片ASR1606 +ASR1606 是 ASR160x 系列的新一代成员，兼容并继承了 ASR160x 系列软件基线及优势。它不仅针对物联网应用场景提供了更为丰富的外围接口，而且针对芯片集成度、整体性能、存储空间进行了进阶优化。ASR1606 采用 22nm 制程工艺，将 CPU、Modem 通信单元、射频、Codec 音频单元、pSRAM & Flash 存储单元以及 PMU 集成在单芯片 SoC 上，搭载 Cortex-R5 处理器，可强化中低速率应用场景及运行低功耗 RTOS 系统设备的处理性能，适用于环境监测、智慧城市、移动支付、共享经济、工业物联网等领域。 -ASR1606作为一款高集成度的 Cat.1606双蜂窝芯片，采用22nm 工艺制造，采用 Cortex-R5，集成了调制解调器通信系统、音频编解码器、PSRAM+闪存和 PMIC，具有封装尺寸小、性能高的特点。可广泛应用于各种标准数据模块，在跟踪器、共享设备、电网、V2X、各种智能硬件等市场中具有突出的性能。 +
+ +
+
+ ASR1606 芯片功能框图 +
+
-![Alt text](../media/background/hardware-platform/9.png) +#### LTE Cat.4 移动智能终端芯片 ASR1803S -#### Cat1.4G移动智能终端芯片ASR1803S +ASR1803S 是一款基于先进工艺的 4G 基带射频一体化芯片，是集成了射频和内存的高集成度基带通信芯片。该芯片采用 22nm 先进工艺，支持 6 层 1 阶 PCB，拥有 450MHz~2.7G 的频宽，支持 RTOS 操作系统，所占内存小。同时该芯片集成有应用处理器（ARM Cortex-A7），可用于支持 Linux 环境下的各种应用程序，为客户不同产品开发提供灵活选择。ASR1803S 支持全新的动态电压调节技术，能有效降低工作电压，降低功耗，并且支持 QSPI NOR/NAND flash，令 boot 速度更快。该芯片可广泛应用于民用及工业与行业应用当中，如 POS 机、POC 对讲机、数据卡 Dongle、MiFi 终端以及各类水、电、气表的行业综合应用中。 -ASR1803S作为一款高集成度的蜂窝芯片，集成了射频收发器和 RAM，支持实时操作系统，占用内存更少。该芯片可广泛应用于民用设备和工业设备，如POS，POC，加密狗，MiFi终端以及包括水表，电表和燃气表在内的各种设备。带有 Cortex-A1803的ASR7支持基于 Linux 的各种应用程序。 +
+ +
+
+ ASR1803 芯片功能框图 +
+
-![Alt text](../media/background/hardware-platform/10.png) +## 模组型号与平台的对应关系 -## QuecPython对应原厂模组支持型号 +以下的一些表格展示了当前 QuecPython 支持的各种型号的模块与各个芯片厂家和芯片型号的对应关系。 -QuecPython对应EC618平台硬件支持情况： +### 移芯平台 -![Alt text](../media/background/hardware-platform/11.png) +![移芯平台硬件支持情况](../media/background/hardware-platform/modules_with_eigencomm_chip.png) -QuecPython对应Unsioc平台硬件支持情况： +### 展锐平台 -![Alt text](../media/background/hardware-platform/12.png) +![展锐平台硬件支持情况](../media/background/hardware-platform/modules_with_unisoc_chip.png) -QuecPython对应Qualcomm平台硬件支持情况： +### 高通平台 -![Alt text](../media/background/hardware-platform/13.png) +![高通平台硬件支持情况](../media/background/hardware-platform/modules_with_qualcomm_chip.png) -QuecPython对应ASR平台硬件支持情况： +### ASR 平台 -![Alt text](../media/background/hardware-platform/14.png) \ No newline at end of file +![ASR 平台硬件支持情况](../media/background/hardware-platform/modules_with_asr_chip.png) diff --git a/docs/Application_guide/zh/background/wireless-modules.md b/docs/Application_guide/zh/background/wireless-modules.md index 54b90339aeb6c6b3b36689c81c766e92bcbde500..d56c0bf29625d6b79f791ab283821655c255fafb 100644 --- a/docs/Application_guide/zh/background/wireless-modules.md +++ b/docs/Application_guide/zh/background/wireless-modules.md @@ -1,4 +1,3 @@ - # 无线通信模块简介 QuecPython 是运行在无线通信模块上的开发框架。对于首次接触物联网开发的用户而言，无线通信模块可能是一个相对陌生的概念。本文主要针对无线通信和蜂窝网络本身，以及模块的概念、特性和开发方式进行简要的介绍。 @@ -12,9 +11,9 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 .. details:: 关于通信 物联网无线通信的种类繁多，面向场景多样，因此在具体的功能结构和技术细节上存在较大的差异，但他们的基本流程和模式是类似的。为了便于理解，我们不妨使用人和人之间的通信进行类比。 - + 设想这样一个场景，在没有现代电子科技的情况下，位于两座相邻的山顶上的两人如何实现互相通信？ - +

@@ -22,9 +21,9 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 两座孤单的山头
- + 最简单直接的方法是互相喊叫，利用声音作为信息载体和空气作为传输媒介。但当两人的距离远到一定程度时，声音会衰减或被干扰，这种方法就不太可行了。此时，通过视觉信号进行交流是更好的方式。因此，两人可以使用彩色旗帜或火把作为信息载体和光线作为传输媒介来传递信息。不过，这一方法还有一个前提：双方都需要建立一种共识，了解并遵守不同的旗帜或者火光所代表的含义。这样，两人就可以在相距较远的山头实现低效但相对可靠的通信了。 - +

@@ -32,18 +31,18 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 使用旗语互相交流
- + 这个简陋的双人通信流程包含了通信系统的基本要素：信源、信宿、信道、信息载体和编码规则。信源是产生和发送信息的一端，信宿是接收和处理信息的一端，信道是信号在信源和信宿之间传输的通道，信息载体是承载信息的物理量，编码规则是约定好的信息表示方式。 - + 现代通信同样包含类似的要素，只是更加复杂和高效。有过使用电话线进行拨号上网经历的用户对于“猫”（Modem，调制解调器）应该不会感到陌生。电话线及电话网络是被设计成用于传输 300 Hz 到 3400 Hz 的模拟音频信号的，并不适合直接传输网络数据。要使得计算机之间可以通过电话线实现双向通信，需要满足两个基本条件： - + - 通过操作系统和网卡，实现用户原始数据与可在网络设备间互相传输和辨识的标准数据形式之间的相互转换。这种通过规范化数据格式，使之符合某一标准或共识，从而提升信息传输效率和系统有效性的方法通常称为编码（Coding），在接收端则称为解码（Decoding）。 - 通过“猫”，实现数字信号与可通过电话线传输的模拟信号之间的相互转换。这种通过对原始信号进行各种转换，使之能借助不同的通信介质（或载体）进行传播的方法通常称为调制（Modulation），在接收端则称之为解调（Demodulation）。调制和解调的目的是为了适应信道的特性，克服信道的干扰，提高信号的传输质量。 - + 除了电话线之外，还有许多其他的通信介质，如无线电波、光纤、卫星等。不同的通信介质有不同的特点和优势，需要采用不同的编码和调制技术。例如，无线电波可以在空气中传播，不需要物理连接，但容易受到其他无线电波的干扰，需要采用频率复用、编码复用、正交复用等技术来分配和利用频谱资源。光纤可以传输高速高容量的光信号，具有低损耗、高带宽、抗干扰等优点，但需要特殊的光电转换设备，需要采用脉冲编码调制、相位调制、频移键控等技术来实现光与电之间的转换。卫星可以覆盖广阔的地区，实现远程通信，但需要高功率的发射器和接收器，需要采用多址接入、跳频扩频、正交相移键控等技术来实现卫星与地面之间的通信。 - + 通信技术是一门涉及多个学科领域的综合性科学，它包括信息论、信号处理、电路理论、微波技术、天线技术、网络技术等方面。当然，作为用户和普通开发者，我们无需了解太多细节，各类终端设备和通信模块已经帮助我们处理好了一切。我们需要关注的，只是具体通信方式的选择和使用方法。 - +

@@ -51,20 +50,20 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 无线通信系统简略框图
- + > 需要注意的是，为降低入门难度，本节的讲解并不全面和严谨。对于无线通信原理以及各类物联网无线通信方式的具体内容，本文不做系统介绍。有兴趣的读者可以自行参考《通信原理》《无线通信原理与应用》《物联网》等教材进行自学。 不同的物联网应用场景，对于无线通信的需求存在很大差别。下表展示了当前常见的物联网无线通信技术的特性和使用场景差异。 -| 通信技术 | 速率 | 传输距离 | 功耗 | 成本 | 应用场景 | -| :------: | :--: | :------: | :--: | :--: | ------------------------------------------------------------ | -| Wi-Fi | 高 | 短 | 高 | 中 |
  • 室内无线上网
  • 智能家居
| +| 通信技术 | 速率 | 传输距离 | 功耗 | 成本 | 应用场景 | +| :------: | :--: | :------: | :--: | :--: | -------------------------------------------------------------------------------------------- | +| Wi-Fi | 高 | 短 | 高 | 中 |
  • 室内无线上网
  • 智能家居
| | 蓝牙 | 中 | 短 | 中 | 低 |
  • 资产追踪
  • 定位标签
  • 医疗传感器
  • 智能手表
| -| Zigbee | 低 | 短 | 低 | 低 |
  • 无线传感器
  • 智能家居
| -| UWB | 高 | 短 | 高 | 高 |
  • 高精度定位
| -| 4G | 高 | 长 | 高 | 高 |
  • 可移动通信
  • 车辆追踪
  • 智慧城市
| -| NB-IoT | 低 | 长 | 低 | 中 |
  • 远程抄表
  • 井盖检测
| -| LoRa | 低 | 长 | 低 | 中 |
  • 园区覆盖
  • 近海渔船检测
| +| Zigbee | 低 | 短 | 低 | 低 |
  • 无线传感器
  • 智能家居
| +| UWB | 高 | 短 | 高 | 高 |
  • 高精度定位
| +| 4G | 高 | 长 | 高 | 高 |
  • 可移动通信
  • 车辆追踪
  • 智慧城市
| +| NB-IoT | 低 | 长 | 低 | 中 |
  • 远程抄表
  • 井盖检测
| +| LoRa | 低 | 长 | 低 | 中 |
  • 园区覆盖
  • 近海渔船检测
| ### 蜂窝网络的概念 @@ -91,17 +90,17 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 .. details:: 从 1G 到 5G 蜂窝网络最早由美国贝尔实验室在 1947 年提出，并在 1979 年在日本首次商用。最初的蜂窝网络只能提供模拟语音电话业务，被称为第一代（The 1st Generation，1G）移动通信系统。1G 移动通信系统采用频分多址接入（Frequency Division Multiple Access，FDMA）技术，将不同用户分配到不同频率的信道上。1G 移动通信系统虽然开创了移动通信的时代，但也存在很多缺点，如频谱利用率低、业务种类有限、无高速数据业务、保密性差以及设备成本高等。 - + 为了解决模拟系统中存在的问题，在 20 世纪 90 年代初，第二代（The 2nd Generation，2G）移动通信系统即数字移动通信技术出现了。2G 移动通信系统采用数字调制技术，并使用时分多址接入（Time Division Multiple Access，TDMA）或者码分多址接入（Code Division Multiple Access，CDMA）技术。2G 移动通信系统相比 1G 系统有了很大的改进，如系统容量、保密性和语音通话质量都大幅提升，并且开始提供数据业务。2G 移动通信系统最具代表性的是欧洲的全球移动通信系统（Global System for Mobile Communication，GSM），它使得全球范围内的漫游成为可能，并成为世界上最广泛使用的标准之一。 - + 随着互联网的发展，人们对数据业务的需求也越来越高。为了提高数据传输速率，在 2G 系统的基础上又出现了一些增强技术，如通用分组无线服务（General Packet Radio Service，GPRS）、增强型数据速率 GMS 演进（Enhanced Data for GSM Evolution，EDGE）等。这些技术被称为 2.5G 或 2.75G，它们在 2G 系统的基础上提供了更高的数据传输速率，但仍然不能满足人们对高速宽带数据业务的需求。 - + 2001 年，以数字多媒体移动通信为目的的第三代（The 3rd Generation，3G）移动通信系统进入商用阶段。3G 移动通信系统采用更先进的宽带码分多址技术（Wideband Code Division Multiple Access，WCDMA），并在更高频段使用更大的系统带宽进行数据发送，因而其数据传输速率得到进一步提升。3G 移动通信系统可以同时传输语音和数据信息，支持图像、音乐、视频等多媒体业务。3G 移动通信系统的主要代表有北美的 CDMA2000、欧洲和日本的 WCDMA、中国的时分同步的码分多址技术（Time Division-Synchronization Code Division Multiple Access，TD-SCDMA）等。这些技术都是基于国际电信联盟（International Telecommunication Union，ITU）制定的国际标准 IMT-2000（International Mobile Telecommunications 2000）。 - + 随着 3G 网络的发展，出现了一些增强技术，如高速下行分组接入（High Speed Downlink Packet Access，HSDPA）、高速上行分组接入（High Speed Uplink Packet Access，HSUPA）和增强型高速分组接入 (High-Speed Packet Access+，HSPA+)等。这些技术被称为 3.5G 或 3.75G，它们在 3G 系统的基础上提供了更高的数据传输速率和更好的用户体验。 - + 2011 年，以数字宽带数据移动互联网通信为目的的第四代（The 4th Generation，4G）移动通信系统正式发布。4G 移动通信系统基于扁平化网络架构设计，在 3G 的长期演进（Long Term Evolution，LTE）基础上进行升级。LTE 系统采用正交频分多址（Orthogonal Frequency-Division Multiple Access，OFDMA）、自适应调制编码（Adaptive Modulation and Coding，AMC）和多天线（Multiple-input Multiple-output，MIMO）等关键技术，大大提高了频谱效率和网络性能。4G 移动通信系统拥有非常高的数据传输速度，是 3G 网络的 50 倍以上，其视频图像的传输效果与高清电视相当。4G 移动通信系统最具代表性的是以时分双工（Time Division Duplexing）/频分双工（Frequency Division Duplexing，FDD）为工作模式的高级长期演进技术（Long Term Evolution Advanced，LTE-A）技术。LTE-A 技术在 LTE 技术的基础上采用了载波聚合（Carrier Aggregation，CA）、中继和多点协同传输（Coordinated Multiple Point，CoMP）等技术，在提高网络容量和覆盖范围方面有了突破性进展。 - + 随着智能终端、物联网、云计算等新兴技术和应用的快速发展，人们对移动通信的需求也越来越高。为了满足未来人类信息社会的需求，第五代（The 5th Generation，5G）移动通信系统应运而生。5G 移动通信系统不仅提供了更高的数据传输速率、更低的时延和更高的可靠性，还支持海量的连接和多样化的业务场景。当前，5G 移动通信系统已渗透到工业、医疗、交通等领域，与各种设备和物体深度融合，实现万物互联，为社会经济发展和人类生活质量提供强大的支撑。 蜂窝网络作为一种无线通信技术，从诞生至今已经经历了五代的发展，每一代都对应着不同的技术和标准，为用户提供了更高的数据传输速度，更好的语音通话质量，以及一系列新特性和新功能。从 1G 的模拟语音通信，到 5G 的全场景互联，蜂窝网络已经成为现代社会运转的必不可少的信息基础设施之一。 @@ -128,19 +127,19 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 目前，在国内，物联网领域应用最多的蜂窝通信标准包括 LTE Cat.4，LTE Cat.1 和 NB-IoT。以下的表格对比了它们的特点。 -| 特点 | LTE Cat.4 | LTE Cat.1bis | NB-IoT | -| :------: | :----------------------------------------------------: | :----------------------------------------------------------: | :------------------------------------------------: | -| 下行速率 | 150 Mbps | 10.3 Mbps | 250 kbps | -| 上行速率 | 50 Mbps | 5.2 Mbps | 250 kbps | -| 网络覆盖 | 全球 LTE 网络 | 全球 LTE 网络 | 需要部署新的基站或升级现有基站 | -| 移动性 | 支持高速移动 | 支持 100 km/h 移动 | 不支持移动 | -| 延迟 | 毫秒级 | 毫秒级 | 秒级 | -| 成本 | 较高 | 较低 | 较低 | -| 功耗 | 较高 | 较低 | 较低 | +| 特点 | LTE Cat.4 | LTE Cat.1bis | NB-IoT | +| :------: | :----------------------------------------------------: | :------------------------------------------------------------------: | :------------------------------------------------: | +| 下行速率 | 150 Mbps | 10.3 Mbps | 250 kbps | +| 上行速率 | 50 Mbps | 5.2 Mbps | 250 kbps | +| 网络覆盖 | 全球 LTE 网络 | 全球 LTE 网络 | 需要部署新的基站或升级现有基站 | +| 移动性 | 支持高速移动 | 支持 100 km/h 移动 | 不支持移动 | +| 延迟 | 毫秒级 | 毫秒级 | 秒级 | +| 成本 | 较高 | 较低 | 较低 | +| 功耗 | 较高 | 较低 | 较低 | | 应用场景 | 高清视频监控、路由器、销售终端等需要高速数据传输的场景 | 共享支付、工业控制、车载支付、公网对讲、POS 等需要中速数据传输的场景 | 水表、电表、气表等需要低速数据传输且固定不动的场景 | -| 语音支持 | 支持 VoLTE（语音通话） | 支持 VoLTE（语音通话） | 不支持语音通话 | -| 天线配置 | 2x2 MIMO（多输入多输出） | 1x1 SISO（单输入单输出） | 1x1 SISO（单输入单输出） | -| 带宽 | 20 MHz | 1.4 MHz | 180 kHz | +| 语音支持 | 支持 VoLTE（语音通话） | 支持 VoLTE（语音通话） | 不支持语音通话 | +| 天线配置 | 2x2 MIMO（多输入多输出） | 1x1 SISO（单输入单输出） | 1x1 SISO（单输入单输出） | +| 带宽 | 20 MHz | 1.4 MHz | 180 kHz | ## 初识模块 @@ -207,7 +206,7 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 .. details:: 关于 AT 指令 AT 指令是目前业界历史最悠久，使用领域最广泛的通讯指令集之一。它构建起了一套用户和模块间的完备的双向通信机制：用户（或 MCU）通过向模块发送 AT 指令，控制模块执行包括联网、通话、定位等在内的各类功能，模块则将执行结果和状态返回给用户。这种“一发一收”的机制和相对单一的处理方式非常适合在资源有限的嵌入式环境中使用。如今，市面上的绝大多数模块在出厂时都内置了 AT Server 程序，可以接收、解析和执行特定的 AT 指令。 - +

@@ -249,21 +248,21 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 .. tabset:: LED 闪灯代码 ## 使用 QuecOpen（CSDK） - + ```c #include "ql_application.h" #include "ql_gpio.h" #include - - static quec_gpio_cfg_t led_gpio_cfg[] = + + static quec_gpio_cfg_t led_gpio_cfg[] = { {GPIO_PIN_NO_75, PIN_DIRECTION_OUT, PIN_NO_EDGE, PIN_PULL_DISABLE, PIN_LEVEL_LOW} }; - + static void led_test(void *argv) { ql_gpio_init(led_gpio_cfg[0].gpio_pin_num, led_gpio_cfg[0].pin_dir, led_gpio_cfg[0].pin_pull, led_gpio_cfg[0].pin_level); - + while (1) { ql_gpio_set_level(led_gpio_cfg[0].gpio_pin_num, PIN_LEVEL_LOW); @@ -272,25 +271,25 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 ql_rtos_task_sleep_s(1); } } - + application_init(led_test, "led_test", 2, 2); ``` - + ## 使用 QuecPython - + ```python from machine import Pin import utime as time - + led = Pin(Pin.GPIO15, Pin.OUT, Pin.PULL_DISABLE, 0) - + def led_test(): while 1: led.write(0) time.sleep(1) led.write(1) time.sleep(1) - + if __name__ == "__main__": led_test() ``` @@ -301,14 +300,14 @@ QuecPython 是运行在无线通信模块上的开发框架。对于首次接触 下表比较了标准模式，CSDK 二次开发和脚本二次开发在多个维度的差异。用户可根据实际需求选择最适合自己的开发方式。 -| 特性 | 标准模式 | 二次开发（CSDK） | 二次开发（脚本语言） | 备注 | -| :------: | :------: | :--------------: | :------------------: | :----------------------------------------------------------- | -| 物料成本 | ⭐⭐ | ⭐ | ⭐ |
  • 二次开发时，可将模块作为系统主控使用，节省单片机部分的成本。
| -| 上手门槛 | ⭐ | ⭐⭐⭐ | ⭐ |
  • 模块厂商通常只面向大客户提供 CSDK 开发技术支持和其他相关服务。
| -| 开发难度 | ⭐ | ⭐⭐⭐ | ⭐ |
  • CSDK 开发需要开发者拥有 RTOS 或 Linux 开发经验，普通单片机开发者很难快速掌握。
  • 标准模式仅需用户掌握单片机串口通信和字符串处理方法，无特殊要求。
  • 脚本语言开发方式仅需用户掌握基础语法，无特殊要求。
| -| 开发周期 | ⭐ | ⭐⭐⭐ | ⭐ |
  • CSDK 开发的复杂度决定了其较长的开发周期和较高的开发成本。
| -| 维护成本 | ⭐⭐ | ⭐⭐⭐ | ⭐ |
  • 脚本语言的模块化开发的特性有助于保证其长期运行的稳定性，同时普遍内置了 OTA 功能，便于执行远程升级。
| -| 灵活性 | ⭐ | ⭐⭐⭐ | ⭐⭐ |
  • 标准模式下，开发者通常只能调用串口、ADC 等有限的功能。
  • 使用脚本语言开发时，开发者可以通过内置的功能库调用大部分的模块资源。
  • 使用 CSDK 开发时，开发者可以根据自身需求和想法直接控制所有可用资源。
| -| 性能 | - | ⭐⭐⭐ | ⭐⭐ |
  • 脚本语言的性能远低于 C 语言，因此在对于运行速度、时间精度（时序）、资源数量等要求较高的少部分场合，不建议采用脚本语言开发。
| -| 功耗 | ⭐ | ⭐⭐ | ⭐⭐ |
  • 一般的 4G 模块在自主休眠时的功耗水平在 mA 级别。
  • 在标准模式下，可以通过使用系统主控切断模块供电的方式实现最大限度的省电，最低功耗可达前者的 1/10。
| -| 生态系统 | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ |
  • 标准 AT 指令开发和脚本开发在网络上都具有较多的公开资料和教程。
  • CSDK 开发通常不具备开放生态。
| +| 特性 | 标准模式 | 二次开发（CSDK） | 二次开发（脚本语言） | 备注 | +| :------: | :------: | :--------------: | :------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 物料成本 | ⭐⭐ | ⭐ | ⭐ |
  • 二次开发时，可将模块作为系统主控使用，节省单片机部分的成本。
| +| 上手门槛 | ⭐ | ⭐⭐⭐ | ⭐ |
  • 模块厂商通常只面向大客户提供 CSDK 开发技术支持和其他相关服务。
| +| 开发难度 | ⭐ | ⭐⭐⭐ | ⭐ |
  • CSDK 开发需要开发者拥有 RTOS 或 Linux 开发经验，普通单片机开发者很难快速掌握。
  • 标准模式仅需用户掌握单片机串口通信和字符串处理方法，无特殊要求。
  • 脚本语言开发方式仅需用户掌握基础语法，无特殊要求。
| +| 开发周期 | ⭐ | ⭐⭐⭐ | ⭐ |
  • CSDK 开发的复杂度决定了其较长的开发周期和较高的开发成本。
| +| 维护成本 | ⭐⭐ | ⭐⭐⭐ | ⭐ |
  • 脚本语言的模块化开发的特性有助于保证其长期运行的稳定性，同时普遍内置了 OTA 功能，便于执行远程升级。
| +| 灵活性 | ⭐ | ⭐⭐⭐ | ⭐⭐ |
  • 标准模式下，开发者通常只能调用串口、ADC 等有限的功能。
  • 使用脚本语言开发时，开发者可以通过内置的功能库调用大部分的模块资源。
  • 使用 CSDK 开发时，开发者可以根据自身需求和想法直接控制所有可用资源。
| +| 性能 | - | ⭐⭐⭐ | ⭐⭐ |
  • 脚本语言的性能远低于 C 语言，因此在对于运行速度、时间精度（时序）、资源数量等要求较高的少部分场合，不建议采用脚本语言开发。
| +| 功耗 | ⭐ | ⭐⭐ | ⭐⭐ |
  • 一般的 4G 模块在自主休眠时的功耗水平在 mA 级别。
  • 在标准模式下，可以通过使用系统主控切断模块供电的方式实现最大限度的省电，最低功耗可达前者的 1/10。
| +| 生态系统 | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ |
  • 标准 AT 指令开发和脚本开发在网络上都具有较多的公开资料和教程。
  • CSDK 开发通常不具备开放生态。
| diff --git a/docs/Application_guide/zh/media/background/hardware-platform/5.jpg b/docs/Application_guide/zh/media/background/hardware-platform/5.jpg deleted file mode 100644 index ef3a7172871a84588b8ad9499a446765aa55381f..0000000000000000000000000000000000000000 Binary files a/docs/Application_guide/zh/media/background/hardware-platform/5.jpg and /dev/null differ diff --git a/docs/Application_guide/zh/media/background/hardware-platform/8.png b/docs/Application_guide/zh/media/background/hardware-platform/ASR1603.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/8.png rename to docs/Application_guide/zh/media/background/hardware-platform/ASR1603.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/9.png b/docs/Application_guide/zh/media/background/hardware-platform/ASR1606.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/9.png rename to docs/Application_guide/zh/media/background/hardware-platform/ASR1606.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/10.png b/docs/Application_guide/zh/media/background/hardware-platform/ASR1803.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/10.png rename to docs/Application_guide/zh/media/background/hardware-platform/ASR1803.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/3.png b/docs/Application_guide/zh/media/background/hardware-platform/EC618.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/3.png rename to docs/Application_guide/zh/media/background/hardware-platform/EC618.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/7.png b/docs/Application_guide/zh/media/background/hardware-platform/MDM9205.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/7.png rename to docs/Application_guide/zh/media/background/hardware-platform/MDM9205.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/6.png b/docs/Application_guide/zh/media/background/hardware-platform/RDA8908A.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/6.png rename to docs/Application_guide/zh/media/background/hardware-platform/RDA8908A.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/UIS8850DG.png b/docs/Application_guide/zh/media/background/hardware-platform/UIS8850DG.png new file mode 100644 index 0000000000000000000000000000000000000000..1d1589d63fe204ebf4276e58418bda12fe2dba28 Binary files /dev/null and b/docs/Application_guide/zh/media/background/hardware-platform/UIS8850DG.png differ diff --git a/docs/Application_guide/zh/media/background/hardware-platform/4.png b/docs/Application_guide/zh/media/background/hardware-platform/UIS8910DM.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/4.png rename to docs/Application_guide/zh/media/background/hardware-platform/UIS8910DM.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/1.png b/docs/Application_guide/zh/media/background/hardware-platform/app-dev-steps.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/1.png rename to docs/Application_guide/zh/media/background/hardware-platform/app-dev-steps.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/14.png b/docs/Application_guide/zh/media/background/hardware-platform/modules_with_asr_chip.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/14.png rename to docs/Application_guide/zh/media/background/hardware-platform/modules_with_asr_chip.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/11.png b/docs/Application_guide/zh/media/background/hardware-platform/modules_with_eigencomm_chip.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/11.png rename to docs/Application_guide/zh/media/background/hardware-platform/modules_with_eigencomm_chip.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/13.png b/docs/Application_guide/zh/media/background/hardware-platform/modules_with_qualcomm_chip.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/13.png rename to docs/Application_guide/zh/media/background/hardware-platform/modules_with_qualcomm_chip.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/12.png b/docs/Application_guide/zh/media/background/hardware-platform/modules_with_unisoc_chip.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/12.png rename to docs/Application_guide/zh/media/background/hardware-platform/modules_with_unisoc_chip.png diff --git a/docs/Application_guide/zh/media/background/hardware-platform/2.png b/docs/Application_guide/zh/media/background/hardware-platform/std_mode_vs_qpy_mode.png similarity index 100% rename from docs/Application_guide/zh/media/background/hardware-platform/2.png rename to docs/Application_guide/zh/media/background/hardware-platform/std_mode_vs_qpy_mode.png diff --git a/docs/Application_guide/zh/system/info.md b/docs/Application_guide/zh/system/info.md index c5037ae9bda8e9ef910b8afa7b45be13dedce301..6fb77d050c80cc78287132532beeb181fff3948d 100644 --- a/docs/Application_guide/zh/system/info.md +++ b/docs/Application_guide/zh/system/info.md @@ -1,18 +1,18 @@ # 系统信息 -本文主要介绍如何使用`uos`、`usys`、`modem`等模块查询模组的固件信息、模组剩余内存大小等用户经常关注的信息，本文将不断补充，以方便用户了解模组的基本信息。 +本文主要介绍如何使用 `uos`、`usys`、`modem` 等模块查询模组的固件信息、模组剩余内存大小等用户经常关注的信息，本文将不断补充，以方便用户了解模组的基本信息。 ## 查询固件版本信息 ```python ->>> import uos # 查询QuecPython固件版本信息(QuecPython独有命名规则) +>>> import uos >>> uos.uname() # 返回值(EC600U型号为例) # ('sysname=EC600U-CNLB', 'nodename=EC600U', 'release=1.13.0', 'version=v1.12 on Sat_Nov_19_2022_5:29:48_PM', 'machine=EC600U with QUECTEL', 'qpyver=V0002') ``` -如上所示我们可以查询到模组型号 machine = EC600U with QUECTEL，即 EC600U，但固件中对型号的区分是 sysname = EC600U-CNLB，即这个固件可以在 EC600UCNLB 这个子型号中使用，一般严格遵循字母数字一一对应原则，但是也有例外情况存在，固件具体适用的模组型号以下载区的固件描述和移远官方技术人员描述为准。还可以查询到固件的编译日期和 microPython 版本 version = v1.12 on Sat_Nov_19_2022_5: 29: 48_PM，一般用于判断 BETA 版本(仅用于测试严禁量产的版本)新旧，由于 BETA 版本仅仅用于测试，所以 QuecPython 版本并非是正式发布的，故版本号信息不会变更，只能通过编译时间来确认版本，建议用户进行版本控制时也使用这种方式判断版本，拿到测试版本进行测试时也可以方便的进行版本控制。qpyver = V0002 这个字段即为 QuecPython 固件官网发布的正式版本号，在此不过多赘述。 +如上所示，我们可以查询到模组型号 `machine = EC600U with QUECTEL`，即 EC600U，但固件中对型号的区分是 sysname = EC600U-CNLB，即这个固件可以在 EC600UCNLB 这个子型号中使用，一般严格遵循字母数字一一对应原则，但是也有例外情况存在，固件具体适用的模组型号以下载区的固件描述和移远官方技术人员描述为准。还可以查询到固件的编译日期和 microPython 版本 version = v1.12 on Sat_Nov_19_2022_5: 29: 48_PM，一般用于判断 BETA 版本(仅用于测试严禁量产的版本)新旧，由于 BETA 版本仅仅用于测试，所以 QuecPython 版本并非是正式发布的，故版本号信息不会变更，只能通过编译时间来确认版本，建议用户进行版本控制时也使用这种方式判断版本，拿到测试版本进行测试时也可以方便的进行版本控制。qpyver = V0002 这个字段即为 QuecPython 固件官网发布的正式版本号，在此不过多赘述。 为什么要查询固件版本？ @@ -83,7 +83,7 @@ print('剩余可用RAM空间:{}KB'.format(mem / 1024)) ## 查询 microPython 虚拟机版本 ```python ->>> try:import usys as sys +>>> try:import usys as sys ... except ImportError:import sys >>> sys.implementation # 返回值 @@ -95,7 +95,7 @@ print('剩余可用RAM空间:{}KB'.format(mem / 1024)) ## 查询 microPython 语言版本 ```python ->>> try:import usys as sys +>>> try:import usys as sys ... except ImportError:import sys >>> sys.version # 返回值 diff --git a/docs/Application_guide/zh/system/log.md b/docs/Application_guide/zh/system/log.md index 494909cfbcbd6ddc24b5e4a0e3283271bed3a264..899c03214bc892d73849d987c664d0157b7a7428 100644 --- a/docs/Application_guide/zh/system/log.md +++ b/docs/Application_guide/zh/system/log.md @@ -1,36 +1,34 @@ # 日志功能 -当程序运行出现问题时，日志记录是一种非常有用的工具，它可以帮助我们追踪和定位问题。在MicroPython中，可以使用log模块来记录程序运行中的信息。本文将介绍log模块的使用方法和常见功能。 - - +当程序运行出现问题时，日志记录是一种非常有用的工具，它可以帮助我们追踪和定位问题。在 MicroPython 中，可以使用 log 模块来记录程序运行中的信息。本文将介绍 log 模块的使用方法和常见功能。 ## 日志级别 ### `log.DEBUG` -常量，用来标识LOG等级，最详细的日志信息，通常只在开发和调试时使用。 +常量，用来标识 LOG 等级，最详细的日志信息，通常只在开发和调试时使用。 ### `log.INFO` -常量，用来标识LOG等级，确认一切按预期运行。 +常量，用来标识 LOG 等级，确认一切按预期运行。 ### `log.WARNING` -常量，用来标识LOG等级，表明发生了一些意外，或者指示可能出现问题的情况，但仍然可以继续执行。 +常量，用来标识 LOG 等级，表明发生了一些意外，或者指示可能出现问题的情况，但仍然可以继续执行。 ### `log.ERROR` -常量，用来标识LOG等级，由于更严重的问题，应用程序已不能执行某些功能。 +常量，用来标识 LOG 等级，由于更严重的问题，应用程序已不能执行某些功能。 ### `log.CRITICAL` -常量，用来标识LOG等级，指出应用程序中的严重错误，可能导致应用程序停止运行。 +常量，用来标识 LOG 等级，指出应用程序中的严重错误，可能导致应用程序停止运行。 ## 日志设置 ### `log.basicConfig` -设置日志输出级别，默认为log.INFO，系统只会输出 level 数值大于或等于该 level 的的日志结果。 +设置日志输出级别，默认为 log.INFO，系统只会输出 level 数值大于或等于该 level 的的日志结果。 ```python log.basicConfig(level) @@ -38,7 +36,7 @@ log.basicConfig(level) **参数描述：** -* `level`-日志等级 +- `level` - 日志等级 **返回值描述：** @@ -53,7 +51,7 @@ log.basicConfig(level=log.INFO) ### `log.set_output` -设置日志输出的位置，目前只支持uart和usys.stdout +设置日志输出的位置，目前只支持 uart 和 usys.stdout ```python log.set_output(out) @@ -61,7 +59,7 @@ log.set_output(out) **参数描述：** -* `out` - 日志输出位置，输出到指定串口或者交互口，默认不设置为交互口输出，类型参考示例 +- `out` - 日志输出位置，输出到指定串口或者交互口，默认不设置为交互口输出，类型参考示例 **返回值描述：** @@ -93,7 +91,7 @@ Testlog.info("this is a Test log") # 会输出到交互口 ### `log.getLogger` -获取log对象，对象支持输出不同等级的log信息。 +获取 log 对象，对象支持输出不同等级的 log 信息。 ```python Testlog = log.getLogger(name) @@ -101,15 +99,15 @@ Testlog = log.getLogger(name) **参数描述：** -* `name` - 当前log对象的主题信息，字符串类型 +- `name` - 当前 log 对象的主题信息，字符串类型 **返回值描述：** -* log操作句柄，也可理解成log对象，拥有log输出的方法。 +- log 操作句柄，也可理解成 log 对象，拥有 log 输出的方法。 ### `log.debug` -输出DEBUG级别的日志。 +输出 DEBUG 级别的日志。 ```python Testlog.debug(msg) @@ -117,11 +115,11 @@ Testlog.debug(msg) **参数描述：** -* `msg` - 日志内容，字符串类型 +- `msg` - 日志内容，字符串类型 ### `log.info` -输出INFO级别的日志。 +输出 INFO 级别的日志。 ```python Testlog.info(msg) @@ -129,11 +127,11 @@ Testlog.info(msg) **参数描述：** -* `msg` - 日志内容，字符串类型 +- `msg` - 日志内容，字符串类型 ### `log.warning` -输出WARNING级别的日志。 +输出 WARNING 级别的日志。 ```python Testlog.warning(msg) @@ -141,11 +139,11 @@ Testlog.warning(msg) **参数描述：** -* `msg` - 日志内容，字符串类型 +- `msg` - 日志内容，字符串类型 ### `log.error` -输出ERROR级别的日志。 +输出 ERROR 级别的日志。 ```python Testlog.error(msg) @@ -153,11 +151,11 @@ Testlog.error(msg) **参数描述：** -* `msg` - 日志内容，字符串类型 +- `msg` - 日志内容，字符串类型 ### `log.critical` -输出CRITICAL级别的日志。 +输出 CRITICAL 级别的日志。 ```python Testlog.critical(msg) @@ -165,8 +163,7 @@ Testlog.critical(msg) **参数描述：** -* `msg` - 日志内容，字符串类型 - +- `msg` - 日志内容，字符串类型 **示例：** @@ -184,6 +181,3 @@ Testlog.critical("Test critical message!!") Testlog.info("Test info message!!") Testlog.warning("Test warning message!!") ``` - - - diff --git a/docs/Application_guide/zh/system/power-consumption.md b/docs/Application_guide/zh/system/power-consumption.md index 7cb0d21808782360c34978df98122d02137294bb..33deb57498da7892e25ce15ad44f6b06c41404ae 100644 --- a/docs/Application_guide/zh/system/power-consumption.md +++ b/docs/Application_guide/zh/system/power-consumption.md @@ -1,40 +1,42 @@ # 功耗管理 -## 1. 模组支持的功耗模式 +## 模组支持的功耗模式 + 蜂窝通信模组支持多种工作模式，每种模式的功耗各不相同，常见的工作模式有以下几种： - **ACTIVE**：模组进行LTE数传、GSM通话或RTOS在运行逻辑时的状态，耗流受到具体业务和网络通信制式的影响，CPU本身耗流和网络射频功率都有所不同，故实际功耗在不同工况下会有较大差异。 - **IDEL**：此时模组处于空闲状态，硬件正常在电，RTOS保持运行，但没有任何业务。有业务启动或网络业务呼入时，会立即恢复运行。ECX00U平台会在IDEL模式下降低时钟频率，进入轻睡眠状态。 +**ACTIVE**：模组进行 LTE 数传、GSM 通话或 RTOS 在运行逻辑时的状态，耗流受到具体业务和网络通信制式的影响，CPU 本身耗流和网络射频功率都有所不同，故实际功耗在不同工况下会有较大差异。 + +**IDEL**：此时模组处于空闲状态，硬件正常在电，RTOS 保持运行，但没有任何业务。有业务启动或网络业务呼入时，会立即恢复运行。ECX00U 平台会在 IDEL 模式下降低时钟频率，进入轻睡眠状态。 - **休眠**：休眠模式的前提是模组处于空闲状态且使能autosleep，进入休眠模式后，RTOS暂停运行，模组的时钟频率会变慢，部分外设控制器（UART、SPI等）下电，同时只保留部分中断控制器，达到减小耗流的目的。 +**休眠**：休眠模式的前提是模组处于空闲状态且使能 autosleep，进入休眠模式后，RTOS 暂停运行，模组的时钟频率会变慢，部分外设控制器（UART、SPI 等）下电，同时只保留部分中断控制器，达到减小耗流的目的。 - **PSM**：PSM模式是3GPP协议所规定的一种低功耗模式，这种模式下，模组只会周期性的唤醒并执行业务，其余时间都处于PSM休眠中。PSM休眠时，模组行为和耗流都近似于关机。 +**PSM**：PSM 模式是 3GPP 协议所规定的一种低功耗模式，这种模式下，模组只会周期性的唤醒并执行业务，其余时间都处于 PSM 休眠中。PSM 休眠时，模组行为和耗流都近似于关机。 - **关机**：模组完全下电的状态，此时BB芯片和外设控制器完全关闭，但PMIC仍是在电的。一般可由Powerkey或者RTC唤醒。 +**关机**：模组完全下电的状态，此时 BB 芯片和外设控制器完全关闭，但 PMIC 仍是在电的。一般可由 Powerkey 或者 RTC 唤醒。 **各平台工作模式支持情况和耗流：** -| | ECX00U | ECX00G | ECX00N | ECX00M | ECX00E | BG95/BG77 | EC21 | -| :------- | ------ | ----- | ---- | ------ | ---- | -------- | -------- | -| IDLE（LTE FDD@64ms） | 12.34 mA | 10.1 mA | 17.36 mA | 16.72 mA | 4 mA | 18.9 mA(catm@128ms) | 16.9 mA | -| SLEEP(LTE FDD@64ms) | 2.05mA | 1.99 mA | 1.64 mA | 1.37 mA | 0.64 mA | 1.89 mA(catm@128ms) | 2.74 mA | -| SLEEP(CFUN0) | 1.29mA | 1.03 mA | 0.96 mA | 0.8 mA | 60 μA | 0.575mA | 1.00 mA | -| PSM | 15 μA | 15 μA | 不支持 | 不支持 | 5 μA | 5.10 μA | | -| 关机 | 33 μA | 15 μA | 20 μA | 38 μA | 3 μA | 14.87 μA | 7 μA | +| | ECX00U | ECX00G | ECX00N | ECX00M | ECX00E | BG95/BG77 | EC21 | +| :------------------- | -------- | ------- | -------- | -------- | ------- | ------------------- | ------- | +| IDLE（LTE FDD@64ms） | 12.34 mA | 10.1 mA | 17.36 mA | 16.72 mA | 4 mA | 18.9 mA(catm@128ms) | 16.9 mA | +| SLEEP(LTE FDD@64ms) | 2.05mA | 1.99 mA | 1.64 mA | 1.37 mA | 0.64 mA | 1.89 mA(catm@128ms) | 2.74 mA | +| SLEEP(CFUN0) | 1.29mA | 1.03 mA | 0.96 mA | 0.8 mA | 60 μA | 0.575mA | 1.00 mA | +| PSM | 15 μA | 15 μA | 不支持 | 不支持 | 5 μA | 5.10 μA | | +| 关机 | 33 μA | 15 μA | 20 μA | 38 μA | 3 μA | 14.87 μA | 7 μA | +## 休眠 +休眠是通信模组最常用的一种低功耗模式。模组处于空闲状态时，若 autosleep 被使能，则模组会进入休眠状态。此时，模组会关闭部分 IP 核（如外设控制器和中断控制器等）并且降低时钟频率，从而实现耗流的降低。 -## 2. 休眠 - 休眠是通信模组最常用的一种低功耗模式。模组处于空闲状态时，若autosleep被使能，则模组会进入休眠状态。此时，模组会关闭部分IP核（如外设控制器和中断控制器等）并且降低时钟频率，从而实现耗流的降低。 +### RTOS 休眠原理 -### 2.1 RTOS休眠原理 -以freertos+ARM Cortex-M3为例： +以 freertos + ARM Cortex-M3 为例： **休眠检测机制：** -freertos在上电初始化时，会默认建立一个名为IDLE的task，优先级为0，也就是说，这个task只在RTOS不运行其它task时才会被调度到。休眠相关处理就在IDLE TASK中被执行。freertos在IDLE TASK中，会检测模组的外设是否正在使用，网络是否有数据等休眠条件等，满足休眠条件且autosleep使能时，控制模组进入休眠模式。 +freertos 在上电初始化时，会默认建立一个名为 IDLE 的 task，优先级为 0，也就是说，这个 task 只在 RTOS 不运行其它 task 时才会被调度到。休眠相关处理就在 IDLE TASK 中被执行。freertos 在 IDLE TASK 中，会检测模组的外设是否正在使用，网络是否有数据等休眠条件等，满足休眠条件且 autosleep 使能时，控制模组进入休眠模式。 **休眠机制：** -freertos的休眠使用\_WFI指令进入arm的休眠模式，此时，高速时钟将会关闭，外设会在保存上下文后断电，arm的内核会停止运行，但NVIC（中断控制器）和sram仍可保持运行，任意中断都可将内核唤醒。 +freertos 的休眠使用\_WFI 指令进入 arm 的休眠模式，此时，高速时钟将会关闭，外设会在保存上下文后断电，arm 的内核会停止运行，但 NVIC（中断控制器）和 sram 仍可保持运行，任意中断都可将内核唤醒。 **唤醒机制：** 任意中断均可将内核唤醒，唤醒后内核立即恢复运行，高速时钟恢复输出，为断电的外设恢复上下文，最后恢复应用程序的运行。这种休眠模式不仅实现了耗流的降低，还能较快恢复应用程序的运行。 @@ -43,52 +45,56 @@ freertos的休眠使用\_WFI指令进入arm的休眠模式，此时，高速时 ![Sleep](../media/system/power-consumption/RTOSsleep.png) -### 2.2 通信模组休眠 -根据前一章节可知，设备空闲时保持IDLE状态还是进入休眠状态，完全取决于是否使能autosleep。换言之，设备空闲时进入休眠时没有任何硬性阻碍，而是完全由用户控制。那么，为什么不选择默认进入休眠呢？ +### 通信模组休眠 + +根据前一章节可知，设备空闲时保持 IDLE 状态还是进入休眠状态，完全取决于是否使能 autosleep。换言之，设备空闲时进入休眠时没有任何硬性阻碍，而是完全由用户控制。那么，为什么不选择默认进入休眠呢？ -原因是，某些外设需要一直刷新（如LCD）。然而当模组休眠时，这些外设便不能连续工作，而是不断进行掉电->恢复的过程，严重降低了外设的刷新效率和响应速度。同时，由于休眠时采用低速时钟，任何依赖高速时钟的设备即使不掉电也无法正常工作。故而，模组空闲时会默认保持在IDLE状态，维持所有设备的正常工作。 +原因是，某些外设需要一直刷新（如 LCD）。然而当模组休眠时，这些外设便不能连续工作，而是不断进行掉电->恢复的过程，严重降低了外设的刷新效率和响应速度。同时，由于休眠时采用低速时钟，任何依赖高速时钟的设备即使不掉电也无法正常工作。故而，模组空闲时会默认保持在 IDLE 状态，维持所有设备的正常工作。 -#### 2.2.1 Autosleep机制 +#### Autosleep 机制 -autosleep本质上是操作RTOS休眠检测机制中的一个flag，不使能autosleep时，模组的检测机制就会指令模组保持在IDLE状态。autosleep被使能时，检测机制才认为模组处于允许休眠的状态，从而进入休眠的逻辑。 +autosleep 本质上是操作 RTOS 休眠检测机制中的一个 flag，不使能 autosleep 时，模组的检测机制就会指令模组保持在 IDLE 状态。autosleep 被使能时，检测机制才认为模组处于允许休眠的状态，从而进入休眠的逻辑。 -使用方法参见：[autosleep相关API说明](https://python.quectel.com/doc/API_reference/zh/syslib/pm.html#自动休眠模式控制) +使用方法参见：[autosleep 相关 API 说明](https://python.quectel.com/doc/API_reference/zh/syslib/pm.html#自动休眠模式控制) + +#### 休眠锁机制 -#### 2.2.2 休眠锁机制 在某些场景下，我们既要使模组能够进入休眠，又需要在特定代码段保护某些外设的正常工作，这时，我们就要引入休眠锁机制。 -休眠锁本质上也是一个flag，允许创建多个。生效机制是：只要有任意一个休眠锁处于lock状态，模组就不会进入休眠。 +休眠锁本质上也是一个 flag，允许创建多个。生效机制是：只要有任意一个休眠锁处于 lock 状态，模组就不会进入休眠。 + +使用方法参见：[功耗锁相关 API 说明](https://python.quectel.com/doc/API_reference/zh/syslib/pm.html#创建wake_lock锁) -使用方法参见：[功耗锁相关API说明](https://python.quectel.com/doc/API_reference/zh/syslib/pm.html#创建wake_lock锁) +#### 影响蜂窝模组休眠的因素 -#### 2.2.3 影响蜂窝模组休眠的因素 +##### 底电流 -##### 2.2.3.1 底电流 -影响底电流的功耗的原因主要是系统的主频、打开的IP核的功耗，这块和PMIC 相关。 +影响底电流的功耗的原因主要是系统的主频、打开的 IP 核的功耗，这块和 PMIC 相关。 底电流的影响因素主要来源于硬件，包括模组本身和外设两部分： -模组本身的耗流因素主要包括：系统主频、打开的IP核。 -外设耗电：部分外设使用模组PMIC进行供电，此时其耗流就会由模组负担。 +模组本身的耗流因素主要包括：系统主频、打开的 IP 核。 +外设耗电：部分外设使用模组 PMIC 进行供电，此时其耗流就会由模组负担。 -一般来说，测量底电流时，需要将网络置为CFUN0，使射频停止工作，此时测试出的电流即为模组底电流，正常情况下其特征一般近似直线，如下图： +一般来说，测量底电流时，需要将网络置为 CFUN0，使射频停止工作，此时测试出的电流即为模组底电流，正常情况下其特征一般近似直线，如下图： ![BaseCurrent](../media/system/power-consumption/BaseCurrent.jpg) -##### 2.2.3.2 DRX 周期&Paging -基站寻呼（paging）：当网络状态产生变化/需要对UE进行呼叫/ETWS或CMAS系统发送预警时，基站会对模组发起寻呼，通知处于IDLE状态的模组开始进行通信。 +##### DRX 周期 & Paging -DRX周期：模组网络在没有RRC连接的情况下，会周期性的监听基站寻呼，保证基站寻呼到来时能及时响应。这个监听的周期就叫做DRX周期。DRX周期一般有32ms、64ms、128ms几种，DRX周期越短，同样时间内监听基站信号的次数就越多，功耗就越高，但响应寻呼就更及时。反之，DRX周期越长，功耗越低，但响应寻呼的速度越慢。 +基站寻呼（paging）：当网络状态产生变化/需要对 UE 进行呼叫/ETWS 或 CMAS 系统发送预警时，基站会对模组发起寻呼，通知处于 IDLE 状态的模组开始进行通信。 -附上Sleep（CFUN1）模式下耗流图，图中规律性的凸起即为paging，其周期即DRX周期： +DRX 周期：模组网络在没有 RRC 连接的情况下，会周期性的监听基站寻呼，保证基站寻呼到来时能及时响应。这个监听的周期就叫做 DRX 周期。DRX 周期一般有 32ms、64ms、128ms 几种，DRX 周期越短，同样时间内监听基站信号的次数就越多，功耗就越高，但响应寻呼就更及时。反之，DRX 周期越长，功耗越低，但响应寻呼的速度越慢。 + +附上 Sleep（CFUN1）模式下耗流图，图中规律性的凸起即为 paging，其周期即 DRX 周期： ![Paging](../media/system/power-consumption/Paging.jpg) -##### 2.2.3.3 信号质量 -信号质量差的时候，在完成相同的网络行为时，模组需要更大的发射功率。这会在两个场景下影响模组功耗： -1.进行网络业务时，功耗会上升，除上文描述的发射功率外，如果网络业务出现了因通信质量差导致的重连或重传，整体的业务时间会被拉长，导致功耗进一步上升。 -2.模组休眠时，每次寻呼的峰值耗流会上升，导致整体休眠电流上升。 +##### 信号质量 + +信号质量差的时候，在完成相同的网络行为时，模组需要更大的发射功率。这会在两个场景下影响模组功耗： 1.进行网络业务时，功耗会上升，除上文描述的发射功率外，如果网络业务出现了因通信质量差导致的重连或重传，整体的业务时间会被拉长，导致功耗进一步上升。 2.模组休眠时，每次寻呼的峰值耗流会上升，导致整体休眠电流上升。 -##### 2.2.2.4 业务数据 -模组在进行网络通信时，射频和CPU都会工作，从而产生较大的耗流。一般实际业务中，不会一直进行业务数据传输，常见的业务模式是心跳包。 +##### 业务数据 + +模组在进行网络通信时，射频和 CPU 都会工作，从而产生较大的耗流。一般实际业务中，不会一直进行业务数据传输，常见的业务模式是心跳包。 由于在使用长连接时，如果长期不进行通信，可能会被对端认为已经离线，从而断开连接。所以业务中一般会以固定周期向对端发送一包数据，用来保活长连接。 各心跳周期下的功耗数据(LTE-FDD@64)： @@ -97,54 +103,57 @@ DRX周期：模组网络在没有RRC连接的情况下，会周期性的监听 | 5min | 2.16 mA | 2.13 mA | 1.32 mA | 4.41 mA | 5 mA | | 10min | 1.84 mA | 1.76 mA | 1.03 mA | 3.39 mA | 4.43 mA | +##### RRC 释放时间 +无线资源控制（Radio Resource Control，RRC），又称为无线资源管理（RRM）或者无线资源分配（RRA），是包括呼叫准入控制、切换、功率控制、信道分配、分组调度、端到端 QoS 保障等各自独立的调配和管理算法。模组要进行业务时，需要和基站建立 RRC 连接，只有当 RRC 连接被释放时，模组才能进入休眠。 -##### 2.2.2.5 RRC 释放时间 -无线资源控制（Radio Resource Control，RRC），又称为无线资源管理（RRM）或者无线资源分配（RRA），是包括呼叫准入控制、切换、功率控制、信道分配、分组调度、端到端QoS保障等各自独立的调配和管理算法。模组要进行业务时，需要和基站建立RRC连接，只有当RRC连接被释放时，模组才能进入休眠。 - -但如下图所示，这个RRC连接的生命周期中，只有最开始数秒在进行真正的数据业务。从业务完成到RRC连接释放之间，有一段耗流近似IDLE，却无法休眠的时间，这段耗流的形成和RRC的运营商策略有关： +但如下图所示，这个 RRC 连接的生命周期中，只有最开始数秒在进行真正的数据业务。从业务完成到 RRC 连接释放之间，有一段耗流近似 IDLE，却无法休眠的时间，这段耗流的形成和 RRC 的运营商策略有关： ![Paging](../media/system/power-consumption/RRC.jpg) -为了避免乒乓效应，基站并不会在网络业务完成后立即释放RRC连接，而是会等待一段时间，保证短时间内再次进行业务时无需重新建立RRC连接。RRC连接的时长会因网络环境和运营商策略而不同产生差别，在没有网络数据而RRC未释放的条件下，模组并不会进入休眠。因此RRC连接的时长会显著影响模组功耗。 +为了避免乒乓效应，基站并不会在网络业务完成后立即释放 RRC 连接，而是会等待一段时间，保证短时间内再次进行业务时无需重新建立 RRC 连接。RRC 连接的时长会因网络环境和运营商策略而不同产生差别，在没有网络数据而 RRC 未释放的条件下，模组并不会进入休眠。因此 RRC 连接的时长会显著影响模组功耗。 -### 2.3 休眠模式唤醒源 -蜂窝模组进入休眠模式后，有多种模式可以唤醒模组，包括网络数据、电话、GPIO 中断、Timer等，各种方式实际上都是通过中断来唤醒系统。 +### 休眠模式唤醒源 -#### 2.3.1 Soc 唤醒机制 -模组的休眠状态可以由任意中断唤醒（前提是有效的，部分中断控制器处于功耗考虑也会被关闭），唤醒后会在临界区中恢复设备上下文。此时中断控制器中存有此中断的标志，但是不会运行。等待外设恢复完毕，CPU会退出中断区，此时中断的ISR会立即运行。 +蜂窝模组进入休眠模式后，有多种模式可以唤醒模组，包括网络数据、电话、GPIO 中断、Timer 等，各种方式实际上都是通过中断来唤醒系统。 -#### 2.3.2 网络数据&电话唤醒 +#### SoC 唤醒机制 -网络数据&电话：基站通过paging通知模组有呼叫请求，之后cp（或DSP）通过回调唤醒CPU，并通知CPU有网络数据到来，CPU开始将空口数据搬运进协议栈的buffer，此时上层应用（socket或电话）可从协议栈中获取到网络数据。 +模组的休眠状态可以由任意中断唤醒（前提是有效的，部分中断控制器处于功耗考虑也会被关闭），唤醒后会在临界区中恢复设备上下文。此时中断控制器中存有此中断的标志，但是不会运行。等待外设恢复完毕，CPU 会退出中断区，此时中断的 ISR 会立即运行。 + +#### 网络数据&电话唤醒 + +网络数据&电话：基站通过 paging 通知模组有呼叫请求，之后 cp（或 DSP）通过回调唤醒 CPU，并通知 CPU 有网络数据到来，CPU 开始将空口数据搬运进协议栈的 buffer，此时上层应用（socket 或电话）可从协议栈中获取到网络数据。 ![Network](../media/system/power-consumption/Networkwakeup.png) -#### 2.3.3 GPIO 中断唤醒 +#### GPIO 中断唤醒 -GPIO可用的前提：GPIO在模组休眠时保持供电，且其连接的中断的控制器也未被关闭。 -GPIO硬件被触发时，其连接的中断控制器会立即响应并唤醒CPU，CPU会将外设的上下文恢复，然后退出临界区。此时ISR检测到GPIO的中断已经触发，会立即执行GPIO的中断函数（一般是发消息触发GPIO绑定的回调），最后触发该GPIO绑定的回调函数。 +GPIO 可用的前提：GPIO 在模组休眠时保持供电，且其连接的中断的控制器也未被关闭。 +GPIO 硬件被触发时，其连接的中断控制器会立即响应并唤醒 CPU，CPU 会将外设的上下文恢复，然后退出临界区。此时 ISR 检测到 GPIO 的中断已经触发，会立即执行 GPIO 的中断函数（一般是发消息触发 GPIO 绑定的回调），最后触发该 GPIO 绑定的回调函数。 ![GPIO](../media/system/power-consumption/GPIO.png) -#### 2.3.4 timer 唤醒 -Timer超时会触发系统定时器绑定的中断，中断控制器会立即响应并唤醒CPU，CPU会将外设的上下文恢复，然后退出临界区。最后通过ISR触发timer绑定的回调。 +#### timer 唤醒 + +Timer 超时会触发系统定时器绑定的中断，中断控制器会立即响应并唤醒 CPU，CPU 会将外设的上下文恢复，然后退出临界区。最后通过 ISR 触发 timer 绑定的回调。 ![Timer](../media/system/power-consumption/timer.png) -#### 2.3.5 唤醒源获取 +#### 唤醒源获取 + 实际上，从上面三条可以看到，凡是涉及到唤醒行为，都要通过中断控制器进行，这正是休眠模式的特征：由任意中断唤醒。由此，我们可以得出结论：不需要刻意去获取唤醒源，唤醒行为必然对应着特定中断的触发。 -#### 2.3.6 唤醒后业务处理 -上一条已经做出结论：不需要刻意去获取唤醒源，唤醒行为必然对应着特定中断的触发。那么业务处理的原则也就很简单了：模组出休眠逻辑中，设备的上下文恢复后退出临界区，唤醒中断的ISR就会立即去执行，我们需要的业务逻辑直接由此触发即可，一般都是采用在ISR发送消息或者信号量，来触发对应业务的执行。 +#### 唤醒后业务处理 + +上一条已经做出结论：不需要刻意去获取唤醒源，唤醒行为必然对应着特定中断的触发。那么业务处理的原则也就很简单了：模组出休眠逻辑中，设备的上下文恢复后退出临界区，唤醒中断的 ISR 就会立即去执行，我们需要的业务逻辑直接由此触发即可，一般都是采用在 ISR 发送消息或者信号量，来触发对应业务的执行。 -#### 2.3.7 弱信号休眠方案 +#### 弱信号休眠方案 + +弱信号会带来一系列造成功耗上升的改变：发射功率上升、频繁触发小区切换、业务中出现重传和重连、DRX 周期降低等等……以下介绍部分弱信号休眠方案： 1.控制 DRX 周期使之尽量长，减少网络发射的次数。在发射功率较高时，减少发射次数，可以减少耗流。 2.使用 RRC 快速释放，降低业务完成后 rrc 连接的保持时间。 3.提高小区测量阈值，避免频繁触发小区检测。 + +#### 典型应用 -弱信号会带来一系列造成功耗上升的改变：发射功率上升、频繁触发小区切换、业务中出现重传和重连、DRX周期降低等等……以下介绍部分弱信号休眠方案： -1.控制DRX周期使之尽量长，减少网络发射的次数。在发射功率较高时，减少发射次数，可以减少耗流。 -2.使用RRC快速释放，降低业务完成后rrc连接的保持时间。 -3.提高小区测量阈值，避免频繁触发小区检测。 -#### 2.3.8 典型应用 **网络例程：网络主动发送心跳包&网络接收寻呼唤醒** ```python @@ -203,10 +212,10 @@ c.publish(pub_path, b"hello") print("Publish topic: %s, msg: hello" % pub_path) _thread.start_new_thread(wait_msg, ())#监听MQTT,等待数据到来，本质上就是等待寻呼 - + ``` -**硬件例程1：GPIO/keypad 等外部硬件中断唤醒** +**硬件例程 1：GPIO/keypad 等外部硬件中断唤醒** ```python import pm @@ -218,7 +227,7 @@ def fun(args): f = open("/usr/log.txt", "a+") #以追加模式打开一个文件，低功耗时无法连接交互口，在文件中保存调试信息 f.write('### interrupt {} ###'.format(args)) # args[0]:gpio号 args[1]:上升沿或下降沿，写入文件 f.close()#关闭文件，保存写入信息 - + extint = ExtInt(ExtInt.GPIO1, ExtInt.IRQ_FALLING, ExtInt.PULL_PU, fun)#给GPIO1绑定回调fuction extint.enable()#使能GPIO中断 @@ -227,7 +236,7 @@ extint.enable()#使能GPIO中断 #若文件中写入了正确的信息，说明低功耗模式下GPIO中断有效唤醒了模组，并且执行了其绑定的中断。 ``` -**硬件例程2：UART唤醒和接收** +**硬件例程 2：UART 唤醒和接收** ```python """ @@ -260,8 +269,8 @@ class Example_uart(object): def callback(self, para): if(0 == para[0]): - self.uart.write("UART WAKRUP!")#在串口RX回调中发送特定数据 - + self.uart.write("UART WAKRUP!")#在串口RX回调中发送特定数据 + def uartWrite(self, msg): self.uart.write(msg) @@ -283,7 +292,7 @@ if __name__ == "__main__": ``` -**硬件例程3：利用功耗锁在休眠唤醒时保护硬件时序和状态** +**硬件例程 3：利用功耗锁在休眠唤醒时保护硬件时序和状态** ```python from machine import SPI @@ -294,63 +303,62 @@ spi_obj = SPI(0, 0, 1) if __name__ == '__main__': pm.autosleep(1) - + lpm_fd = pm.create_wakelock("test", len("test"))#锁住功耗锁，保护SPI读写 r_data = bytearray(5) # 创建接收数据的buff data = b"world" # 测试数据 ret = spi_obj.write_read(r_data, data, 5) # 写入数据并接收 spi_log.info(r_data) - + lpm_fd = pm.create_wakelock("test", len("test"))#释放功耗锁，允许在SPI不进行读写时进入低功耗 ``` +#### 常见问题 - -#### 2.3.7 常见问题 **1.无法正常进入休眠:排查唤醒源** -| 常见唤醒源 | 备注 | -| ---------- | ----------------------------------------- | -| 功耗锁 | 任一把锁未释放都无法休眠，需要全部释放 | -| UART | UART有数据时不可休眠 | -| USB | USB插入不可休眠 | -| Thread | Thread运行时不会进入IDLE，无法休眠 | -| SPI | SPI有数据时无法休眠 | -| LVGL | LVGL会不断刷新，休眠使应使LVGL先进入sleep | +| 常见唤醒源 | 备注 | +| ---------- | --------------------------------------------- | +| 功耗锁 | 任一把锁未释放都无法休眠，需要全部释放 | +| UART | UART 有数据时不可休眠 | +| USB | USB 插入不可休眠 | +| Thread | Thread 运行时不会进入 IDLE，无法休眠 | +| SPI | SPI 有数据时无法休眠 | +| LVGL | LVGL 会不断刷新，休眠使应使 LVGL 先进入 sleep | **2.正常进入休眠后底电流高，检测硬件和网络环境，需要检查的部分包括：** -| 耗流源 | 备注 | -| ------- | -------------------------------------------- | -| PWM | PWM控制器可在休眠时使用低速时钟进行输出 | -| GPIO | GPIO休眠时能够保持对外输出，需要检查是否漏电 | -| VDD_EXT | 常开电源，休眠时需要检查漏电 | +| 耗流源 | 备注 | +| ------- | --------------------------------------------- | +| PWM | PWM 控制器可在休眠时使用低速时钟进行输出 | +| GPIO | GPIO 休眠时能够保持对外输出，需要检查是否漏电 | +| VDD_EXT | 常开电源，休眠时需要检查漏电 | **3.网络环境导致功耗高** -| 影响因素 | 备注 | -| -------- | ------------------------------- | -| 射频功耗 | 检查paging时耗流峰值和网络质量 | -| RRC周期 | 检查业务完成到RRC链接释放的时间 | +| 影响因素 | 备注 | +| -------- | --------------------------------- | +| 射频功耗 | 检查 paging 时耗流峰值和网络质量 | +| RRC 周期 | 检查业务完成到 RRC 链接释放的时间 | +## PSM 模式 +### 什么是 PSM 模式 -## 3. PSM 模式 -### 3.1 什么是PSM 模式 -PSM模式是在UE空闲一定时间后关闭信号的发送和接收，允许与AS（接入层）相关的功能，这相当于部分关闭，降低了天线、射频、信令处理等功耗。 +PSM 模式是在 UE 空闲一定时间后关闭信号的发送和接收，允许与 AS（接入层）相关的功能，这相当于部分关闭，降低了天线、射频、信令处理等功耗。 -PSM模式的优点是可以长时间睡眠，但缺点是无法及时应对终端接收（移动终端、MT）服务。主要应用在远程抄表和一些对实时性要求不高的场景中。 +PSM 模式的优点是可以长时间睡眠，但缺点是无法及时应对终端接收（移动终端、MT）服务。主要应用在远程抄表和一些对实时性要求不高的场景中。 -### 3.2 PSM 模式原理 +### PSM 模式原理 -PSM是一种比常规休眠功耗功耗更低的模式，但其运行需要网络侧支持。 +PSM 是一种比常规休眠功耗功耗更低的模式，但其运行需要网络侧支持。 -启用PSM是，需要先向基站发送请求（通过ATTACH或TA_UPDATER携带定时器信息）。基站若支持进入PSM，则会在对应的REQUEST中下发定时器信息，需要注意的是，实际PSM的参数会使用基站下发的值，并不一定和我们请求的值相同。 +启用 PSM 是，需要先向基站发送请求（通过 ATTACH 或 TA_UPDATER 携带定时器信息）。基站若支持进入 PSM，则会在对应的 REQUEST 中下发定时器信息，需要注意的是，实际 PSM 的参数会使用基站下发的值，并不一定和我们请求的值相同。 -模组会以基站下发的值来配置定时器时间，当模组进入IDLE且ACT定时器超时，模组会关闭CPU和一切射频，此时相当于部分关机，只是保留了比关机更多的唤醒源，一般包括ACT、TAU定时器和PSM_INT。功耗一般下降到微安级别。此时由于基站已经记录UE使用PSM，不会断开此UE的连接，下次如果在同一小区内重新开机，就无需拨号，直接用原有的IP等信息，进一步减少了功耗。 +模组会以基站下发的值来配置定时器时间，当模组进入 IDLE 且 ACT 定时器超时，模组会关闭 CPU 和一切射频，此时相当于部分关机，只是保留了比关机更多的唤醒源，一般包括 ACT、TAU 定时器和 PSM_INT。功耗一般下降到微安级别。此时由于基站已经记录 UE 使用 PSM，不会断开此 UE 的连接，下次如果在同一小区内重新开机，就无需拨号，直接用原有的 IP 等信息，进一步减少了功耗。 -当PSM TAU定时器超时、RTC_alarm到期或PSM_INT等唤醒源被触发时，模组会被唤醒。由于硬件上CPU（包括SRAM）和PA均被下电，此时并不能恢复休眠前运行状态，而是要重新走开机流程。开机后可进行网络业务，网络业务完成且RRC被释放后ACT定时器编开始计时，超时便进入PSM中。 +当 PSM TAU 定时器超时、RTC_alarm 到期或 PSM_INT 等唤醒源被触发时，模组会被唤醒。由于硬件上 CPU（包括 SRAM）和 PA 均被下电，此时并不能恢复休眠前运行状态，而是要重新走开机流程。开机后可进行网络业务，网络业务完成且 RRC 被释放后 ACT 定时器编开始计时，超时便进入 PSM 中。 **整体流程如下：** @@ -358,61 +366,62 @@ PSM是一种比常规休眠功耗功耗更低的模式，但其运行需要网 最终，在两个定时器的作用下，模组会进行周期性的休眠，唤醒切换，但只有在唤醒的时候，才能进行网络业务，休眠时是无法响应网络寻呼的。 -**耗流特征如下(本示例每1min唤醒一次)：** +**耗流特征如下(本示例每 1min 唤醒一次)：** ![Timer](../media/system/power-consumption/PSMCycle.jpg) -#### 3.2.1 ACT和TAU定时器 +#### ACT 和 TAU 定时器 -ACT，又称T3324，当模组完成网络业务（即RRC连接释放时）开始计时，超时后立即进入PSM。 +ACT，又称 T3324，当模组完成网络业务（即 RRC 连接释放时）开始计时，超时后立即进入 PSM。 -TAU，又称T3412，当模组完成网络业务（即RRC连接释放时）开始计时，超时后，若模组在PSM模式，会将模组唤醒。 +TAU，又称 T3412，当模组完成网络业务（即 RRC 连接释放时）开始计时，超时后，若模组在 PSM 模式，会将模组唤醒。 它们的时序关系如下图： ![Timer](../media/system/power-consumption/3GPP_PSM_TIMER.png) -### 3.3 PSM &RTC 模式下的功耗以及各平台支持情况 +### PSM &RTC 模式下的功耗以及各平台支持情况 + +| | ECX00U | ECX00G | ECX00M | ECX00E | BG95/BG77 | +| -------- | ------ | ------ | ------ | ------------------- | --------- | +| PSM | 15 uA | 15 uA | 不支持 | 5uA | 5.10 uA | +| RTC+关机 | 33 uA | 15 uA | 38 uA | 5uA(with hibernate) | 14.87 uA | -| | ECX00U | ECX00G | ECX00M | ECX00E | BG95/BG77 | -| -------- | ------ | ---- | ------------ | ---- | ---- | -| PSM | 15 uA | 15 uA | 不支持 | 5uA | 5.10 uA | -| RTC+关机 | 33 uA | 15 uA | 38 uA | 5uA(with hibernate) | 14.87 uA | +### PSM 唤醒源 -### 3.4 PSM 唤醒源 -#### 3.4.1 PSM INT +#### PSM INT -PSM_INT一般是模组PMIC预留的引脚，其固定作用就是唤醒PSM。不需要额外的配置，进入PSM休眠后按照指定方式触发即可唤醒模组。 +PSM_INT 一般是模组 PMIC 预留的引脚，其固定作用就是唤醒 PSM。不需要额外的配置，进入 PSM 休眠后按照指定方式触发即可唤醒模组。 -但对于ECX00E模组，没有专门的PSM_INT,而是由wakeup引脚实现此功能，使用方法参见wakeup引脚 +但对于 ECX00E 模组，没有专门的 PSM_INT,而是由 wakeup 引脚实现此功能，使用方法参见 wakeup 引脚 -#### 3.4.2 RTC 闹钟 +#### RTC 闹钟 -除关机之外，RTC闹钟也能在PSM模式下生效。其使用方法与关机RTC闹钟相同。 +除关机之外，RTC 闹钟也能在 PSM 模式下生效。其使用方法与关机 RTC 闹钟相同。 -参见：[RTC相关API说明](https://python.quectel.com/doc/API_reference/zh/peripherals/machine.RTC.html) +参见：[RTC 相关 API 说明](https://python.quectel.com/doc/API_reference/zh/peripherals/machine.RTC.html) -#### 3.4.3 Powerkey +#### Powerkey -Powerkey也能唤醒PSM模式，作用原理和触发开机一致。 +Powerkey 也能唤醒 PSM 模式，作用原理和触发开机一致。 -#### 3.4.4 TAU Timer +#### TAU Timer -上文描述过，TAU定时器超时会唤醒模组。 +上文描述过，TAU 定时器超时会唤醒模组。 -> 注意：BG95/BG77 的TAU Timer 和RTC alarm复用了同一个PMIC唤醒源，因此PSM和RTC不能同时使用 +> 注意：BG95/BG77 的 TAU Timer 和 RTC alarm 复用了同一个 PMIC 唤醒源，因此 PSM 和 RTC 不能同时使用 -### 3.5 PSM 典型应用 +### PSM 典型应用 -PSM功耗虽低，但有以下缺点： +PSM 功耗虽低，但有以下缺点： -1.PSM启动时需要走重启逻辑，应用恢复时间远远长于autosleep； +1.PSM 启动时需要走重启逻辑，应用恢复时间远远长于 autosleep； 2.产生小区切换时，无法拿到原有的网络信息，导致出现掉网和重新注网问题，反而会使耗流上升； -3.PSM休眠时不响应寻呼 +3.PSM 休眠时不响应寻呼 -所以PSM的应用场景一般满足以下三个条件： +所以 PSM 的应用场景一般满足以下三个条件： 1.定时任务间隔较长，可忽略启动时间 @@ -420,46 +429,45 @@ PSM功耗虽低，但有以下缺点： 3.对数据实时性要求不高 -#### 3.5.1 如何进入PSM +#### 如何进入 PSM -需要在联网，且确认运营商支持PSM的前提下使用。根据业务需求决定ACT和TAU的周期，通过API设置即可： +需要在联网，且确认运营商支持 PSM 的前提下使用。根据业务需求决定 ACT 和 TAU 的周期，通过 API 设置即可： -参见：[PSM相关API说明](https://python.quectel.com/doc/API_reference/zh/syslib/pm.html#设置PSM模式的控制时间) +参见：[PSM 相关 API 说明](https://python.quectel.com/doc/API_reference/zh/syslib/pm.html#设置PSM模式的控制时间) -#### 3.5.2 PSM INT 应用 +#### PSM INT 应用 -EC600U和BG95支持此引脚，上升沿触发，进入PSM时模组PMIC会默认配置此引脚，确保触发方式正确即可在PSM模式下唤醒模组。 +EC600U 和 BG95 支持此引脚，上升沿触发，进入 PSM 时模组 PMIC 会默认配置此引脚，确保触发方式正确即可在 PSM 模式下唤醒模组。 -> ECX00E使用wakeup引脚，需要额外进行配置 +> ECX00E 使用 wakeup 引脚，需要额外进行配置 -#### 3.5.3 弱信号PSM 方案 +#### 弱信号 PSM 方案 -弱信号下PSM处理机制如下： +弱信号下 PSM 处理机制如下： -1.基站下发定时器后，模组即会按定时器设置进入PSM。因此只要成功接收到基站下发的定时器，即使在PSM过程中网络通信断开，在下一次联网前，仍能保持正确的周期。 +1.基站下发定时器后，模组即会按定时器设置进入 PSM。因此只要成功接收到基站下发的定时器，即使在 PSM 过程中网络通信断开，在下一次联网前，仍能保持正确的周期。 -2.如果出现了连不上网络或者小区切换的情况，模组会主动放弃原有的连接，重新触发驻网和拨号，保证网络可用，并且在注网时会再次请求PSM。 +2.如果出现了连不上网络或者小区切换的情况，模组会主动放弃原有的连接，重新触发驻网和拨号，保证网络可用，并且在注网时会再次请求 PSM。 -3.网络质量过差导致PSM无法正常请求和下发：使用关机和RTC闹钟唤醒来代替PSM模式 +3.网络质量过差导致 PSM 无法正常请求和下发：使用关机和 RTC 闹钟唤醒来代替 PSM 模式 -#### 3.5.4 不支持PSM 的运营商的方案 +#### 不支持 PSM 的运营商的方案 -如果运营商不支持PSM，基站会设法阻碍模组进入PSM。常见的行为有三种： +如果运营商不支持 PSM，基站会设法阻碍模组进入 PSM。常见的行为有三种： -1. 在模组向基站请求定时器时，直接REJECT请求(此情况很少，绝大部分为后两种)。 -2. 下发不成对的ACT和TAU定时器，不成对的定时器无法使模组进入PSM。 +1. 在模组向基站请求定时器时，直接 REJECT 请求(此情况很少，绝大部分为后两种)。 +2. 下发不成对的 ACT 和 TAU 定时器，不成对的定时器无法使模组进入 PSM。 3. 不下发定时器 -此时，只能通过RTC闹钟定时唤醒关机来实现类似的业务需求，这种方式也能达到在无需数据交互时减少耗流。但从关机状态重新开机相比PSM多了一个注网和拨号的动作，在每次唤醒注网时都会产生更多射频功耗。 +此时，只能通过 RTC 闹钟定时唤醒关机来实现类似的业务需求，这种方式也能达到在无需数据交互时减少耗流。但从关机状态重新开机相比 PSM 多了一个注网和拨号的动作，在每次唤醒注网时都会产生更多射频功耗。 -> 此外，ECX00E在不支持PSM时需要通过pm.forcehib()方法强制进入hibernate休眠，因为此平台关机时RTC无法维持运行。 -> +> 此外，ECX00E 在不支持 PSM 时需要通过 pm.forcehib()方法强制进入 hibernate 休眠，因为此平台关机时 RTC 无法维持运行。 -### 3.6 常见问题排查 +### 常见问题排查 -**1.PSM设置返回True，但无法进入** +**1.PSM 设置返回 True，但无法进入** -基站可能不支持PSM，确认这一点的方法是从CPlog中查看基站下发的信息，需要查看的条目为： +基站可能不支持 PSM，确认这一点的方法是从 CPlog 中查看基站下发的信息，需要查看的条目为： **ATTACH_REQUEST** @@ -469,46 +477,37 @@ EC600U和BG95支持此引脚，上升沿触发，进入PSM时模组PMIC会默认 **TA_UPDATE_ACCEPT** -如图，模组设置成功后，REQUEST一定会带有成对的定时器信息，我们需要关注ACCEPT中基站是否正确下发了定时器信息。 +如图，模组设置成功后，REQUEST 一定会带有成对的定时器信息，我们需要关注 ACCEPT 中基站是否正确下发了定时器信息。 ![Timer](../media/system/power-consumption/PSMRequest.png) -如图，网络环境不支持PSM，基站未下发成对的定时器，只下发了一个ACT定时器，这时候是不能进入PSM的： +如图，网络环境不支持 PSM，基站未下发成对的定时器，只下发了一个 ACT 定时器，这时候是不能进入 PSM 的： ![Timer](../media/system/power-consumption/PSMWrongACCEPT.png) -**2.PSM成功进入，但休眠-唤醒周期与设置的不同** +**2.PSM 成功进入，但休眠-唤醒周期与设置的不同** -同样的，查看以上CPlog条目，基站下发的定时器周期可能不等于设置的值，且模组最终以基站下发的值为准。 +同样的，查看以上 CPlog 条目，基站下发的定时器周期可能不等于设置的值，且模组最终以基站下发的值为准。 -## 4. 常见应用场景 -**对讲机低功耗方案：** - -RRC快速释放：对讲机的网络业务是不固定的，随机触发的。快速释放RRC能够保证在任何一个随机时间点，都能在对讲后快速释放RRC，从而进入休眠。 +## 常见应用场景 +**对讲机低功耗方案：** +RRC 快速释放：对讲机的网络业务是不固定的，随机触发的。快速释放 RRC 能够保证在任何一个随机时间点，都能在对讲后快速释放 RRC，从而进入休眠。 **tracker 低功耗方案：** -RRC快速释放：tracker是一个定位器，位置是不固定的，定期进行一次定位。可使用RRC快速释放减少RRC连接保持的时长，从而降低整体耗流。 - - +RRC 快速释放：tracker 是一个定位器，位置是不固定的，定期进行一次定位。可使用 RRC 快速释放减少 RRC 连接保持的时长，从而降低整体耗流。 **表计、门磁低功耗方案：** -PSM，此类产品的唤醒间隔较长，且一般不会经常移动，对数据的实时性要求不高，可采用PSM。若需要在无网络或运营商不支持的情况下使用，可采用关机+RTC闹钟定时唤醒的方案。 - - +PSM，此类产品的唤醒间隔较长，且一般不会经常移动，对数据的实时性要求不高，可采用 PSM。若需要在无网络或运营商不支持的情况下使用，可采用关机+RTC 闹钟定时唤醒的方案。 **根据功耗需求选型：** -uA级耗流：必须选择支持PSM或关机RTC唤醒的型号 - - - -mA级耗流：全平台支持autosleep，根据其它需求评估适合型号 - +uA 级耗流：必须选择支持 PSM 或关机 RTC 唤醒的型号 +mA 级耗流：全平台支持 autosleep，根据其它需求评估适合型号 **待机时间推算方法：** @@ -518,7 +517,6 @@ mA级耗流：全平台支持autosleep，根据其它需求评估适合型号 3.从待机时间的计算公式：待机时间 = 电池容量/ 平均待机电流 -例如：已知电池容量800mah，给ECX00E供电。ECX00E在autosleep模式下保持网络连接（LTE-FDD@64）时平均待机电流约0.64mA。 - -则实际待机时间T=800mah/0.64mA=1250h +例如：已知电池容量 800mah，给 ECX00E 供电。ECX00E 在 autosleep 模式下保持网络连接（LTE-FDD@64）时平均待机电流约 0.64mA。 +则实际待机时间 T=800mah/0.64mA=1250h diff --git a/docs/Application_guide/zh/system/power-manager.md b/docs/Application_guide/zh/system/power-manager.md index 72db8810e1d4ab6629f34fa04dc3c91827248231..f83ed2d64754262bf1be94d6421672deaba15fc6 100644 --- a/docs/Application_guide/zh/system/power-manager.md +++ b/docs/Application_guide/zh/system/power-manager.md @@ -1,6 +1,6 @@ # 电源管理 -## 1.电源管理概述 +## 电源管理概述 随着SOC技术的发展，电源管理技术也在不断革新。现今的SOC一般采用PMU（Power Management Unit，电源管理单元）来进行供电，其设计目标一般包括以下几点： @@ -129,7 +129,7 @@ RESET一般是直接连接在CPU上的，其触发的动作并不涉及PMIC， #### 5.1.4 自定义Powerkey短按长按功能 -一般是在能够双边触发的powerkey上实现。实现方法是在按下时的中断里启动一个定时器，在抬起的中断里关闭这个定时器。如果定时器尚未到期，就被pwrkey抬起的中断关闭，则判定为短按。如果直到超时都没有抬起的中断触发，则判定为长按。定时器的时间就是界定短按和长按的阈值。 +一般是在能够双边触发的 powerkey 上实现。实现方法是在按下时的中断里启动一个定时器，在抬起的中断里关闭这个定时器。如果定时器尚未到期，就被 pwrkey 抬起的中断关闭，则判定为短按。如果直到超时都没有抬起的中断触发，则判定为长按。定时器的时间就是界定短按和长按的阈值。 配置powerkey自定义功能用法：[class PowerKey - power key按键回调注册功能 ](https://python.quectel.com/doc/API_reference/zh/peripherals/misc.PowerKey.html) @@ -328,13 +328,13 @@ PMIC充电管理单元的实现形式一般是一个linear charger（线性充 涓流模式/激活模式：电池电压低于某个阈值时，电池管理系统会禁止向电池中充电，此时需要用小电流激活电池，使电池电压恢复到可充电状态。 -预充电模式/小电流模式：当电池电压较低时，如果进行全功率充电，由于电池的化学特性，会给电池带来高温和过压等安全隐患。因此，当电压小于全电流充电阈值时，充电管理电源会用较小电流和电压对VBAT进行充电。 +预充电模式/小电流模式：当电池电压较低时，如果进行全功率充电，由于电池的化学特性，会给电池带来高温和过压等安全隐患。因此，当电压小于全电流充电阈值时，充电管理电源会用较小电流和电压对 VBAT 进行充电。 全电流模式/快速充电模式：此时电池已经到达能够安全进行全功率充电的电压，保持一个较大的恒定电流，快速对电池进行充电。 -恒压充电：电池较接近满载电压，此时保持恒压，充电电流随VBAT和充电单元间压差减小逐渐下降，直到到达满电，充电停止。 +恒压充电：电池较接近满载电压，此时保持恒压，充电电流随 VBAT 和充电单元间压差减小逐渐下降，直到到达满电，充电停止。 -复充：充电完成后，轮询VBAT电压，发现VBAT滑落到复充触发电压以下时，则进行恒压充电。 +复充：充电完成后，轮询 VBAT 电压，发现 VBAT 滑落到复充触发电压以下时，则进行恒压充电。 **典型的充电电流、电压曲线图如下：** @@ -350,9 +350,11 @@ PMIC充电管理单元的实现形式一般是一个linear charger（线性充 #### 6.2.2 实现方案原理 充电单元本身含有控制充电阶段的FSM，可以在CPU不运行的情况下控制充电行为，所以我们要实现的即是在不开机的情况下，监控充电状态（如VBAT电压、电池温度等，可能还需要进行显示）。 -此时，可在VBUS被电源拉高时通过硬件联动powerkey（如果PMIC支持charger插入触发开机，则无需触发powerkey，使能charger触发开机即可），CPU上电。 +充电单元本身含有控制充电阶段的 FSM，可以在 CPU 不运行的情况下控制充电行为，所以我们要实现的即是在不开机的情况下，监控充电状态（如 VBAT 电压、电池温度等，可能还需要进行显示）。 -关机充电的逻辑停留在boot中实现，主要包括轮询电池状态和LCD显示等业务，但并不从boot中跳转进RTOS阶段，如果此时检测到powerkey再次被触发，就进入正常的开机流程。 +此时，可在 VBUS 被电源拉高时通过硬件联动 powerkey（如果 PMIC 支持 charger 插入触发开机，则无需触发 powerkey，使能 charger 触发开机即可），CPU 上电。 + +关机充电的逻辑停留在 boot 中实现，主要包括轮询电池状态和 LCD 显示等业务，但并不从 boot 中跳转进 RTOS 阶段，如果此时检测到 powerkey 再次被触发，就进入正常的开机流程。 ![PoweroffCharger](../media/system/power-manager/PoweroffCharger.png) diff --git a/docs/FAQ/zh/mp/hd-design.md b/docs/FAQ/zh/mp/hd-design.md index 0c6c0d7a89e665fd5a1caaf55d74d8e6cb0d73f6..aadd99a49444fba4bc0f7d0f660aa898571ebf47 100644 --- a/docs/FAQ/zh/mp/hd-design.md +++ b/docs/FAQ/zh/mp/hd-design.md @@ -29,3 +29,6 @@ - 如已开机，开发评估板可以正常识别，只有自行制作的PCB无法识别，需要检查自己的USB电路设计是否符合硬件设计的要求，如阻抗匹配要求、走线要求，TVS管是否结电容过大等。排查此问题比较直接的方法是直接连接USB的四根通信线到模块USB引脚，去掉电路板上原先设计的电路。 - 如经过以上排查仍无法识别，需要考虑是否模块损坏，换一块PCB板进行对比测试。 +### 硬件如何设计可以让模组上电自动开机？ + +绝大部分模组直接将POWERKEY引脚通过下拉电阻接地即可，但是部分型号不允许一直接地，如BG95系列模组，具体可参考硬件设计手册。除了BG95系列，还有部分应用场景不能一直接地，如需要使用定时开关机降低功耗时，如一直接地，进行软件关机后又会自动开机，此时将需要使用BG95系列类似电路，开机完成后将POWERKEY引脚拉高，将不再影响软件关机功能。 \ No newline at end of file