explorer

万丈高楼平地起,勿在浮沙筑高台

0%

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 框架,便可以以函数调用的方式来实现多个进程(芯片)之间的通信,通信细节对于程序员来讲就是透明的。程序员便可以专注于上层业务逻辑,提高开发效率。

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

阅读全文 »