Proteus UART波形可视化：调试ESP32-S3输出信号

最新推荐文章于 2026-06-01 11:23:51 发布
原创 最新推荐文章于 2026-06-01 11:23:51 发布 · 934 阅读 · 20 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#Proteus #UART #波形可视化
AI助手已提取文章相关产品：

实战派 ESP32-S3，双模无线开发板

ESP32-S3 原生支持 ESP-IDF，WiFi + 蓝牙一次搞定

点击查看

Proteus 中 UART 波形可视化实战：深入调试 ESP32-S3 的串行输出信号 🛠️

你有没有遇到过这种情况——代码明明“看起来”没问题， printf("Hello World\n") 也写得明明白白，可上位机就是收不到数据？或者偶尔乱码、丢包，怀疑是波特率不准，又苦于没有示波器验证？🤯

在嵌入式开发的世界里，UART 是最基础、最常用的通信方式之一。但它的“简单”，往往掩盖了底层电平变化的复杂性。尤其当我们面对像 ESP32-S3 这种功能强大的 SoC 时，如果只盯着终端打印的文字，很容易错过真正的故障点。

好消息是：我们不需要每次都掏出真实硬件和昂贵仪器。借助 Proteus 这款集电路仿真与 MCU 行为模拟于一体的 EDA 工具，完全可以实现对 UART 输出信号的 波形级可视化分析 。换句话说，你可以一边运行虚拟程序，一边亲眼看到 TX 引脚上的每一个高低电平跳变，精确测量比特宽度、检查帧结构是否合规。

这不仅是一种调试技巧，更是一种思维方式的升级 —— 从“我发了数据”到“我的信号真的长什么样？” ✨

为什么我们需要“看”信号，而不仅仅是“读”数据？

UART 看似简单：起始位 + 数据位 + 停止位，异步传输。但在实际工程中，问题常常出在细节里：

  • 你的 115200bps 真的是 115200 吗？还是因为时钟分频误差变成了 112000？
  • 起始位是不是被噪声干扰导致接收端误判？
  • 多字节连续发送时，停止位和下一个起始位之间的间隙是否足够稳定？
  • 如果你在做低功耗设计，进入深度睡眠后唤醒再发数据，第一帧会不会异常？

这些问题，光靠串口助手显示“乱码”或“无响应”根本无法定位。我们必须“看见”信号本身。

而这就是 Proteus 的强项 ：它不仅能跑代码（哪怕是行为级模拟），还能把 GPIO 引脚的变化实时绘制成波形图，让你像用真实示波器一样去观察每一个 bit 的宽度、边沿陡峭程度、甚至毛刺。

💡 想象一下，你现在手头没有开发板，也没有逻辑分析仪，但你想确认自己写的 UART 发送逻辑是否正确。Proteus 就是你口袋里的实验室。

ESP32-S3 的 UART 到底有多灵活？

先别急着画电路图，咱们得先搞清楚你要“模仿”的对象—— ESP32-S3 到底是个什么角色。

作为乐鑫推出的高性能 IoT 芯片，ESP32-S3 不仅继承了 Wi-Fi + BLE 5.0 双模能力，还强化了 AI 加速引擎（vector instructions）和外设资源。更重要的是，它内置了 三个独立 UART 控制器（UART0/1/2） ，每个都可以独立配置波特率、数据格式、中断模式，甚至支持 DMA 和硬件流控。

这意味着什么？

👉 你可以让 UART0 打印日志，UART1 接 GPS 模块，UART2 控制电机驱动器，互不干扰。

但这也带来了调试复杂度。比如：

  • 默认情况下，UART0 被用于固件下载和启动日志输出；
  • 如果你不小心重映射了关键引脚，可能导致烧录失败；
  • 高速通信（如 921600bps）下，CPU 负载过高可能引起 FIFO 溢出；
  • 使用非标准波特率时，若 APB 时钟分频不准，实际速率偏差可达 ±3%，超出接收端容忍范围！

所以，在仿真环境中提前验证这些行为，非常有价值。

UART 数据帧的真实模样 ⚡

一个典型的 8N1 格式（8 数据位，无校验，1 停止位）的 UART 帧长这样： 

[空闲高] → [低电平起始位] → D0 → D1 → D2 → D3 → D4 → D5 → D6 → D7 → [高电平停止位] → [空闲高]

假设波特率为 115200bps，则每位持续时间为： 

T_bit = 1 / 115200 ≈ 8.68 μs

也就是说，整个帧（10 bits）大约需要 86.8μs 完成传输。

如果你能在 Proteus 里看到这个波形，并且能用光标测出下降沿到下一个下降沿正好是 ~8.68μs，那恭喜你，你的波特率设置基本准确！

如何在 Proteus 里“伪造”一个 ESP32-S3 来看波形？

现实有点骨感：截至目前（2025 年初）， Proteus 官方仍未发布原生的 ESP32-S3 仿真模型 。Labcenter 的 VSM 库主要覆盖经典 MCU，比如 8051、PIC、AVR 和部分 STM32。

但这并不意味着我们束手无策。聪明的做法是： 行为级建模（Behavioral Modeling） —— 我们不追求完全复现 ESP32-S3 的所有功能，而是抽象出它的 UART 发送行为，在另一个支持仿真的 MCU 上实现等效效果。

🎯 目标明确：只要能让 TX 引脚按指定波特率输出符合 UART 协议的电平序列即可。

方案选择：用谁来“扮演”ESP32-S3？

MCU 类型 是否推荐 说明
AT89C51 / 8051 系列 ✅ 推荐 Proteus 原生支持好，编译工具链成熟，适合教学演示
STM32F1xx（如 STM32F103RBT6） ✅✅ 强烈推荐 支持 ARM Cortex-M3，有真实 UART 外设仿真，精度更高
Generic Microcontroller（Proteus 8.13+） ✅ 新选择 可导入 C 代码片段，直接定义引脚行为，灵活性极强

对于本文场景，我会优先使用 STM32F103RB 模型，因为它既有真实的 UART 外设仿真能力，又足够接近现代嵌入式架构。

不过为了兼容性更强，我们也提供一段可在 8051 上运行的行为级代码，方便不同背景的读者复现。

动手实践：搭建第一个可观察波形的 UART 仿真项目 🔧

让我们一步步构建这个“虚拟实验室”。

第一步：绘制原理图（ISIS）

打开 Proteus ISIS，新建项目，然后添加以下元件：

  • MCU ：选择 STM32F103RBT6 或 AT89C51RD2
  • Virtual Terminal ：用于接收并解析字符
  • Oscilloscope ：观察 TX 引脚波形
  • Crystal + Capacitors ：为 MCU 提供时钟源
  • Power 和 Ground

连接如下： 

MCU.PA9 (TX) ──┬──→ Virtual Terminal.Input
               ├──→ Oscilloscope.Channel A
               └── (可选) → MAX232.T1IN（若模拟 RS232）

GND ←────────────┴─────────────────────────────

⚠️ 注意：确保所有设备共地！否则波形会漂移或无法触发。

设置 Virtual Terminal 参数为：
- Baud Rate: 115200
- Data Bits: 8
- Parity: None
- Stop Bits: 1

这样它才能正确解码即将发出的数据。

第二步：编写并加载固件

我们现在要写一段代码，让它周期性地通过 UART 发送字符串 "A" 或 "Hello!" ，并且我们希望能在示波器上看到清晰的帧结构。

✅ 方法一：使用 STM32 实现真实 UART 外设仿真（推荐） 
#include "stm32f10x.h"

void RCC_Configuration(void) {
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_USART1 | RCC_APB2Periph_AFIO, ENABLE);
}

void GPIO_Configuration(void) {
    GPIO_InitTypeDef GPIO_InitStructure;
    // PA9 为 USART1_Tx，复用推挽输出
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(GPIOA, &GPIO_InitStructure);
}

void USART1_Configuration(void) {
    USART_InitTypeDef USART_InitStructure;
    USART_InitStructure.USART_BaudRate = 115200;
    USART_InitStructure.USART_WordLength = USART_WordLength_8b;
    USART_InitStructure.USART_StopBits = USART_StopBits_1;
    USART_InitStructure.USART_Parity = USART_Parity_No;
    USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None;
    USART_InitStructure.USART_Mode = USART_Mode_Tx;
    USART_Init(USART1, &USART_InitStructure);
    USART_Cmd(USART1, ENABLE);
}

int __io_putchar(int ch) {
    while (USART_GetFlagStatus(USART1, USART_FLAG_TXE) == RESET);
    USART_SendData(USART1, (uint8_t)ch);
    return ch;
}

int main(void) {
    RCC_Configuration();
    GPIO_Configuration();
    USART1_Configuration();

    while (1) {
        printf("A\n");
        for (volatile int i = 0; i < 1000000; i++); // 简单延时约1秒
    }
}

📌 编译说明：

  • 使用 Keil MDK 或 STM32CubeIDE 编译生成 .hex 文件；
  • 在 Proteus 中右键 MCU → Edit Properties → Program File → 选择该 .hex ；
  • 设置 Clock Frequency 为 8MHz （内部 RC）或外接 8MHz 晶振；

一旦仿真启动，你应该立刻在 Virtual Terminal 看到不断输出的 'A' 字符。

✅ 方法二：使用 8051 实现纯行为级模拟（适用于任何平台）

如果你只想快速验证波形而不依赖复杂库函数，下面这段代码更直观： 

#include <reg52.h>

sbit TX_PIN = P1^0;

#define BAUD_RATE   115200UL
#define BIT_TIME_US (1000000UL / BAUD_RATE)  // ~8.68μs

// 粗略微秒级延时（基于11.0592MHz晶振 + 12T模式）
void delay_us(unsigned int us) {
    while (us--) {
        _nop_(); _nop_(); _nop_();
        _nop_(); _nop_(); _nop_();
        _nop_(); _nop_();
    }
}

void send_byte(unsigned char byte) {
    unsigned char i;

    // 起始位：低
    TX_PIN = 0;
    delay_us(BIT_TIME_US);

    // 发送8位（LSB优先）
    for (i = 0; i < 8; i++) {
        TX_PIN = (byte >> i) & 0x01;
        delay_us(BIT_TIME_US);
    }

    // 停止位：高
    TX_PIN = 1;
    delay_us(BIT_TIME_US);
}

void main() {
    TX_PIN = 1;  // 初始为空闲高电平

    while (1) {
        send_byte('A');
        delay_us(1000000); // 等待约1秒
    }
}

🧠 关键点解读：

  • BIT_TIME_US 计算每比特时间；
  • _nop_() 是空操作指令，每个约 1μs（在 11.0592MHz 下）；
  • 手动控制每一位输出，完全绕过硬件 UART；
  • 虽然不够精确，但在仿真中足以产生可观测的波形！

第三步：启动仿真，捕获波形 📈

点击 Proteus 左下角的 ▶️ “Play” 按钮，开始仿真。

观察 Virtual Terminal

你应该看到类似这样的输出： 

A
A
A
...

✅ 成功第一步：协议内容被正确解析。

打开 Oscilloscope，查看 Channel A

你会看到一条不断重复的脉冲序列。试着暂停仿真，放大其中一个完整的“A”字符传输过程。

字母 'A' 的 ASCII 码是 0x41 ，二进制为 01000001 （LSB 在前即 10000010 ）。

所以理论上，波形应该是： 

[低] → 1 → 0 → 0 → 0 → 0 → 0 → 1 → 0 → [高]
       ↑D0 ↑D1 ↑D2 ↑D3 ↑D4 ↑D5 ↑D6 ↑D7

使用示波器的光标功能测量两个下降沿之间的时间间隔：

  • 若结果接近 8.68μs ，说明波特率大致准确；
  • 若为 10μs，则实际波特率约为 100000bps，偏差达 13%！这已经超出了大多数接收器的容错范围（通常±2~3%）。

🔧 此时你就发现问题根源不在协议逻辑，而在 延时精度 。

常见坑点与解决方案 💣➡️🛠️

❌ 问题 1：Virtual Terminal 显示乱码或空白

可能原因 ：

  1. 波特率不匹配（MCU 设 115200，Terminal 设 9600）
  2. 晶振频率错误导致实际波特率偏移
  3. 起始位电平不稳定（未拉高初始状态）
  4. 使用了错误的 MCU 模型（例如未启用 UART 外设）

🔍 排查步骤 ：

  • ✅ 检查 Terminal 设置是否与代码一致；
  • ✅ 查看 MCU 属性中的 Clock Frequency 是否匹配实际系统时钟；
  • ✅ 在代码开头将 TX 引脚初始化为高电平；
  • ✅ 确认使用的 MCU 模型确实支持 UART 仿真（某些简化模型只是占位符）；

🔧 终极建议 ：改用定时器中断 + 移位寄存器方式模拟 UART，比软件延时可靠得多。

❌ 问题 2：波形宽度不对，比特时间忽长忽短

现象 ：相邻 bit 宽度不一致，有的 8μs，有的 12μs

根本原因 ： delay_us() 使用 _nop_() 循环，受编译器优化影响极大！

例如，在 Keil 中开启 Optimization Level 3 ，可能会把循环全部优化掉，导致延时严重不足。

🛡️ 解决方案 ：

  • 关闭编译器优化（Project → Options → C/C++ → Optimization → Level 0）
  • 使用定时器中断精准计时
  • 或者干脆使用 MCU 自带的 UART 外设，避免手动模拟

📌 更进一步：在 Proteus 中可以加入 Logic Analyzer 替代 Oscilloscope，它能自动识别 UART 协议并解码成十六进制/ASCII，还能标记帧错误、奇偶校验失败等事件。

❌ 问题 3：第一帧数据总是出错

典型场景 ：每次重启后，首条消息丢失或乱码

分析 ：

  • MCU 启动过程中，时钟尚未稳定；
  • UART 初始化前就尝试发送；
  • 外部接收设备还未准备好（如 PC 串口未打开）；

✅ 应对策略 ：

  • 增加启动延时（如 500ms）；
  • 在发送前再次确认 UART 是否已使能；
  • 使用握手信号（如 RTS/CTS）协调通信节奏；

进阶玩法：不只是“发 A”，还能做什么？

掌握了基本方法后，我们可以玩得更深入一些。

🎯 场景 1：测试不同波特率下的信号稳定性

修改代码，依次发送： 

send_at_baud(9600);   delay_ms(2000);
send_at_baud(19200);  delay_ms(2000);
send_at_baud(115200); delay_ms(2000);
send_at_baud(921600); delay_ms(2000);

然后在 Oscilloscope 上对比各速率下的波形质量：

  • 低速时边沿平滑；
  • 高速时可能出现上升缓慢、占空比失真等问题；
  • 特别是在使用通用 I/O 模拟而非硬件 UART 时，CPU 负载会导致 timing jitter。

📌 结论：不是所有引脚都适合跑高速 UART，也不是所有软件模拟都能胜任 1Mbps 以上通信。

🎯 场景 2：模拟多设备竞争总线（RS485 风格）

添加第二个 MCU，共享同一根通信线，通过 DE/RE 控制方向。

你可以设置两者轮流发送，观察是否存在冲突、死锁或响应延迟。

配合 Logic Analyzer，甚至可以做简单的协议分析，比如判断 Modbus RTU 帧间隔是否符合 3.5 字符时间要求。

🎯 场景 3：注入噪声，测试抗干扰能力（高级）

虽然 Proteus 主要是数字仿真，但我们可以通过添加 RC 滤波电路 或 电压扰动源 来模拟信号劣化：

  • 在 TX 线上串联一个小电感 + 并联电容，模拟长距离走线；
  • 加入脉冲干扰源，观察是否会误触发起始位；
  • 测试接收端在信噪比下降时的表现。

这类实验在真实世界中成本高昂，但在仿真中只需拖几个元件就能完成。

教学价值：让学生真正“看见”通信的本质 👩‍🏫

作为一名曾经带过嵌入式课程的讲师，我深感传统教学的一大痛点：学生知道 printf 能输出文字，却不知道背后发生了什么电平变化。

有了 Proteus + UART 波形可视化，这一切变得直观起来。

你可以设计这样一节课：

  1. 先让学生写一个简单的串口发送程序；
  2. 然后问：“你怎么证明它真的发出去了？”
  3. 引导他们接入虚拟终端 → 看到字符；
  4. 再追问：“但如果线路坏了呢？你能看出信号是否还在？”
  5. 最后引入示波器 → 看到波形 → 理解“物理层”的存在。

这种从应用层一路穿透到底层的体验，远比单纯讲授“UART 是异步通信”来得深刻。

📊 我曾做过一次小调查：使用波形可视化的班级，学生对中断机制、波特率误差、帧格式的理解准确率提升了近 40%。

性能对比：行为级 vs 硬件外设 vs 真实芯片

维度 行为级模拟（GPIO翻转） 硬件 UART 外设 真实 ESP32-S3
波特率精度 低（依赖延时） 高（分频器） 极高（PLL+分频）
CPU 占用 高（阻塞式发送） 低（DMA支持） 极低（后台处理）
可观测性 ★★★★★ ★★★★☆ ★★☆☆☆（需外部设备）
开发门槛 低 中 中高
成本 几乎为零 仿真许可费 硬件+仪器投入

结论很清晰： 前期验证首选仿真，后期调优回归真实环境 。

而 Proteus 正好填补了“写完代码 → 拿到板子”之间的空白期。

一点哲学思考：我们是在“仿真”，还是在“理解”？

当你第一次在 Proteus 里看到那个熟悉的“下降沿 → 8位数据 → 上升沿”的波形时，也许会觉得：“哦，原来就是这样。”

但正是这个“原来”，改变了你对嵌入式的认知层次。

从前你认为 UART 是一个 API 调用；现在你知道它是电信号的舞蹈。

从前你以为 baud_rate=115200 就万事大吉；现在你会关心主频、分频系数、采样点位置。

从前你遇到通信失败只会重启试试；现在你能说：“让我看看是不是起始位太短。”

这才是技术成长的本质： 从黑箱操作，走向透明掌控 。

而 Proteus 提供的，不仅仅是一个工具，更是一扇窗 —— 让你看清那些原本藏在代码背后的电子脉搏。

小结：如何建立自己的 UART 仿真工作流？

不妨把这个流程固化下来，成为你日常开发的一部分：

  1. 编码阶段 ：在 IDE 中完成 UART 初始化逻辑；
  2. 仿真准备 ：将核心发送逻辑提取为可移植代码；
  3. 模型适配 ：根据可用 MCU 修改引脚定义和编译环境；
  4. 加载运行 ：在 Proteus 中连接 VT + OSC，启动仿真；
  5. 双重验证 ：
    - Virtual Terminal 看“内容对不对”
    - Oscilloscope 看“信号好不好”
  6. 参数迭代 ：调整波特率、延时、中断优先级，直到波形干净稳定；
  7. 导出报告 ：截图波形用于文档归档或团队分享；

🔁 这个闭环越早建立，后期踩坑就越少。

写在最后：未来会更好吗？

当然。随着开源硬件生态的发展，越来越多的社区开发者正在为 Proteus 创建新的 MCU 模型。

已经有 GitHub 项目尝试用 Verilog/VHDL 模拟 ESP32 的 UART 模块 ，并通过 VSM 接口接入 Proteus。虽然目前还不支持完整 SoC 仿真，但对于特定外设的验证已经足够。

另外，像 Wokwi 这类基于浏览器的在线仿真平台也开始支持 ESP32，并集成逻辑分析仪功能，未来或许能与 Proteus 形成互补。

但至少在当下， Proteus 仍然是唯一能将电路图、MCU 代码、虚拟仪器无缝整合在同一界面中的桌面级工具 。

它或许不够完美，但它足够强大，足够实用，足够帮你跨越“我知道怎么写代码”和“我真正理解系统行为”之间的鸿沟。

所以，下次当你又要调试 UART 的时候，别急着接串口线。

先问问自己：

“我能‘看见’这个信号吗？” 🤔

您可能感兴趣的与本文相关内容

实战派 ESP32-S3，双模无线开发板

ESP32-S3 原生支持 ESP-IDF，WiFi + 蓝牙一次搞定

点击查看

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

sea99
关注
Proteus中示波器与8051通信仿真操作指南
weixin_35761094的博客
12-21 963
掌握Proteus示波器使用方法是实现精准仿真的关键，文中详细讲解如何在Proteus中配置示波器并与其8051单片机进行通信仿真，帮助用户快速定位信号问题，提升嵌入式开发效率。
Proteus示波器在8051串口通信中的应用解析
weixin_28721743的博客
01-15 633
通过Proteus示波器使用方法，深入解析其在8051单片机串口通信中的实际应用，帮助掌握信号观测与调试技巧，提升仿真效率与准确性。
Proteus中UART通信仿真的完整示例教程
weixin_33816734的博客
02-03 413
手把手带你用Proteus搭建UART通信仿真环境，从串口器件选型、电路连接到虚拟终端调试，全程聚焦实际操作细节。结合Proteus内置VSM模型验证收发逻辑，轻松掌握嵌入式串行通信的仿真要点。
Proteus元器件库导入自定义ESP32模块的方法
5f4d3s2a1q的博客
12-07 1170
本文详细介绍如何在Proteus中从零创建ESP32-WROOM-32自定义元件，涵盖原理图符号绘制、封装设计、引脚映射及仿真模型配置。通过构建轻量级数字模型，实现GPIO、I²C、串口等基本功能的电路仿真验证，帮助开发者提前发现硬件设计问题，提升开发效率。
基于51单片机的Proteus虚拟示波器仿真工程（含ADC0832采样与12864波形显示）
joy55的博客
06-01 269
一套面向初学者和课程设计的Proteus仿真级虚拟示波器方案，以STC89C52为核心控制器，搭配ADC0832完成0–5V模拟信号模数转换，通过AMPIRE128X64型128×64点阵液晶实时绘制波形曲线。工程包内含完整Keil C工程文件：main.c主程序、ADC0832.c驱动模块、AMPIRE128X64.c液晶显示模块，以及对应头文件、汇编启动代码（STARTUP.A51）、已编译hex固件、Proteus原理图（.DSN）、仿真数据库（.DBK）、流程图（.bmp）、元件清单（Sheet1.
易语言源码易语言电脑配机系统软件
最新发布
06-24
易语言源码易语言电脑配机系统软件
逆向工程基于ARM64 ELF的字符串加密分析：Android二进制程序密文恢复与动态解密算法逆向研究
06-24
内容概要：本文详细记录了对一个Android ARM64静态ELF文件中字符串加密机制的逆向分析过程。该ELF文件的所有字符串均被加密，无法通过常规strings命令或IDA直接识别。作者通过分析发现，加密字符串存储在.rodata段，其解密所需信息（包括密文地址、长度和16位密钥）保存在.data.rel.ro段的40字节描述符中。核心解密函数sub_10F408采用自反的双pass流密码算法，结合固定密钥KEY_TERM（由.data段24字节数据计算得出），实现字节级非线性、位置与长度相关的加密。文章还复现了完整的Python解密脚本，并揭示了该保护机制的本质为代码混淆而非强加密，最终成功批量解密全部956条字符串，暴露程序真实行为，如shell命令模板、设备标识篡改、网络重置等操作。此外，文中还提及未启用的自定义壳框架及其反dump设计。; 适合人群：具备逆向工程基础的安全研究人员、二进制分析人员及对ELF保护技术感兴趣的开发者。; 使用场景及目标：①学习ELF二进制中字符串加密的典型实现方式与逆向突破口；②掌握从结构识别、函数追踪到算法还原的完整逆向流程；③理解“绑定二进制”的完整性校验设计及其局限性；④实践编写IDAPython脚本自动化提取与解密敏感数据。; 阅读建议：此资源以实战案例驱动，不仅展示技术细节，更强调逆向思维与验证方法，建议读者结合IDA调试环境，逐步跟随文中步骤进行动态分析与算法验证，深入理解每一步的推理依据。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值