在实际开发中，许多开发者在尝试将LuatOS-Air脚本运行于标准LuatOS环境时遭遇报错或功能异常。这些问题多源于对底层驱动抽象层理解不足以及对系统任务模型的误用。本文将梳理典型错误场景，并提供可落地的修复方案，助力实现平滑迁移。
一、lua版本不一样
LuatOS-Air使用的是lua5.1版本，本身不支持位移运算符。
LuatOS使用的是lua5.3版本，取消了module(..., package.seeall)这种形式的跨文件调用。
二、api不同
首先说明，core和脚本有所不同，用户可以理解为，core是安卓/ios系统，脚本为一个又一个的app，只有core+脚本，才能支撑起完整的一个二次开发项目。
LuatOS-Air的api：
在https://doc.openluat.com/wiki/21?wiki_page_id=2068这里，又分为了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：
在https://docs.openluat.com/osapi/这里，和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也会放在最后，方便用户对比。
LuatOS-Air_uart.zip
开始移植
main.lua的改造
PROJECT和VERSION这两个参数不变，下载时候需要这两个参数
require "log"这句可以删除，底层已经写好了log库，并提供了和LuatOS-Air lib层api几乎一致的core api，查看对应的 luatos log库api https://docs.openluat.com/osapi/core/log/
后得知，几种日志模式的常量有所不同，所以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接口(https://docs.openluat.com/osapi/core/pm/)，可以看到luatos没有wake接口，但是有不休眠模式，所以先设置下不休眠，也就是将pm.wake("testUart")换成pm.request(pm.NONE)
然后执行的是uart.on两个注册函数，当时串口有接收事件产生时候，会去执行read函数，当串口有发送事件产生时，会执行writeOK函数，对比luatos的注册串口收发事件(https://docs.openluat.com/osapi/core/uart/#45-uartonid-event-func),可以看出，这两个芯片收发事件函数一致，无需更改。
最后执行的是串口设置指令，LuatOS-Air和luatos有很大不同，LuatOS-Air的uart设置接口如下(https://doc.openluat.com/wiki/21?wiki_page_id=2250#uartsetup_id_baud_databits_parity_stopbitsmsgmodetxDoneReportflowcontrolpriority_33)
luatos的uart设置接口如下(https://docs.openluat.com/osapi/core/uart/#41-uartsetupid-baud_rate-data_bits-stop_bits-partiy-bit_order-buff_size-rs485_gpio-rs485_level-rs485_delay-debug_enable-error_drop)
这两个接口，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就被我们改造成了这样
至此 整个改造过程结束，改造后的文件我也放在下面方便用户对比
luatos_uart.zip
今天的内容就分享到这里了~
