移植20万行代码发现树莓派Pico竟是三无产品？是真香还是真不香？

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

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

树莓派Pico系统不完善

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

树莓派Pico移植20万行代码

移植到树莓派Pico系统的几大问题无OS,没有thread,也没有event,纯粹单线程阻塞

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

树莓派Pico移植OSAL

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

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

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

现有API不健全及完善

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

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

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

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

PICO API timer

PICO 重复定时器

在系统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'