在将LuatOS-Air平台上的脚本迁移到通用LuatOS版本时，开发者首先需要关注的是两者在运行环境与API支持上的差异。尽管核心语言均为Lua，但LuatOS-Air针对特定硬件做了轻量化封装，而标准LuatOS功能更完整、模块更丰富，因此在移植过程中需对脚本结构、外设调用及任务调度机制进行适配调整，以确保代码稳定运行。
一、lua版本不一样
LuatOS-Air使用的是lua5.1版本，本身不支持位移运算符。
LuatOS使用的是lua5.3版本，取消了module(..., package.seeall)这种形式的跨文件调用。
二、api不同
首先说明，core和脚本有所不同，用户可以理解为，core是安卓/ios系统，脚本为一个又一个的app，只有core+脚本，才能支撑起完整的一个二次开发项目。
LuatOS-Air的api：
在这里，又分为了5.1原生接口，提供的额外接口两种。
在额外的接口其中，又分为了底层接口和二次封装接口，底层接口叫做core api，二次封装接口叫做script lib api，下面会简称为lib层api。
core api实现过程不可见，封装在了core里，受限于和RDA的协议，这部分实现过程不开源，而lib层的api，实现过程可见，用户可以自行修改。
lib层api一般是将底层提供的接口进行合并与封装，更加的简单与易用，也有部分lib层api是直接给core发送AT指令然后处理AT指令的返回值，并且以函数返回值的形式返回给调用该api的位置。
LuatOS的api
在这里，和LuatOS-Air一样，分为了5.3原生接口和提供的额外接口两种。
在额外的接口其中，又分为了核心库接口和扩展库接口，核心库接口叫做core api，扩展库接口叫做script lib api，下面会简称为lib层api。
core api实现过程不可见，封装在了core里，这部分实现过程不开源，而lib层的api，实现过程可见，用户可以自行修改。
LuatOS 核心库是在底层实现的功能库，调用核心库无需代码使用 require 操作；
LuatOS 扩展库是用 Lua 脚本实现的功能库，必须用 requre 调用才能够使用扩展库。
三、跨文件调用方式不同
LuatOS-Air跨文件调用方式
LuatOS-Air在每一个非main.lua的文件头部，第一行可执行代码永远是module(..., package.seeall)，主要作用是将该文件中所有的全局变量/全局函数，加入到一张名为 _G的table中方便其他.lua文件调用，在这里不做过多讲解，能有转移需求的客户，基本都会LuatOS-Air的跨文件调用方法。
luatos跨文件调用方式
luatos跨文件调用方式有两种，一种和LuatOS-Air类似，不过是在文件第一行，新建一个和文件名相同的table，文件结尾处return这个table，接下来举个例子
首先封装一个函数
我们新建一个文件叫tools.lua，把这个函数放进去，现在，整个文件如下面这样：
现在，我们封装的这个函数就能在其他文件(例如main.lua)里被调用了，具体代码如下：
当调用了require接口后，Lua虚拟机会自动加载你调用的文件，执行文件的内容，然后返回你文件里return的结果。
为了更好地理解这段话，我们可以看下面两个文件，其中main.lua是被运行的那个入口文件，
此处为第一种调用方法，简单来说，被调用文件头部，将module(..., package.seeall)换成文件名={}，文件末尾处加return {本文件中写的函数名=本文件中写的函数名}，有多个函数的时候，可以添加多个元素名= 元素名进table里。
第二种调用方法依旧是在文件开头写上文件名={}，不同的是，需要被调用的函数名，可以写成文件名.函数名的形式，最后的return不需要return一个很长的table了，只需要return 文件名，例如：
需要在main.lua 中调用test.lua的test函数，那么除了固定格式以外的main.lua可以写成
具体可参考https://gitee.com/openLuat/LuatOS/tree/master/script/libs这里所有的demo
四、实例
以uart的demo为例，笔者将带着用户，将LuatOS-Air uart的demo，移植到luatos上（仅讲解uart1的移植过程，其他串口通用），除去无关本次移植过程的部分，LuatOS-Air的uart1完整demo如下，是一个自发自收的测试demo，luatos完整的demo也会放在最后，方便用户对比。
开始移植
main.lua的改造
PROJECT和VERSION这两个参数不变，下载时候需要这两个参数
require "log"这句可以删除，底层已经写好了log库，并提供了和LuatOS-Air lib层api几乎一致的core api，查看对应的 luatos log库api
后得知，几种日志模式的常量有所不同，所以LOG_LEVEL = log.LOGLEVEL_TRACE这句，可以改成LOG_LEVEL = log.LOG_INFO，再添加一句log.setLevel(LOG_LEVEL )
因为主逻辑都在testUart1文件中，不需要在main.lua中调用，所以保持 require "testUart1" 原样即可，为了用户更直观的看出跨文件调用的不同，所以我在testUart1中又写了一个名为function_name的函数，然后在main.lua中进行循环调用。sys.init函数不需要，直接删去即可
完成上述步骤以后，main.lua就被我们改造成了下面这样
testUart1.lua的改造
接下来进入testUart1.lua中
module(...,package.seeall)改为 testUart1 ={}，pm和utils两个库，utils不需要，直接删除，pm库底层提供了，无需require，也删除。
接下来会先将proc、read、write、writeOk和我刚刚写的function_name这几个函数会加载到内存中，但是还没有执行，接下来执行的是pm.wake("testUart")，查看luatos的pm接口，可以看到luatos没有wake接口，但是有不休眠模式，所以先设置下不休眠，也就是将pm.wake("testUart")换成pm.request(pm.NONE)
然后执行的是uart.on两个注册函数，当时串口有接收事件产生时候，会去执行read函数，当串口有发送事件产生时，会执行writeOK函数，对比luatos的注册串口收发事件，可以看出，这两个芯片收发事件函数一致，无需更改。
最后执行的是串口设置指令，LuatOS-Air和luatos有很大不同
这两个接口，LuatOS-Air的和luatos最大区别就是，LuatOS-Air将485半自动收发控制分开了，单独写了一个uart.set_rs485_oe
而luatos将其写在了一起，用户在使用该接口时，一定要注意不同接口之间参数的位置。
当有串口接收事件产生时，模块会进入read函数，在read函数里，打印了data原始数据和转成hex以后的数据后，便进入了proc函数中，并且将串口来的数据传入给proc函数，进行处理。
值得注意的是，read函数里有将串口来的数据通过uart.read函数赋值给data变量这个操作，但是luatos截至当前文章完成时，uart.read函数的第二个参数，只能填number，意为每次接收的字节数，也就是需要将代码中的uart.read(UART_ID,"*l")换成uart.read(UART_ID,1024)后面这个1024，为uart.setup的第7个参数，串口缓冲区你设置的大小，未设置默认为1024字节，如果需要用户自行设置，则最小512，最大4096
而当有串口发送事件产生时，模块会进入writeOk函数，该函数比较简单，就打印了下发送成功字样。
最后一行因为有跨文件调用，所以需要return 文件名，也就是加一句return testUart1
最后整个testUart1.lua就被我们改造成了这样
今天的内容就分享到这里了~
