关于 IPCC 管理的细节不多，因为用户无法自定义任何内容，我们希望避免对此提供过多支持。
应使用的下层接口是 AN5289 中描述的 TL_***()。
还有描述两个 CPU 之间通信流的 MSC。
无论如何，这里有一些答案：
- CPU2 如何知道将 IPCC CPU1 请求的答案放在哪里？
> BLE 和系统通道正在使用命令缓冲区发布响应。
- 关于 p_mem_manager_table->pevt_free_buffer_queue = (uint8_t*)&FreeBufQueue：这个缓冲区有什么用？
- 此缓冲区在每个用户事件 RX 占用事件时被填充。谁清空它？
> 这不是缓冲区，而是缓冲区地址链接的队列。从 CPU2 接收到的异步事件需要相关缓冲区被释放/释放回 CPU2。所有空闲缓冲区都被推入该队列。
- CPU2 正在访问这个缓冲区吗？
> 是的，CPU2 正在检索那些空闲缓冲区，将它们放回事件队列中供以后使用。
- 它与 SystemEvtQueue 缓冲区有关吗？
> SystemEvtQueue 是另一种方式。系统事件由 CPU2 在 SystemEvtQueue 中发布。一旦 CPU1 读取了系统事件，它将释放它到 FreeBufQueue
BLE 也有同样的事情：有一个接收队列来接收异步 BLE 事件，一旦完成，它们就可以免费进入 FreeBufQueue
- 这些有什么用？
tl_mm_config.p_BleSpareEvtBuffer = BleSpareEvtBuffer;
tl_mm_config.p_SystemSpareEvtBuffer = SystemSpareEvtBuffer;
> 这两个缓冲区当前未使用。它们应该保持可用，因为某些下一个 CM0+ 版本可能会使用它们。发生这种情况时，它将对用户透明并向后兼容。
- 这些有什么用？
tl_mm_config.p_AsynchEvtPool = EvtPool;
tl_mm_config.AsynchEvtPoolSize = POOL_SIZE;
BLE 和系统通道异步事件从该池中获取并发送到 CPU1。当 CPU1 将接收到的异步事件推回 FreeBufQueue 时，CPU2 从 FreeBufQueue 中读取它们推回 EvtPool。
- 如何在 IPCC 中执行读/写访问？读/写/队列地址在哪里？
> IPCC 不持有任何缓冲区/队列。它只是一个支持邮箱实现的硬件IP。它的唯一目的是生成从一个 CPU 到另一个 CPU 的事件，并在事件处理后得到确认。
如前所述，所有通信都是通过队列和缓冲区完成的。当一个缓冲区被填满并链接到一个队列时，IPCC 被触发以向另一个 CPU 发出消息已发布到队列中的信号。CPU2要使用的缓冲区地址都在共享表中给出。CPU1 应使用所有信息填充共享表，在 CPU2 启动时，CPU2 将读取该信息。
- 内存管理通道如何连接到其他 IPCC 通道（发送自由命令）？
> 内存通道仅用于释放后台缓冲区。
大致 ：
* 用于异步事件（BLE 或系统）的缓冲区取自 EvtPool 并由 CPU2 填充
* 然后将填充的缓冲区排队到 SystemEvtQueue (System) 或 HciAsynchEventQueue (BLE)
* IPCC 被触发（系统或 BLE 通道）以通知 CPU1 关于接收队列中发布的缓冲区
* CPU1从队列中取出缓冲区并读取
* 完成后，CPU1 将缓冲区发送回 FreeBufQueue
* CPU1触发IPCC（内存通道）通知CPU2一个buffer已经释放到FreeBufQueue中
* CPU2 从 FreeBufQueue 中检索缓冲区并将其放回 EvtPool。
这个描述是一个概述，在细节上我们有更多的链接队列，但上面的概念是正确的。
关于 IPCC 管理的细节不多，因为用户无法自定义任何内容，我们希望避免对此提供过多支持。
应使用的下层接口是 AN5289 中描述的 TL_***()。
还有描述两个 CPU 之间通信流的 MSC。
无论如何，这里有一些答案：
- CPU2 如何知道将 IPCC CPU1 请求的答案放在哪里？
> BLE 和系统通道正在使用命令缓冲区发布响应。
- 关于 p_mem_manager_table->pevt_free_buffer_queue = (uint8_t*)&FreeBufQueue：这个缓冲区有什么用？
- 此缓冲区在每个用户事件 RX 占用事件时被填充。谁清空它？
> 这不是缓冲区，而是缓冲区地址链接的队列。从 CPU2 接收到的异步事件需要相关缓冲区被释放/释放回 CPU2。所有空闲缓冲区都被推入该队列。
- CPU2 正在访问这个缓冲区吗？
> 是的，CPU2 正在检索那些空闲缓冲区，将它们放回事件队列中供以后使用。
- 它与 SystemEvtQueue 缓冲区有关吗？
> SystemEvtQueue 是另一种方式。系统事件由 CPU2 在 SystemEvtQueue 中发布。一旦 CPU1 读取了系统事件，它将释放它到 FreeBufQueue
BLE 也有同样的事情：有一个接收队列来接收异步 BLE 事件，一旦完成，它们就可以免费进入 FreeBufQueue
- 这些有什么用？
tl_mm_config.p_BleSpareEvtBuffer = BleSpareEvtBuffer;
tl_mm_config.p_SystemSpareEvtBuffer = SystemSpareEvtBuffer;
> 这两个缓冲区当前未使用。它们应该保持可用，因为某些下一个 CM0+ 版本可能会使用它们。发生这种情况时，它将对用户透明并向后兼容。
- 这些有什么用？
tl_mm_config.p_AsynchEvtPool = EvtPool;
tl_mm_config.AsynchEvtPoolSize = POOL_SIZE;
BLE 和系统通道异步事件从该池中获取并发送到 CPU1。当 CPU1 将接收到的异步事件推回 FreeBufQueue 时，CPU2 从 FreeBufQueue 中读取它们推回 EvtPool。
- 如何在 IPCC 中执行读/写访问？读/写/队列地址在哪里？
> IPCC 不持有任何缓冲区/队列。它只是一个支持邮箱实现的硬件IP。它的唯一目的是生成从一个 CPU 到另一个 CPU 的事件，并在事件处理后得到确认。
如前所述，所有通信都是通过队列和缓冲区完成的。当一个缓冲区被填满并链接到一个队列时，IPCC 被触发以向另一个 CPU 发出消息已发布到队列中的信号。CPU2要使用的缓冲区地址都在共享表中给出。CPU1 应使用所有信息填充共享表，在 CPU2 启动时，CPU2 将读取该信息。
- 内存管理通道如何连接到其他 IPCC 通道（发送自由命令）？
> 内存通道仅用于释放后台缓冲区。
大致 ：
* 用于异步事件（BLE 或系统）的缓冲区取自 EvtPool 并由 CPU2 填充
* 然后将填充的缓冲区排队到 SystemEvtQueue (System) 或 HciAsynchEventQueue (BLE)
* IPCC 被触发（系统或 BLE 通道）以通知 CPU1 关于接收队列中发布的缓冲区
* CPU1从队列中取出缓冲区并读取
* 完成后，CPU1 将缓冲区发送回 FreeBufQueue
* CPU1触发IPCC（内存通道）通知CPU2一个buffer已经释放到FreeBufQueue中
* CPU2 从 FreeBufQueue 中检索缓冲区并将其放回 EvtPool。
这个描述是一个概述，在细节上我们有更多的链接队列，但上面的概念是正确的。
举报
