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跑起来,然后连上阿里云。准备好了吗?