explorer

宏在 c++ 中要尽可能少的使用，在google c++ 编码规范中也是建议使用宏要谨慎。

谷歌 c++ 编码规范也比较推崇尽量使用const。

两个 stm32 通过 SPI 进行通信，一主一从，但从机不能使用 CubeMX 的默认配置，不然会被带进坑……

QtQuick 提供的 QtChart 可以满足在 Qml 中高效绘制动态曲线，但由于它是 GPL 协议，故应用场景有限。

QWidget 中就具有类 QTabWidget 以 Table 的方式来切换各个窗口，但是在 QtQuick 中并没有一个叫 TabWidget 的组件。

与之较为接近的便是 TabBar 这个组件，但其没有提供子窗口的动态增加和删除。

这里主要关注同类型窗口的动态创建

ERPC 将传统数据流的分析及处理的实现封装了起来，那么它的执行效率如何？

这里仅仅关注 ERPC 在收发方面的实现，而不深入整体架构。

依然是以之前的 demo代码来分析，按照客户端和服务端的收发来顺藤摸瓜。

在 ERPC 的 IDL 说明文档中，对于接口内存的申请和释放是这样描述的：

• On the client side: All memory space has to be allocated and provided by the user code. The shim code only reads from or writes into this memory space.
• On the server side: All memory space is allocated and provided by the shim code. The user code only reads from or writes into this memory space.

为了避免在实际使用中产生内存泄漏，还是需要实际查看代码来理解。

其实这里分两种情况： 1. 以指针作为返回参数 2. 以指针作为形参

NXP 官方提供了 M4 和 A53 通信的 demo，但是仅仅是演示作用： - M4 端仅使用 rpmsg 与 A53 进行通信，没有 ERPC 封装 - A53 端将 rpmsg 操作暴露成了一个 tty 设备，仅适合 echo 演示，不适合编写代码完成通信 - 需要在 rpmsg 的基础上进行 ERPC 封装

那么完成的步骤就是： 1. 完成用户态代码实现与 M4 进行 rpmsg 通信 2. 对 rpmsg 进行 ERPC 封装

在使用 EPRC 进行 TCP 通信的过程中，如果需要同时运行一个客户端和服务端就会出现异常。

这是因为其提供的 erpc_setup_tcp.cpp 只能初始化一个实例，那就需要对其进行理解并修改。

在没有使用 RPC 之前，那就需要程序员自己来完成两个进程（芯片）之间的通信。无论是对于发射端还是接收端，其逻辑都类似如下：

1. 发送端根据制定的传输格式传输二进制流
2. 接收端根据接收到的二进制流，以状态机的方式依次分解二进制流的内容
3. 最终将解析出来的命令和数据与对应的处理程序进行关联调用

人为实现这个过程比较繁琐：

1. 发射端和接收端可能会存在大小端的问题，这需要单独处理
2. 如果代码架构不好，那么换一个底层通信协议便会导致又需要重新实现一次这个过程
3. 长期维护起来比较麻烦，尤其是存在多个进程（芯片）之间通信时
4. 发射端和接收端存在同步和异步调用关系，人为实现较为麻烦

而有了 RPC 框架，便可以以函数调用的方式来实现多个进程（芯片）之间的通信，通信细节对于程序员来讲就是透明的。程序员便可以专注于上层业务逻辑，提高开发效率。

相比较于代码量庞大的 grpc，ERPC 更适合于嵌入式通信的应用场景，我们先来体验一下它。