wangfq
25401c5cf3
关键发现: - BLE TX 不阻塞CPU (CH59x 射频DMA自主发送), Modbus TX 阻塞4.3ms - 两者使用不同硬件 (2.4GHz RF vs UART0), 无资源冲突 - BLE RF ISR 优先级最高, 可抢占 rs485_send 忙等 → BLE连接不中断 - 双通道全开 CPU 44.5%, 余量55% - 同一迭代最坏: BLE准备(2ms) + Modbus TX(4.3ms) = 6.3ms - 两者事件触发同源(继电器翻转), 在同一迭代内顺序处理
182 lines
7.6 KiB
Markdown
182 lines
7.6 KiB
Markdown
# BLE 动态上报 + Modbus 主动上报 并发场景 — MCU 资源占用分析
|
||
|
||
> 场景：蓝牙小程序开启动态上报，同时 RS485 Modbus 主动上报使能
|
||
> 波特率：115200 (Modbus) | BLE 连接间隔：30–50ms（手机协商）
|
||
|
||
---
|
||
|
||
## 1. 关键架构差异：BLE 不阻塞 vs Modbus 阻塞
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────┐
|
||
│ BLE 动态上报 │
|
||
│ ┌─────────────────────────────────────────────┐ │
|
||
│ │ poll_dbn_ble() → report_sens_acs() │ │
|
||
│ │ → usart_packet_processing_acs_loop() │ │
|
||
│ │ → 准备 BLE 缓冲区 (1–2ms，纯内存操作) │ │
|
||
│ │ → 通知 BLE 栈 "有数据要发" │ │
|
||
│ │ → 返回（不阻塞） │ │
|
||
│ └─────────────────────────────────────────────┘ │
|
||
│ │
|
||
│ TMOS_SystemProcess() → BLE 栈调度 │
|
||
│ ┌─────────────────────────────────────────────┐ │
|
||
│ │ BLE RF ISR → DMA 搬数据 → 2.4GHz 无线发送 │ │
|
||
│ │ (硬件自主，CPU 不参与传输) │ │
|
||
│ └─────────────────────────────────────────────┘ │
|
||
│ │
|
||
├─────────────────────────────────────────────────────┤
|
||
│ Modbus 主动上报 │
|
||
│ ┌─────────────────────────────────────────────┐ │
|
||
│ │ modbus_poll() → send_full_data() │ │
|
||
│ │ → rs485_send(43B) │ │
|
||
│ │ → 逐字节 while(FIFO空) 忙等 │ │
|
||
│ │ → 4.3ms CPU 锁死 │ │
|
||
│ └─────────────────────────────────────────────┘ │
|
||
└─────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**BLE 传输不占用 CPU**——CH59x 的 BLE 硬件用 DMA 把数据从 RAM 搬到 RF FIFO，CPU 只需准备缓冲区。Modbus UART 没有 DMA，CPU 逐字节忙等。
|
||
|
||
---
|
||
|
||
## 2. 两者"同时开火"的最坏情况
|
||
|
||
BLE 事件上报和 Modbus 事件上报的触发点是同一个：**继电器翻转**。
|
||
|
||
```
|
||
cjq_srv() 检测到进车
|
||
→ loop1_VD_FLAG = 1
|
||
→ g_loop_acs_info.flag_event = 1 ← BLE 事件触发
|
||
→ relay1_state 翻转 ← Modbus 事件触发
|
||
```
|
||
|
||
同一个主循环迭代内：
|
||
|
||
```
|
||
Main_Circulation:
|
||
TMOS_SystemProcess() ~1.5ms
|
||
poll_dbn_ble()
|
||
→ report_sens_acs()
|
||
→ flag_event == 1
|
||
→ usart_packet_processing_acs_loop(1) ~2ms ← BLE: 准备缓冲区
|
||
cjq_srv() ~1ms
|
||
opt_input_poll() ~0.3ms
|
||
modbus_poll()
|
||
→ modbus_report_schedule()
|
||
→ relay 翻转!
|
||
→ send_full_data() 4.3ms ← Modbus: CPU 忙等 TX
|
||
─────────────────────────────────────────
|
||
本次迭代总耗时: ~9.1ms
|
||
```
|
||
|
||
9.1ms 接近但小于 CAP_OK 测量窗 (8.74ms)，在临界线上——最多积压 1 次 CAP_OK。
|
||
|
||
---
|
||
|
||
## 3. 持续负载量化
|
||
|
||
### 3.1 每秒 CPU 时间分解
|
||
|
||
| 任务 | 频率 | 单次 | 每秒 CPU |
|
||
|------|------|------|---------|
|
||
| 主循环基础 (TMOS+poll+cjq+opto) | ~114次/s (每个 CAP_OK) | 3.4ms | **388 ms/s** |
|
||
| BLE 事件上报 | ~4次/s (2进2出) | 2ms | **8 ms/s** |
|
||
| BLE 周期上报 | ~1.7次/s (600ms) | 2ms | **3 ms/s** |
|
||
| Modbus 活动 TX | ~6.7次/s (150ms) | 4.3ms | **29 ms/s** |
|
||
| Modbus 事件 TX | ~4次/s | 4.3ms | **17 ms/s** |
|
||
| **合计** | | | **445 ms/s (44.5%)** |
|
||
|
||
### 3.2 与纯 Modbus 对比
|
||
|
||
| 场景 | CPU 占比 | 增量 |
|
||
|------|---------|------|
|
||
| 仅线圈检测 (无任何上报) | ~39% | 基线 |
|
||
| + Modbus 主动上报 | ~42% | +3% |
|
||
| + BLE 动态上报 | **~45%** | +3% |
|
||
| 余量 | **55%** | 🟢 |
|
||
|
||
---
|
||
|
||
## 4. BLE 周期上报的间隔细节
|
||
|
||
```c
|
||
// TMR1 ISR (每 5ms):
|
||
if (g_dbn_ble_state_acs_enable.enable)
|
||
g_loop_acs_info.report_counter++;
|
||
|
||
// poll_dbn_ble (主循环):
|
||
if (g_loop_acs_info.report_counter >= 120) // 120 × 5ms = 600ms
|
||
usart_packet_processing_acs_loop(0); // 周期上报
|
||
```
|
||
|
||
BLE 周期 600ms，Modbus 活动 150ms/空闲 800ms，两者不同步——大部分时间不会在同一迭代中同时触发。
|
||
|
||
---
|
||
|
||
## 5. 极限压测：连续进出车 + 双通道全开
|
||
|
||
```
|
||
每秒 2 辆车进出 (4 次继电器翻转):
|
||
BLE 事件 TX × 4 = 8 ms
|
||
Modbus 事件 TX × 4 = 17 ms
|
||
Modbus 活动 TX × 7 = 29 ms
|
||
BLE 周期 TX × 2 = 3 ms
|
||
cjq_srv × 114 = 388 ms
|
||
─────────────────────────
|
||
合计 445 ms/s (44.5% CPU)
|
||
```
|
||
|
||
**结论：55% CPU 余量，远未触及瓶颈。**
|
||
|
||
---
|
||
|
||
## 6. 真正的瓶颈是什么？
|
||
|
||
不是 CPU，是 **Modbus TX 期间的 BLE 连接维护**。
|
||
|
||
BLE 连接需要定期交换链路层包（Connection Event）。连接间隔由手机端协商，通常 30–50ms。
|
||
|
||
```
|
||
Time: 0 10 20 30 40 50 ms
|
||
BLE: [CE] [CE] [CE] ← 每 30ms 一次
|
||
Modbus: [══ TX 4.3ms ══] ← 阻塞期
|
||
```
|
||
|
||
BLE Connection Event 在 ISR 上下文中处理——**射频 ISR 优先级高于主循环**。即使 Modbus TX 正忙等在 UART FIFO 上，BLE ISR 仍能抢占 CPU 完成连接维护。
|
||
|
||
CH59x 中断优先级：
|
||
```
|
||
RF (BLE) > TMR0 (线圈) > TMR1 (5ms) > UART0 > 主循环
|
||
↑ ↑
|
||
抢占一切 被所有人抢占
|
||
```
|
||
|
||
**BLE RF ISR 可以抢占 rs485_send 的忙等循环**。BLE 连接不会因 Modbus TX 断开。
|
||
|
||
---
|
||
|
||
## 7. 内存压力
|
||
|
||
| 缓冲区 | 大小 | 用途 |
|
||
|--------|------|------|
|
||
| BLE notify buffer | ~200B | `g_notify_buftemp` — BLE 上报数据暂存 |
|
||
| BLE response buffer | ~200B | `g_buf_ble_response` — 命令响应 |
|
||
| Modbus TX buffer (栈) | 43B | `send_full_data` 局部变量 |
|
||
| Modbus data buffer (栈) | 255B | `handle_read_*_regs` 响应组装 |
|
||
| RX buffer | 16B | `_rx_buf` (与 700BS 共享) |
|
||
|
||
BLE 和 Modbus 使用独立的缓冲区，不共享、不竞争。栈峰值约 350B（Modbus 调用链最深），BLE 用全局缓冲。
|
||
|
||
---
|
||
|
||
## 8. 总结
|
||
|
||
| 维度 | 评估 | 说明 |
|
||
|------|------|------|
|
||
| **CPU** | 🟢 充裕 | 双通道全开 44.5%，余量 55% |
|
||
| **BLE 连接** | 🟢 安全 | RF ISR 优先级最高，可抢占 Modbus TX |
|
||
| **线圈检测** | 🟢 安全 | 最坏迭代 9.1ms，积压 ≤1 次 CAP_OK |
|
||
| **硬件冲突** | 🟢 无 | BLE=2.4GHz RF+DMA，Modbus=UART0，不同外设 |
|
||
| **内存** | 🟢 充裕 | 独立缓冲，栈增量可忽略 |
|
||
| **TX 叠加** | 🟢 轻微 | BLE 不阻塞，Modbus 4.3ms，同一迭代 BLE+Modbus = 6.3ms |
|