安卓端的串口通信实践讲解2

和原生 API 不同的是，因为我们此时已经知道了我们的 ESP32 主板的设备信息，以及使用的驱动（CDC），所以我们就不使用原生的查找可用设备的方法了，我们这里直接指定我们已知的这个设备（当然，你也可以继续使用原生API的查找和连接方法）：

private fun scanDevice(context: Context) {
    val manager = context.getSystemService(Context.USB_SERVICE) as UsbManager


    val customTable = ProbeTable()
    // 添加我们的设备信息，三个参数分别为 vendroId、productId、驱动程序
    customTable.addProduct(0x1a86, 0x55d3, CdcAcmSerialDriver::class.java)


    val prober = UsbSerialProber(customTable)
    // 查找指定的设备是否存在
    val drivers: List

连接到设备后，下一步就是和数据交互，这里封装的十分方便，只需要获取到 UsbSerialPort 后，直接调用它的 read() 和 write() 即可读写数据：

port = driver.ports[0] // 大多数设备都只有一个 port，所以大多数情况下直接取第一个就行


port.open(connection)
// 设置连接参数，波特率9600，以及 “8N1”
port.setParameters(9600, 8, UsbSerialPort.STOPBITS_1, UsbSerialPort.PARITY_NONE)


// 读取数据
val responseBuffer = ByteArray(1024)
port.read(responseBuffer, 0)


// 写入数据
val sendData = byteArrayOf(0x6F)
port.write(sendData, 0)

此时，一个完整的，用于测试我们上述 ESP32 程序的代码如下：

@Composable
fun SerialScreen() {
    val context = LocalContext.current




    Column(
        Modifier.fillMaxSize(),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Button(onClick = { scanDevice(context) }) {
            Text(text = "查找并连接设备")
        }


        Button(onClick = { switchLight(true) }) {
            Text(text = "开灯")
        }
        Button(onClick = { switchLight(false) }) {
            Text(text = "关灯")
        }


    }
}


private fun scanDevice(context: Context) {
    val manager = context.getSystemService(Context.USB_SERVICE) as UsbManager


    val customTable = ProbeTable()
    customTable.addProduct(0x1a86, 0x55d3, CdcAcmSerialDriver::class.java)


    val prober = UsbSerialProber(customTable)
    val drivers: List

运行这个程序，并且连接设备。

可以看到输出的是 byte 的 101，转换为 ASCII 即为 “e”。

然后我们点击 “开灯”、“关灯” 效果如下：

对了，这里发送的数据 “0x6F” 即 ASCII “o” 的十六进制，同理，“0x63” 即 “c”。

可以看到，可以完美的和我们的 ESP32 开发版进行通信。

实例

无论使用什么方式与串口通信，我们在安卓APP的代码层面能够拿到的数据已经是处理好了的数据。

即，在上一篇文章中我们说过串口通信的一帧数据包括起始位、数据位、校验位、停止位。但是我们在安卓中使用时一般拿到的都只有 数据位 的数据，其他数据已经在底层被解析好了，无需我们去关心怎么解析，或者使用。

我们可以直接拿到的就是可用数据。

这里举一个我之前用过的某型号驱动版的例子。

这块驱动版关于通信的信息如图：

可以看到，它采用了 RS485 的通信方式，波特率支持 9600 或 38400，8位数据位，无校验，1位停止位。

并且，它还规定了一个数据协议。

在它定义的协议中，第一位为地址；第二位为指令；第三位到第N位为数据内容；最后两位为CRC校验。

需要注意的是，这里定义的协议是基于串口通信的，不要把这个协议和串口通信搞混了，简单来说就是在串口通信协议的数据位中又定义了一个自己的协议。

而且可以看到，虽然定义串口参数时没有指定校验，但是在它自己的协议中指定了使用 CRC 校验。

另外，弱弱的吐槽一句，这个驱动版的协议真的不好使。

在实际使用过程中，主机与驱动版的通信数据无法保证一定会在同一个数据帧中发送完成，所以可能会造成“粘包”、“分包”现象，也就是说，数据可能会分几次发过来，而且你不好判断这数据是上次没发送完的数据还是新的数据。

我使用过的另外一款驱动版就方便的多，因为它会在帧头加上开始符号和数据长度，帧尾加上结束符号。

这样一来，即使出现“粘包”、“分包”我们也能很好的给它解析出来。

当然，它这样设计协议肯定是有它的道理的，无非就是减少通信代价之类的。

我还遇到过一款十分简洁的驱动版，直接发送一个整数过去表示执行对应的指令。

驱动版回传的数据同样非常简单，就是一个数字，然后事先约定各个数字表示什么意思……

说归说，我们还是继续来看这款驱动版的通信协议：

这是它的其中一个指令内容，我们发送指令 “1” 过去后，它会返回当前驱动版的型号和版本信息给我们。

因为我们的主板是定制工控主板，所以使用的通信方式是直接用 android-serialport-api。

最终发送与接收回复也很简单：

/**
 * 将十六进制字符串转成 ByteArray
 * */
private fun hexStrToBytes(hexString: String): ByteArray {
    check(hexString.length % 2 == 0) { return ByteArray(0) }


    return hexString.chunked(2)
        .map { it.toInt(16).toByte() }
        .toByteArray()
}


private fun isReceivedLegalData(receiveBuffer: ByteArray): Boolean {


    val rcvData = receiveBuffer.copyOf()  //重新拷贝一个使用，避免原数据被清零


    if (cmd.cmdId.checkDataFormat(rcvData)) {  //检查回复数据格式
        isPkgLost = false
        if (cmd.cmdId.isResponseBelong(rcvData)) {  //检查回复命令来源
            if (!AdhShareData.instance.getIsUsingCrc()) {  //如果不开启CRC检验则直接返回 true
                resolveRcvData(cmdRcvDataCallback, rcvData, cmd.cmdId)
                coroutineScope.launch(Dispatchers.Main) {
                    cmdResponseCallback?.onCmdResponse(ResponseStatus.Success, rcvData, 0, rcvData.size, cmd.cmdId)
                }
                return true
            }


            if (cmd.cmdId.checkCrc(rcvData)) {  //检验CRC
                 resolveRcvData(cmdRcvDataCallback, rcvData, cmd.cmdId)
                coroutineScope.launch(Dispatchers.Main) {
                    cmdResponseCallback?.onCmdResponse(ResponseStatus.Success, rcvData, 0, rcvData.size, cmd.cmdId)
                }


                return true
            }
            else {
                coroutineScope.launch(Dispatchers.Main) {
                    cmdResponseCallback?.onCmdResponse(ResponseStatus.FailCauseCrcError, ByteArray(0), -1, -1, cmd.cmdId)
                }


                return false
            }
        }
        else {
            coroutineScope.launch(Dispatchers.Main) {
                cmdResponseCallback?.onCmdResponse(ResponseStatus.FailCauseNotFromThisCmd, ByteArray(0), -1, -1, cmd.cmdId)
            }


            return false
        }
    }
    else {  //数据不符合，可能是遇到了分包，继续等待下一个数据，然后合并
        isPkgLost = true
        return isReceivedLegalData(cmd)
        /*coroutineScope.launch(Dispatchers.Main) {
            cmdResponseCallback?.onCmdResponse(ResponseStatus.FailCauseWrongFormat, ByteArray(0), -1, -1, cmd.cmdId)
        }


        return false  */
    }
}


// ……省略初始化和连接代码


// 发送数据
val bytes = hexStrToBytes("0201C110")
outputStream.write(bytes, 0, bytes.size)


// 解析数据
val recvBuffer = ByteArray(0)
inputStream.read(recvBuffer)


while (receiveBuffer.isEmpty()) {
   delay(10)
}


isReceivedLegalData()

本来打算直接发我封装好的这个驱动版的协议库的，想了想，好像不太合适，所以就大概抽出了这些不完整的代码，懂这个意思就行了，哈哈。

总结

从上面介绍的两种方式可以看出，两种方式使用各有优缺点。

使用 android-serialport-api 可以直接读取串口数据内容，不需要转USB接口，不需要驱动支持，但是需要 ROOT，适合于定制安卓主板上已经预留了 RS232 或 RS485 接口且设备已 ROOT 的情况下使用。

而使用 USB host ，可以直接读取USB接口转接的串口数据，不需要ROOT，但是只支持有驱动的串口转USB芯片，且只支持使用USB接口，不支持直接连接串口设备。

各位可以根据自己的实际情况灵活选择使用什么方式来实现串口通信。

当然，除了现在介绍的这些串口通信，其实还有一个通信协议在实际使用中用的非常多，那就是 MODBUS 协议。