3、设备端SDK移植准备(MCU篇):了解AliOS Things与Link Kit SDK、MCU资源评估(Flash/RAM)、开发环境搭建(Keil/IAR/CMake)

好,咱们进入第三讲。这一章,说白了就是动手前的“磨刀”环节。很多同学拿到SDK就往板子上怼,结果编译报错一堆,跑起来又死机。我早期也干过这种事,后来发现,花半小时搞清楚手里的家伙什儿,能省下后面三天排查问题的时间。

这一节,我们聚焦三个核心问题:选哪个SDK?MCU够不够用?开发环境怎么搭? 咱们一个一个来拆。

3.1 两大SDK:AliOS Things 与 Link Kit SDK

很多新手会问:“我到底该用哪个?” 嗯,这个问题其实不难。我个人的习惯是:看你的MCU资源,也看你的开发周期。

AliOS Things,它是一个完整的物联网操作系统。里面带了内核、文件系统、网络协议栈,甚至还有JavaScript引擎。说白了,它是个“大而全”的框架。如果你的MCU是Cortex-M4以上,Flash有1MB,RAM有256KB以上,那用AliOS Things会很爽。它帮你把OTA的整个流程都封装好了,你只需要配几个参数。

但如果你用的是资源受限的MCU,比如STM32F103这种“小钢炮”,Flash只有64KB,RAM只有20KB,那AliOS Things就有点“水土不服”了。这时候,Link Kit SDK 才是你的菜。

Link Kit SDK 是个轻量级的C语言SDK。它不依赖操作系统,你可以跑在裸机上,也可以跑在FreeRTOS上。它只做一件事:帮你连上阿里云,实现OTA升级。我曾在一次项目中,用Link Kit SDK在仅有32KB Flash的MCU上跑通了OTA,当时心里还是挺爽的。

核心区别总结:

  • AliOS Things:全功能OS,适合资源丰富、追求开发效率的场景。
  • Link Kit SDK:轻量级组件,适合资源受限、需要高度定制的场景。

我个人建议,如果你是第一次做OTA,或者MCU资源比较宽裕,直接上AliOS Things。它的OTA组件更成熟,文档也更全。如果你是在现有产品上增加OTA功能,且不想动原有系统架构,那Link Kit SDK是更稳妥的选择。

3.2 MCU资源评估:Flash和RAM到底要多少?

这是个大坑。我见过太多人,代码写完了,编译发现Flash超了。或者OTA下载成功了,但解压时RAM不够,直接死机。

为什么会这样?因为OTA升级本身就需要额外的资源开销。你想想看,它要下载固件包,要校验,要解压,还要擦写Flash。每一步都在吃资源。

我根据经验,给你一个参考表格。注意,这是最低建议值,实际项目中建议留出30%的余量。

SDK类型 最低Flash需求 最低RAM需求 备注
AliOS Things + OTA 512KB 128KB 包含内核、网络栈、OTA组件
Link Kit SDK (裸机) 128KB 32KB 仅OTA功能,不含RTOS
Link Kit SDK (FreeRTOS) 256KB 64KB 含FreeRTOS内核

注意: 这里的Flash需求,是指应用程序+OTA功能的总和。如果你的应用本身已经占了400KB Flash,那用AliOS Things就有点悬了。我曾经在一个项目里,应用代码占了480KB,硬塞AliOS Things后只剩32KB,结果OTA升级包稍微大一点就写不进去。后来还是换成了Link Kit SDK才搞定。

另外,RAM的消耗主要在OTA下载过程中。下载的固件包需要一块缓冲区。如果你用差分升级,还需要额外的解压缓冲区。所以,评估RAM时,要算上“下载缓冲区 + 解压缓冲区 + 应用运行时栈”的总和。

3.3 开发环境搭建:Keil、IAR 与 CMake

环境搭建这事儿,说简单也简单,说烦也烦。我见过有人花了一整天装Keil,结果license过期了。也有人用CMake,五分钟就配好了。

咱们分三种情况说。

3.3.1 Keil MDK

这是ARM MCU开发者的老朋友了。如果你用STM32,大概率会选它。

  • 优点:上手快,调试方便,工程模板多。
  • 缺点:收费,且对CMake支持不好。
  • 我的建议:如果你公司有正版license,或者你只是个人学习,用Keil没问题。但要注意,AliOS Things官方提供的Keil工程,有时候需要手动添加一些源文件路径。我建议你直接下载官方的.uvprojx工程文件,不要自己从头建。

3.3.2 IAR Embedded Workbench

IAR的编译器优化做得比Keil好,代码密度更高。对于Flash紧张的MCU,IAR是个好选择。

  • 优点:编译优化强,代码小。
  • 缺点:界面风格有点老,而且同样收费。
  • 我的经验:我在一个项目中,同样的代码,Keil编译出来是98KB,IAR编译出来只有82KB。省下来的16KB,刚好够放OTA的下载缓冲区。所以,如果你资源紧张,试试IAR。

3.3.3 CMake + GCC

这是我现在最常用的方式。免费、跨平台、可脚本化。

  • 优点:免费,支持所有MCU,适合CI/CD。
  • 缺点:需要自己写CMakeLists.txt,调试不如IDE方便。
  • 我的建议:如果你做产品开发,强烈建议用CMake。因为你可以把编译、打包、生成OTA固件这些步骤,全部写成一个脚本。一键搞定。

下面是一个简单的CMakeLists.txt示例,用于编译Link Kit SDK的OTA demo:

cmake_minimum_required(VERSION 3.10)
project(ota_demo)

set(CMAKE_C_STANDARD 11)

# 添加Link Kit SDK源码
add_subdirectory(linkkit_sdk)

# 添加主程序
add_executable(ota_demo.elf
    main.c
    ota_handler.c
)

target_link_libraries(ota_demo.elf
    linkkit_sdk
)

# 生成二进制文件
add_custom_command(TARGET ota_demo.elf POST_BUILD
    COMMAND ${CMAKE_OBJCOPY} -O binary ota_demo.elf ota_demo.bin
    COMMENT "Generate binary file"
)

小技巧: 用CMake时,记得把-Os优化选项打开。我见过有人用-O0编译,结果代码体积大了三倍,Flash直接爆了。优化等级对嵌入式开发来说,不是可选项,是必选项。

3.4 本章小结

嗯,这一章内容不少。咱们捋一下重点:

  • SDK选择:资源多选AliOS Things,资源少选Link Kit SDK。
  • 资源评估:Flash至少留30%余量,RAM要算上OTA缓冲区的开销。
  • 环境搭建:Keil适合快速上手,IAR适合优化代码大小,CMake适合产品化开发。

下一章,我们就要真正开始动手移植了。我会带你一步步把SDK跑起来,然后连上阿里云。准备好了吗?