78
增加通信抽象层，IoT 设备可复用底层通信相关的代码
- 该 PR 仅增加 SimpleComm 和 UART Comm，基于此框架后续将增加 esp-now 等通信方式；
- 以 esp-sparkbot 的 chassis 为例，解 IoT thing 和通信方式之间耦合；
- 同时方便后续 esp-sparkbot 的头部通过其他方式控制其他 IoT 设备；
- board 下的多个 IoT 设备可复用同一通信模块，同一 IoT 设备可使用不同的通信方式，可灵活调节
目前看只有 esp-sparkbot 在用， 可以先写在 esp-sparkbot 的目录下实现，等后面其他板子也使用了，我们再抽出共同的部份，可能会好一点。 可以写个构造函数，比如Chassis(Comm* comm) : comm_(comm) {}，然后这样使用：
thing_manager.AddThing(new Chassis(new Comm(...));
好，明白，先尽量保持各个板子的独立性。（我之前还想把 chassis.cc 文件移动到 iot 目录下来着..）
这里我主要是为给 esp-sparkbot 再增加一个 iot 设备，这个设备走 esp-now 和 uart 方式做的。
感谢您的建议，我按您的建议修改一下。😄
可以写个构造函数，比如Chassis(Comm* comm) : comm_(comm) {}，然后这样使用：
thing_manager.AddThing(new Chassis(new Comm(...));
这里想请教一下，最开始我也是想增加一个新的构造函数来传入 Comm，但是这种方式就没办法通过 DECLARE_THING 和 CreateThing的统一接口去实例化 Chassis 了，所以最后是想增加一个 AddComm 的接口来实现这个逻辑。
如果使用这个方式创建，就需要显式声明 class Chassis（拆分成 .h 和 .cc 文件），感觉这破坏了已有的 IoT 的框架。 这里是否有更好的方案呢？
thing_manager.AddThing(new Chassis(new Comm(...));
我之前想做的是新建一个宏，当然这样就需要相对增加一个带参数的 CreateThing 和 RegisterThing 函数，这样改动好像也不太优雅；
#define DECLARE_THING_COMM(TypeName) \
static iot::Thing* Create##TypeName(Comm* comm) { \
return new iot::TypeName(comm); \
} \
static bool Register##TypeNameHelper = []() { \
RegisterThing(#TypeName, Create##TypeName); \
return true; \
}();
置于“iot/things”之下的均为公共的“thing”，因此它们不会接收与开发板相关的特定参数。作为接口，它们能够调用开发板的公共接口，例如获取“Display”对象、“Codec”对象或者“Backlight”对象以进行操作。若涉及针对开发板进行特殊开发的接口，建议在开发板目录下创建头文件和“.cc”文件，然后将其包含进来，通过“new Chassis(特殊参数)”的方式来实现。这样操作更为灵活。
可能我一开始没有把我做出这些修改的出发点表述清楚，我更倾向于想实现大部分 xiaozhi 板子都能快速接入的一种 IoT 设备，应该对应您这说的“公共的 thing”，只是这个 thing 并不存在于每种具体的 board 上。
Chassis 是一个特例，它只能通过 uart 去“物理有线”地连接上，这只适合于有引出 uart 接口的 board 去使用，现在也就只对应于 esp-sparkbot 的头部（有一个磁吸接口去和 Chassis 底盘连接）。
如果后面新增了一种可以通过 esp-now 或者蓝牙通信的 IoT 设备（这也就是我想新增的），这种 IoT 设备就可以接入 xiaozhi 现在大部分板子（esp32为主控）。在这种基础下，如果有 board 想要去控制这个设备，只需要通过标准 CreateThing 接口去调用一下就可以了。
不知道我描述清楚了没有，或者说我设想的这个事情本身可能不太成立？ 别的 board 并不关心其他的 things。或者说您的意思一直是：
等后面其他板子也使用了，我们再抽出共同的部份，可能会好一点。
btw，非常感谢您以上的耐心回复，感觉您非常 nice 👍。
同意你的思路，不过目前我们先遵循奥卡姆剃刀原理，先让更多的人加入进来开发不同的用途，然后启发我们去抽取这些共性。
dingmos @.***> 于2025年3月8日周六 16:21写道：
可能我一开始没有把我做出这些修改的出发点表述清楚，我更倾向于想实现大部分 xiaozhi 板子都能快速接入的一种 IoT 设备，应该对应您这说的“公共的 thing”，只是这个 thing 并不存在于每种具体的 board 上。
Chassis 是一个特例，它只能通过 uart 去“物理有线”地连接上，这只适合于有引出 uart 接口的 board 去使用，现在也就只对应于 esp-sparkbot 的头部（有一个磁吸接口去和 Chassis 底盘连接）。
如果后面新增了一种可以通过 esp-now 或者蓝牙通信的 IoT 设备（这也就是我想新增的），这种 IoT 设备就可以接入 xiaozhi 现在大部分板子（esp32为主控）。在这种基础下，如果有 board 想要去控制这个设备，只需要通过标准 CreateThing 接口去调用一下就可以了。
不知道我描述清楚了没有，或者说我设想的这个事情本身可能不太成立？ 别的 board 并不关心其他的 things。
btw，非常感谢您以上的耐心回复，感觉您非常 nice 👍。
— Reply to this email directly, view it on GitHub https://github.com/78/xiaozhi-esp32/pull/301#issuecomment-2708135373, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCHXRMWEGSYKQGPIDV3DJ32TKSB7AVCNFSM6AAAAABYRBJ3DGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYGEZTKMZXGM . You are receiving this because you commented.Message ID: @.***> [image: SmallPond]SmallPond left a comment (78/xiaozhi-esp32#301) https://github.com/78/xiaozhi-esp32/pull/301#issuecomment-2708135373
可能我一开始没有把我做出这些修改的出发点表述清楚，我更倾向于想实现大部分 xiaozhi 板子都能快速接入的一种 IoT 设备，应该对应您这说的“公共的 thing”，只是这个 thing 并不存在于每种具体的 board 上。
Chassis 是一个特例，它只能通过 uart 去“物理有线”地连接上，这只适合于有引出 uart 接口的 board 去使用，现在也就只对应于 esp-sparkbot 的头部（有一个磁吸接口去和 Chassis 底盘连接）。
如果后面新增了一种可以通过 esp-now 或者蓝牙通信的 IoT 设备（这也就是我想新增的），这种 IoT 设备就可以接入 xiaozhi 现在大部分板子（esp32为主控）。在这种基础下，如果有 board 想要去控制这个设备，只需要通过标准 CreateThing 接口去调用一下就可以了。
不知道我描述清楚了没有，或者说我设想的这个事情本身可能不太成立？ 别的 board 并不关心其他的 things。
btw，非常感谢您以上的耐心回复，感觉您非常 nice 👍。
— Reply to this email directly, view it on GitHub https://github.com/78/xiaozhi-esp32/pull/301#issuecomment-2708135373, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABCHXRMWEGSYKQGPIDV3DJ32TKSB7AVCNFSM6AAAAABYRBJ3DGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYGEZTKMZXGM . You are receiving this because you commented.Message ID: @.***>