移植了 20 万行代码才发现树莓派 Pico 双核 MCU 竟是三无产品?是真香还是真不香?

树莓派 Pico 双核 MCU 来了,要跟吗?参考下其他人移植代码后的经验

树莓派 Pico 双核 MCU 发布有一段时间了,在尝试将 20 万行代码移植到 Pico 系统后发现,这个系统有不少大坑,还未入手的小伙伴考虑好后再入.将过程中遇到的各种坑汇总,以飨读者.

移植到树莓派 Pico 系统的几大问题

无 OS,没有 thread,也没有 event,纯粹单线程阻塞

常见的的模块在嵌入式系统里面为适配不同的 OS 和系统往往设计一个 OSAL 适配层,这个层一方面向业务功能模块提供标准 API,另一方面针对不同的 OS 或者系统实现对应的 API.

Pico 系统目前是没有使用常见 OS 的,也就是它本身是一个独立的 OS,模块移植需要针对其单独写一个适配层,会显著增加模块的移植工作量.

同样的,因为其没有使用常见 OS,那么现有的其他模块,也无法直接简单使用,都需要针对性的移植,这大大增加了整体的工作量.

另外系统里面没有 thread,也没有 event,纯粹是一个单线程的概念,这个对于通信类应用会是个灾难.

现有 API 不健全及完善

模块中常常使用系统提供的基础功能来支持业务的实现,如各类外围接口操作、定时器、队列等等. Pico 现有的 API 函数实现都是骨头级别的,并没有针对常见使用的 API 做完整对标实现. 移植功能模块时需自行多一层包装和调试.

以 timer 这个常见功能为例,常见的使用逻辑如下:

• 创建 timer 实体,此时 timer 本身是没有开始工作的
• 在需要开启 timer 时,打开 timer
• 在需要关闭 timer 时,关闭 timer
• 功能完成后删除 timer

Pico 系统 API 里面提供的只有 repeating timer 这个,而这个是创建就是开始,而且并没有对应的成对的开启 /关闭 timer 的 API,在使用时,还需要自行验证封装.

在系统 API 里面,其他的部分也或多或少有类似的情况. 这一套本应该是 OS 或者类似 OS 的 API 接口,被 Pico 比较特立独行的封装,其稳定及健壮性有待考验.

模块化系统不完善

开源系统往往可以很方便地集成各类模块实现最终的功能,Pico 整个系统是完全的 CMake 风格,通过包含其核心 SDK 的 CMake 系统即可实现对应的编译 CMake.

但是,各类当前的已有的模块在它目前的代码结构里面是没有,需要自行移植. 另外,针对模块之间的依赖、相互限制、引用、宏依赖等等 都没有做特别处理,

这些都需要在移植时自行研究摸索.

如果一个功能模块需要依赖比较多的其他模块,那么这个过程会比较痛苦和耗费工作量

树莓派 Pico 当前系统的几大挑战

针对 Pico 系统目前的现状,将产品或者功能模块移植到此系统上时,会面临较大挑战,建议先进行评估再开展:

• 无 OS,移植工作量大

• 新增 OS 后,前序移植工作量浪费

• API 尚不健全,稳定健壮性有待考验,接口变化的可能性比较大

树莓派 Pico 的几个推测

树莓派 Pico 目前还刚刚开始,针对接下来可能的发展做几个小的预测:

• WiFi 版 Pico W, 可能性 > 99.99999%. 没有 WiFi 的 MCU 不是好 IoT 系统.
• Arduino > 80%概率能跑,官方估计会半支持
• 80%概率 RPI 要在 FreeRTOS+LWIP 等组合基础上出自己的'OS'