双芯片场景_v0.1.2

双芯片场景版本更新内容总结（v0.1.2）

本次更新主要将lock API拆分为lock和chip两个API，以支持同一APP网关内多个APP同时运行，每个APP扫描并处理多个蓝牙设备，并解决设备独占和芯片分配的问题。通过集中控制的方式，统一管理设备独占和芯片分配，维护系统状态。

你能获得：

• 了解如何在多APP场景下实现蓝牙设备的并发控制。
• 掌握如何使用新的API进行设备锁定和芯片分配。
• 理解双芯片系统中的资源管理和任务调度策略。

核心内容：

1. 设备独占与芯片分配：

• 详细解释：在多APP并发场景下，需要确保每个设备只能被一个APP独占使用，并且合理地将芯片资源分配给不同的APP，避免冲突和资源浪费。
• 行动建议：在APP设计中，务必先请求设备锁，再申请芯片资源，并在完成后及时释放，确保资源的合理利用。

2. 状态维护：

• 详细解释：系统需要维护设备锁状态、整体设备连接状态以及扩展状态（如连接耗时、成功率、芯片流量等），以便进行芯片分配和冲突检查。
• 行动建议：定期检查和更新系统状态，确保状态信息的准确性，为芯片分配算法提供可靠的依据。

3. API设计：

• 详细解释：
  • POST /api/gap/:node/lock：请求设备锁，防止设备或任务并发。
  • GET /api/gap/nodes/lock：查看设备锁状态。
  • DELETE /api/gap/:node/lock：释放设备锁。
  • POST /api/gap/:node/chip：请求使用芯片，可指定芯片或自动分配，并标识用途。
• 行动建议：在APP中使用这些API时，需要处理成功和失败的响应，并根据错误信息进行相应的处理。

4. 芯片分配算法：

• 详细解释：
  • 缺省算法：优先选择连接设备数量较少的芯片。
  • 固定分配：根据设备MAC地址进行哈希分配。
  • 冲突检查：支持根据请求字段（如purpose）进行关联检查。
• 行动建议：根据实际场景选择合适的芯片分配算法，并考虑自定义算法以满足特殊需求。

5. BLEAPP修改建议：

• 详细解释：如果只考虑APP并发连接问题，不考虑任务类型冲突，可以在连接完成后检查当前实际连接的芯片和本APP使用的芯片是否一致，不一致则不进行后续处理。
• 行动建议：根据实际需求修改BLEAPP，确保APP能够正确地处理芯片分配和连接状态。

问答：

Q: 为什么需要将lock API拆分为lock和chip两个API？

A: 在多APP并发场景下，设备锁和芯片分配是两个独立的操作。拆分API可以更清晰地表达APP的意图，并提供更精细的控制，例如，APP可以先锁定设备，然后再根据任务类型申请特定的芯片资源。

Q: 如何处理芯片分配冲突？

A: 系统会进行冲突检查，如果发现请求的芯片正在被其他APP使用，或者任务类型冲突，会返回409错误。APP需要根据错误信息，尝试请求其他芯片资源，或者等待当前芯片空闲。

Q: 如果芯片连接数已满，APP应该如何处理？

A: 如果芯片连接数已满，系统会返回503错误。APP可以尝试请求其他芯片，或者等待当前芯片的连接数减少。同时，也需要考虑优化连接管理策略，减少不必要的连接。