一种串口通信处理方法、装置及电子设备与流程

本申请属于通信技术领域，尤其涉及串口通信处理方法、装置及电子设备。

背景技术：

串口是许多电子设备中的一种常见资源。当电子设备内部具有多种不同的服务模块，并使用串口实现服务模块和相应的内部或外部硬件的数据通信时。例如当机器人内部有伺服服务模块和电机服务模块等服务模块，并通过串口与对应的舵机和电机等硬件进行数据通信，以实现对舵机和电机等硬件的控制时。由于串口是共用的信道，因此这些不同的服务模块的请求数据可能会相互干扰。综上，电子设备通过串口进行数据通信时容易出现通信冲突。

技术实现要素：

有鉴于此，本申请实施例提供了一种串口通信处理方法、装置及电子设备，可以解决电子设备通过串口进行数据通信时容易出现通信冲突的问题。

本申请实施例的第一方面提供了一种串口通信处理方法，应用于电子设备，所述电子设备内包含请求队列、串口收发模块和串口，所述请求队列用于缓存待发送的第一请求，所述串口通信处理方法，包括：

检测所述串口收发模块是否接收到由第一硬件针对第二请求发送的第一响应数据；所述第二请求为所述串口收发模块距离当前时刻最近一次使用所述串口发送的请求；

若所述串口收发模块已接收到所述第一响应数据，则从所述请求队列的所述第一请求中提取出一个第三请求；

控制所述串口收发模块使用所述串口将所述第三请求发送至所述第一硬件。

本申请实施例的第二方面提供了一种串口通信处理装置，包括：

缓存单元，用于在检测待发送的第一请求时，将所述第一请求缓存至所述请求队列；

响应检测单元，用于检测串口收发模块是否接收到第一硬件针对第二请求发送的第一响应数据；所述第二请求为所述串口收发模块距离当前时刻最近一次使用串口发送的请求；

第一请求提取单元，用于在所述串口收发模块已接收到所述第一响应数据时，从所述请求队列中提取出一个第三请求；

第一请求发送单元，用于控制所述串口收发模块使用所述串口将所述第三请求发送至所述第一硬件。

本申请实施例的第三方面提供了一种电子设备，所述电子设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面中任一项所述串口通信处理方法的步骤。

本申请实施例的第四方面提供了一种计算机可读存储介质，包括：存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如上述第一方面中任一项所述串口通信处理方法的步骤。

本申请实施例的第五方面提供了一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面中任一项所述串口通信处理方法。

本申请实施例与现有技术相比存在的有益效果是：本申请实施例在检测到新的请求时，将新的请求缓存至请求队列之中。在此基础上，每次仅会从请求队列中提取出的一个请求，并由串口收发模块使用串口将该请求发送给对应的硬件。在串口收发模块使用串口发出一个请求之后，直至接收到对该请求的响应数据之前，本申请实施例都不会使用串口发送其他的请求。而在接收到该请求对应的响应数据之后，才会从请求队列中再次提取出一个请求，并由发送给对应的硬件。因此串口处同一时刻，仅会发送一个请求或者接收一个响应数据，实现了串口对数据处理的串行化。进而避免了串口出现数据相互干扰，通信冲突的情况出现。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的串口通信处理方法的实现流程示意图；

图2是本申请实施例提供的串口通信处理方法的实现流程示意图；

图3是本申请实施例提供的场景示意图；

图4是本申请实施例提供的串口通信处理装置的结构示意图；

图5是本申请实施例提供的电子设备的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

为了便于理解本申请，此处先对本发明实施例进行简要说明：

实际应用中，串口可分为全双工和半双工两种数据传输方式。由于服务模块发送请求的数量和时机不定，同时对应的内部或外部硬件返回响应数据的时机和数量更是难以预测。因此，同一时刻，串口收发模块可能会有多条需要发送的请求，同时接收到多条需要转发的响应数据。因此无论对于半双工还是半双工的串口而言，这些请求和响应数据都可能会相互干扰，进而容易出现通信冲突的情况。

为了避免电子设备在使用串口时出现通信冲突，本申请实施例在检测到新的请求时，不会直接将新的请求发送出去，而是会将新的请求缓存至请求队列之中，以对所有待发送的请求进行统一缓存。在此基础上，本申请实施例每次仅会从请求队列中提取出的一个请求，并由串口收发模块使用串口将该请求发送给对应的硬件。在串口收发模块每次使用串口发出一个请求之后，直至接收到对该请求的响应数据之前，本申请实施例都不会使用串口发送其他的请求。与此同时，在接收到该请求对应的响应数据之后，本申请实施例则会从请求队列中再次提取出一个请求，并由串口收发模块使用串口将该请求发送给对应的硬件。并重复上述等待响应数据再取出请求和发送请求的操作。

由于每次仅会在接收到上一次发送的请求对应的响应数据之后，才会开始从请求队列中提取出一个请求，并进行下一轮的请求发送。因此串口处同一时刻，仅会发送一个请求或者接收一个响应数据，实现了串口对数据处理的串行化。进而避免了数据相互干扰，通信冲突的情况出现。

同时，对本申请实施例中可能出现的一些词语进行解释如下：

服务模块：是电子设备中的软件模块，用于根据电子设备的实际需求或设置生成相应请求，并基于生成的请求与电子设备的内部或外部硬件进行通信，以实现对这些硬件的控制，或者硬件数据的获取。例如，一些常用的服务模块包括：伺服服务模块、电机服务模块、传感器服务模块和传感器扫描仪模块。本申请实施例不对电子设备内包含的服务模块种类和数量等进行过多限定，可由技术人员根据实际需求确定。

请求队列：是指用于存储服务模块生成的请求的队列。本申请实施例中不对请求队列对请求的存储方式进行过多限定，可由技术人员根据实际需求设置。在本申请的一些可选实施例中，每个请求都有着对应的优先级，以区分不同请求的重要性。因此需要对请求的优先级数据进行存储。本申请实施例不对优先级数据的存储方式进行过多限定，可由技术人员自行设定。例如，可以将各个请求的优先级数据携带于请求数据之中，亦可以设置一个用于存储请求和对应优先级的数据表。对应的，在对不同优先级请求进行缓存时，既可以选择对请求队列中的请求进行优先级排序并存储，亦可以选择不进行排序。

串口收发模块：是指负责对串口进行串口数据收发的软件模块。其中串口数据包括服务模块生成的请求，以及第一硬件针对请求生成的响应数据。在实际应用中，不同技术人员对串口收发模块的命名可能会存在一定的差异，因此此处不对串口收发模块的实际使用名称进行过多的限定。例如，在一些可选实施例中，可以将串口收发模块命名为channeluart。

第一硬件：是与服务模块进行通信的硬件的统称，第一硬件可以根据接收服务模块发送的一些请求进行响应，并返回对应的响应数据。在本申请实施例中，第一硬件可以是电子设备内部或外部的硬件。例如在一些可选实施例，假设电子设备中包含电机，且可以通过电机服务模块对电机进行控制。此时电机即属于第一硬件。而在另一些可选实施例中，假设电子设备与另一台设备通过串口通信连接，同时电子设备中服务模块a可以通过发送请求的方式，获取另一台设备的特定数据。此时另一台设备亦属于第一硬件。

电子设备：是本申请实施例的执行主体。本申请实施例不对电子设备的具体设备类型进行过多限定，可以根据实际应用场景确定。例如，可以是具有串口的车辆或机器人等设备，亦可以是其他具有串口的设备。

为了说明本申请所述的技术方案，下面以电子设备是机器人为例，通过具体实施例来进行说明，应当理解地，当电子设备为其他非机器人的设备时，以下实施例亦可适用。

图1示出了本申请实施例一提供的串口通信处理方法的实现流程图，详述如下：

s101，若检测到待发送的第一请求，则将第一请求缓存至请求队列。

在本申请实施例中，第一请求是机器人内需要发送给第一硬件的请求的统称。该请求可由机器人生成(如由服务模块生成)，亦可以是由其他设备发送给机器人的。

例如在一些可选实施例中，假设机器人中包含电机服务模块和传感器扫描仪模块，同时包含电机和传感器。在此基础上，若希望电机转动以使机器人移动。此时可以由电机服务模块生成相应的请求，并由串口收发模块使用串口将该请求发送至电机。而若需要扫描机器人中的传感器在线情况，以便实现热插拔。此时则可以由传感器扫描仪模块生成相应的请求，并由串口收发模块使用串口将该请求发送至传感器。又例如在前一实施例基础上，假设机器人接收到其他设备发送的用于控制电机的请求，并判定需要对该请求进行响应。此时本申请实施例亦会由串口收发模块使用串口将该请求发送至电机。

另外，本申请实施例不对第一请求的数据格式和内容进行过多限定，可根据实际应用场景确定。

当机器人的服务模块生成第一请求，或者机器人接收到第一请求时，本申请实施例不会直接将其发送给第一硬件，而是会将这些请求缓存至请求队列。应当理解地，第一请求的数量和生成时间均无法预先确定，因此每次缓存第一请求的数量亦需根据实际情况确定。

s102，检测串口收发模块是否接收到由第一硬件针对第二请求发送的第一响应数据，其中，第二请求为串口收发模块距离当前时刻最近一次使用串口发送的请求。

在对请求进行缓存得到请求队列的基础上，本申请实施例会从缓存队列中提取请求，并使用串口发送至对应的第一硬件。同时为了保障每一次仅会使用串口发送一条请求。本申请实施例仅会在每条请求被响应之后，才会发送下一条请求。具体而言：本申请实施例会检测最近一次发送的请求(即第二请求)是否被响应。若串口收发模块已接收到对该请求的响应数据(即第一响应数据)，即说明该请求已被成功响应。若串口收发模块未接收到对应的响应数据，则说明该请求还未被成功响应。

应当说明地，s102中的检测操作，既可以是主动检测也可以是被动检测，具体可由技术人员根据实际需求设定。其中，主动检测是指：机器人主动通过数据查找或匹配等操作，判断是否接收到第一响应数据。被动检测是指：设置一个被动触发的机制。当接收到第一响应数据时，则触发该机制，以使得机器人获知当前已接收到第一响应数据。反之，若该机制未被触发，则可以判定检测结果为未接收到第一响应数据。相对于主动检测，被动检测可以不进行数据查找或匹配等操作。

同时，对主动检测具体的触发条件类型及数量此处不做过多限定，可由技术人员根据实际需求设定。例如，可以同时设置多个触发条件，只要满足其中任意一种或多种，即可触发机器人执行s102操作。作为本申请的一个可选实施例，可以将：有服务模块生成请求时触发、接收到其他设备发送的请求时触发、以固定频率触发和在发送请求(在s102中即为第二请求)的预设的时长阈值后触发，这四种触发条件中的任意一个或多个作为本申请实施例中主动检测的触发条件。当满足任意一个触发条件时，则执行s102的操作。其中，固定频率和预设时长阈值的值，均可由技术人员自行设定。相应的，作为本申请的一个可选实施例，在s102之前，还可以包括以下步骤的任意一个或多个步骤(其中，s1001和s1002不能同时选取)：

s1001，若检测到待发送的第一请求，则执行s102。

s1002，若s101中，将第一请求已缓存至请求队列，则执行s102。

s1003，以预设的固定频率执行s102。

s1004，在串口收发模块在发出第二请求时开始计时，并在计时达到预设的时长阈值时，执行s102。

对于s1001而言，也可以与s101合并，此时s101可以被替换为：

若检测到待发送的第一请求，则将第一请求缓存至请求队列，并执行s102。

对于s1002而言，也可以与s101合并，此时s101可以被替换为：

若检测到待发送的第一请求，则将第一请求缓存至请求队列，并在将第一请求缓存至请求队列后，执行s102。

应当特别说明地，在本申请实施例中，s101是一个可能重复多次的操作。即每次有新的请求时均会执行一次s101。而s102亦是一个可能重复多次的操作，即每次在发送出请求之后，均会有s102的操作。同时s101和s102之间并没有必然的执行顺序先后。即在每次检测到有新的请求时，本申请实施例会将该新请求缓存到请求队列，但不一定会触发s102的操作。而作为本申请的一个可选实施例，若将有服务模块生成请求时触发和接收到其他设备发送的请求时触发均设置为主动检测的触发条件。此时“检测到第一请求”在是s101的触发条件的同时，也成为了s102的触发条件之一。对应的，s102可以与s101同步执行，也可以在s101完成之后执行s102。

s103，若串口收发模块已接收到第一响应数据，则从请求队列的第一请求中提取出一个第三请求。

s104，控制串口收发模块使用串口将第三请求发送至第一硬件。

若串口收发模块已接收的第一响应数据，此时则说明可以开启下一次的请求发送。因此本申请实施例会从请求队列内缓存的请求中，提取出一个请求(即第三请求)作为本次发送的请求。其中，本申请实施例不对第三请求提取的方法进行过多限定，可由技术人员根据实际需设定。

作为本申请的一个可选实施例，考虑到不同的请求对用户的影响程度不同。同时不同请求对机器人自身的重要程度也会存在一定的差异。而在将请求统一缓存值请求队列，且每次仅提取一条请求发送时。若不对请求队列内各条请求进行区分，而是按随机或者时间顺序等规则来进行请求提取和发送。极有可能导致一些对用户体验影响较大或者对机器人自身较为重要的请求，反而较晚被发送出去，进而影响用户对机器人的正常使用，以及机器人自身的性能。为了解决这一问题，本申请实施例中会对每条请求均设置一个对应的优先级，其中，越为重要的请求其优先级越高。在此基础上，在进行第三请求提取的时候。则将请求队列中优先级最高的请求作为第三请求进行提取。以使得当次发送的请求均为当前优先级最高的请求。进而保障了一些对用户体验影响较大或者对机器人自身较为重要的请求，可以优先被发送出去。其中，本申请实施例不对优先级评估的具体维度进行过多限定，可由技术人员根据实际需求自行设定。例如可以从对用户体验的影响和对机器人自身正常运行的重要程度，这两方面的任意一方面或者两方面出发，来进行重要性评估和优先级设置。

作为本申请的一个可选实施例，本申请实施例会根据服务模块对硬件的控制是否会导致机器人有外部的表现，进而使得用户可以感知到，来对服务模块进行分类。将服务模块分为前台类模块和后台类模块。其中前台类模块对硬件的控制结果，可以被用户通过视觉、听觉或触觉等方式感知到，进而影响用户体验。同时，将前台类模块生成的请求的优先级，设置为高于后台类模块生成的请求的优先级。从而使得前台类模块生成的请求可以被优先发送出去，进而使得前台类模块生成的请求可以被优先处理和响应。

例如，假设机器人中包含伺服服务模块和电机服务模块，以及对应的舵机和电机。伺服服务模块可以对舵机进行控制，电机服务模块可以对电机进行控制，进而影响机器人的运动方向和速度等。这些控制结果均会被用户感知到，因此伺服服务模块和电机服务模块属于前台类模块。而对于传感器服务模块和传感器扫描仪模块而言，由于其对传感器进行扫描或控制时，并不会直接对机器人造成用户可感知的影响。因此可以划分为后台类模块。在此基础上，伺服服务模块和电机服务模块生成的请求的优先级，均会高于传感器服务模块和传感器扫描仪模块生成的请求的优先级。

s105，若串口收发模块接收到由第一硬件针对第三请求发送的第二响应数据，则从请求队列中提取出一个第四请求。

s106，控制串口收发模块使用串口将第四请求发送至第一硬件。

其中，对第四请求的提取和发送等操作，亦可以参考s103和s104的说明，此处不予赘述，此时第二响应数据相当于s103中的第一响应数据，第四请求相当于s103中的第三请求。由于本申请实施例是一个对使用串口进行请求持续发送的过程。因此在每次发出一个请求之后，均会有下一次的响应数据接收检测以及请求提取和发送的操作。因此理论上s103-s104，以及s105-s106的操作，可能会反复执行多次。具体执行的次数需根据实际应用场景确定。

应当说明地，由于第一硬件是对与服务模块进行通信的硬件的统称，而不同的请求实际执行的硬件可能相同或不同。因此在本申请实施例中，将请求发送至第一硬件的操作，实际是指将该请求发送至该请求指向的硬件。即这其中包含着确定请求实际指向硬件的操作。相应的，将第二请求发送至第一硬件、将第三请求发送至第一硬件和将第四请求发送至第一硬件，是指将第二请求发送至第二请求指向的第一硬件、将第三请求发送至第三请求指向的第一硬件和将第四请求发送至第四请求指向的第一硬件。

以上述机器人中包含伺服服务模块和电机服务模块，以及对应的舵机和电机的实例，继续进行举例说明。假设第二请求和第四请求是由伺服服务模块生成的请求，而第三请求是由电机服务模块生成的请求。在此基础上，机器人在需要发送第二请求或第四请求时，会先确定出第二请求或第四请求指向的是舵机。再由串口收发模块使用串口将第二请求发送至舵机。同理，在需要发送第三请求时，会先确定出第三请求指向的是电机。再由串口收发模块使用串口将第三请求发送至电机。

本申请实施例中，机器人在每次有新的请求时，均会将新请求缓存至请求队列之中，并根据请求的重要程度为每个请求设置好对应的优先级。在满足预设的任一触发条件时，机器人均会检测串口收发模块最近一次发送的请求是否被成功响应。并仅在最近一次发送的请求被成功响应时，从请求队列中提取出优先级最高的请求。再控制串口收发模块，使用串口将该请求发送至对应的硬件。从而实现对所有待发送请求的串行化处理。对于串口而言，每次仅需发送一条请求给硬件。同时，同一时刻最多只需要处理一条请求或者响应数据。因此串口处不会出现数据干扰。即使在有较多数据需要利用串口通信时，依然可以使得各个请求可以稳定快速地发送出去，使得串口通信数据的完整性和及时性得到有效的保障，避免了机器人通过串口进行数据通信时容易出现通信冲突的问题。另外，由于各个请求的优先级可以由技术人员根据实际需要灵活设定，因此使得对串口通信的开发和调整更为灵活。

关于图1所示实施例的一些说明：

一、s102中被动检测的一种可选方式。

作为本申请的一个可选实施例，为了实现对串口收发模块最近一次发送的请求是否被成功响应的检测，本申请实施例会在串口收发模块内设置一个互斥锁。通过每次发生请求时对互斥锁加锁，每次接到响应数据时对互斥锁解锁的方式。因此在判断请求是否被成功响应时，只需判断互斥锁是否被加锁即可。具体而言，本申请实施例包括：

若串口收发模块使用串口将第二请求发送至第一硬件，则对互斥锁加锁，以使得互斥锁处于加锁状态。

其中，本申请实施例不对请求发送操作，和对互斥锁加锁操作的时间先后，进行过多限定。例如，在一些实施例中，可以设置为在发送请求之前，先对互斥锁加锁再发送请求。而在另一些实施例中，亦可以同时进行请求发送和加锁的操作，或者先发送请求再进行加锁。具体可由技术人员自行设定。

若串口收发模块接收到第一响应数据，则对互斥锁进行解锁，以使得互斥锁处于解锁状态。

本申请实施例中，在接收到响应数据后，则会对互斥锁进行解锁。

相应的，s102中检测串口收发模块是否接收到由第一硬件针对第二请求发送的第一响应数据，包括：

获取互斥锁的状态。

若互斥锁为解锁状态，则判定为串口收发模块已接收到第一响应数据。

由于本申请实施例会根据请求发送的情况，以及响应数据接收的情况，来对互斥锁进行加解锁。因此，在需要检测串口收发模块是否接收到响应数据时，只需要获取互斥锁状态即可。当为加锁状态时，说明仍未接收到响应数据。若为解锁状态，则说明已接收到响应数据。其中，由于互斥锁解锁后可以主动唤醒特定线程或任务，以告知机器人互斥锁为解锁状态，即此时已接收到了响应数据。因此在本申请实施例中，可以实现对请求是否被成功响应的被动检测。而在互斥锁未主动唤醒特定线程或任务时，则说明互斥锁处于加锁状态。可以将s102的结果持续判定为串口收发模块未检测到第一响应数据。因此本申请实施例无需通过轮询等方式来主动检测s102的结果。进而使得本申请实施例检测响应数据的操作更加简洁高效，且不会耗费cpu过多时间和资源进行数据检测。

二、针对一些意外情况导致长时间无响应数据返回的应对措施。

考虑到实际情况中，当硬件出现故障、掉线或者毁坏等意外情况时，硬件是难以或者无法回复请求对应的响应数据的。因此在本申请实施例中，若在向第一硬件发送请求之后，若遇到第一硬件故障、掉线或者毁坏等意外情况。可能会导致串口收发模块无法收到响应数据的情况。此时若仍等待接收到最近一次请求对应的响应数据，才开启下一次请求的选取和发送，可能会导致机器人长时间无法进行正常工作。为了防止这一情况出现，本申请实施例会设置一个响应超时的判断机制，并会在响应超时时将串口使用权转移，即重新从请求队列中进行请求提取和发送。进而保障机器人的正常运行。具体而言，参考图2，本申请实施例包括：

s201，检测串口收发模块在发出第二请求之后的预设超时时长内，是否接收到第一响应数据。

s202，若串口收发模块在发出第二请求之后的预设超时时长内未接收到第一响应数据，则从请求队列中提取出一个第三请求。

s203，控制串口收发模块使用串口将第三请求发送至第一硬件。

本申请实施例会预先设置一个预设超时时长，以作为判断是否超时的依据。在串口收发模块发送请求时，会同步开始计时。若在计时时长达到预设超时时长时，仍没有接收到针对请求的响应数据。则说明当前已属于响应超时的情况。此时本申请实施例会继续从请求队列中提取请求并发送请求，以保障对请求队列中各个请求的正常处理，保障机器人的正常运行。其中预设超时时长的具体值，可由技术人员根据实际需求设定，此处不做过多限定。例如，在一些可选实施例中，可以设置为5秒。

由于第二请求是指串口收发模块最近一次发送的请求，而不是特征某一个请求。对于任何一个请求a而言，在其被串口收发模块发送之后，直至串口收发模块发送下一个请求之前，该请求a即为第二请求。因此s201-s203的操作，理论上是适用于任意一个已发送的请求。即在每次串口收发模块发送请求之后，均可以执行s201-s203的操作。

三、可以将上述说明点一和说明点二进行结合。

作为本申请的一个可选实施例，当采用了互斥锁进行响应数据是否接收到的检测时，为了实现对响应超时的判断，在本申请实施例中，包括：

检测互斥锁在加锁后的预设超时时长内是否解锁。

若互斥锁在加锁后的预设超时时长内未解锁，则对互斥锁解锁，以使得互斥锁处于解锁状态。

由于互斥锁仅会在接收到响应数据时解锁。因此若互斥锁在加锁后的预设超时时长内没有解锁，则说明当前已属于响应超时的情况。此时本申请实施例会对互斥锁进行解锁。以继续从请求队列中提取请求并发送请求，保障对请求队列中各个请求的正常处理，保障机器人的正常运行。其中预设超时时长的具体值，可由技术人员根据实际需求设定，此处不做过多限定。例如，在一些可选实施例中，可以设置为5秒。

四、以一实例进行举例说明。

参考图3，假设机器人中包含有伺服服务模块、电机服务模块、传感器服务模块和传感器扫描仪模块，同时包含串口，以及舵机、电机和传感器。其中，伺服服务模块用于对舵机进行控制，电机服务模块用于对电机进行控制，传感器服务模块用于对传感器进行控制，传感器扫描仪模块用于检测传感器的在线状态。假设伺服服务模块、电机服务模块、传感器服务模块和传感器扫描仪模块，分别生成了请求1、请求2、请求3和请求4，且4个请求优先级依次为1、2、3和4。其中优先级数字越小，优先级越高。同时假设预设超时时长设定为5秒，串口收发模块内设置有互斥锁，串口收发模块发送请求前会对互斥锁加锁，接收到响应数据时会对互斥锁解锁。检测方式为被动检测，即当互斥锁解锁时，才开始对下一个请求的选取和发送。串口收发模块最近一次请求发送操作，是在1秒前发送了一个请求0给电机，并对互斥锁加锁。

在本申请实施例中，请求1、请求2、请求3和请求4均会被存储至请求队列之中。同时会等待电机返回针对前一请求的响应数据。

若互斥锁加在锁后的5秒内未解锁，则本申请实施例会从请求队列中提取出优先级最高的请求1，并控制串口收发模块使用串口将请求1发送至舵机，对互斥锁加锁。并检测互斥锁加锁后的5秒内是否解锁。

若互斥锁在5秒内解锁了，则本申请实施例会在互斥锁解锁时，从请求队列中提取出优先级最高的请求1，控制串口收发模块使用串口将请求1发送至舵机，对互斥锁加锁。并检测互斥锁加锁后的5秒内是否解锁。

若互斥锁加在锁后的5秒内未解锁，则本申请实施例会从请求队列中提取出优先级最高的请求2(假设此时请求队列中请求2优先级为最高)，并控制串口收发模块使用串口将请求2发送至电机，对互斥锁加锁。并检测互斥锁加锁后的5秒内是否解锁。

若互斥锁在5秒内解锁了，则本申请实施例会从请求队列中提取出优先级最高的请求2(假设此时请求队列中请求2优先级为最高)，并控制串口收发模块使用串口将请求2发送至电机，对互斥锁加锁。并检测互斥锁加锁后的5秒内是否解锁。

依次类推，本申请实施例会重复：从请求队列中提取出优先级最高的请求，发送给对应的硬件，并对互斥锁加锁以及检测互斥锁是否在5秒内检索的操作。由于机器人的正常运行时间不定，运行过程中产生的请求数量和时间也不定，因此上述对请求队列进行请求提取和互斥锁加锁解锁操作的重复次数亦无法确定。具体需根据实际场景确定。

对应于上文实施例的方法，图4示出了本申请实施例提供的串口通信处理装置的结构框图，为了便于说明，仅示出了与本申请实施例相关的部分。串口通信处理装置可以是前述实施例一提供的串口通信处理方法的执行主体。

参照图4，该串口通信处理装置包括：

缓存单元41，用于在检测待发送的第一请求时，将所述第一请求缓存至所述请求队列；

响应检测单元42，用于检测串口收发模块是否接收到第一硬件针对第二请求发送的第一响应数据；所述第二请求为所述串口收发模块距离当前时刻最近一次使用串口发送的请求；

第一请求提取单元43，用于在所述串口收发模块已接收到所述第一响应数据时，从所述请求队列中提取出一个第三请求；

第一请求发送单元44，用于控制所述串口收发模块使用所述串口将所述第三请求发送至所述第一硬件。

进一步地，所述缓存队列缓存的各个所述第一请求均具有对应的优先级；所述第三请求为所述缓存队列中优先级最高的第一请求。

进一步地，所述串口收发模块内设置有互斥锁，该串口通信处理装置，还包括：

加锁单元，用于在所述串口收发模块使用所述串口将所述第二请求发送至所述第一硬件前，对所述互斥锁加锁，以使得所述互斥锁处于加锁状态；

解锁单元，用于在所述串口收发模块接收到所述第一响应数据后，对所述互斥锁进行解锁，以使得所述互斥锁处于解锁状态；

相应的，响应检测单元42，包括：

状态获取单元，获取所述互斥锁的状态；

检测判定单元，在所述互斥锁为所述解锁状态时，判定为所述串口收发模块已接收到所述第一响应数据。

进一步地，该串口通信处理装置，还包括：

第一超时检测单元，用于检测所述串口收发模块在发出所述第二请求之后的预设超时时长内，是否接收到所述第一响应数据；

第二请求提取单元，用于在所述串口收发模块在发出所述第二请求之后的所述预设超时时长内未接收到所述第一响应数据时，从所述请求队列中提取出一个所述第三请求；

第二请求发送单元，用于控制所述串口收发模块使用所述串口将所述第三请求发送至所述第一硬件。

进一步地，该串口通信处理装置，还包括：

第二超时检测单元，用于检测所述互斥锁在加锁后的预设超时时长内是否解锁；

超时解锁单元，用于在所述互斥锁在加锁后的所述预设超时时长内未解锁时，对所述互斥锁解锁，以使得所述互斥锁处于所述解锁状态。

进一步地，所述第一硬件包括舵机、电机和传感器，所述第一硬件包括舵机、电机和传感器，所述电子设备中还包含服务模块，且所述第一请求是由所述服务模块生成的；

所述服务模块包括：前台类模块和后台类模块；

所述前台类模块包括：伺服服务模块和电机服务模块中的一种或多种模块；

所述后台类模块包括：传感器服务模块和传感器扫描仪模块中的一种或多种模块；其中，所述伺服服务模块为对所述舵机进行控制的服务模块，所述电机服务模块为对所述电机进行控制的服务模块，所述传感器服务模块为对所述传感器进行控制的服务模块，所述传感器扫描仪模块为对所述传感器进行扫描的服务模块；

所述前台模块生成的请求的优先级，高于所述后台模块生成的请求的优先级。

进一步地，该串口通信处理装置，还包括：

第三请求提取单元，用于在所述串口收发模块接收到由所述第一硬件针对第三请求发送的第二响应数据时，从所述请求队列中提取出一个第四请求；

第三请求发送单元，用于控制所述串口收发模块使用所述串口将所述第四请求发送至所述第一硬件。

本申请实施例提供的串口通信处理装置中各模块实现各自功能的过程，具体可参考前述图1至图3所示实施例，以及其他所有相关实施例的描述，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。还应理解的是，虽然术语“第一”、“第二”等在文本中在一些本申请实施例中用来描述各种元素，但是这些元素不应该受到这些术语的限制。这些术语只是用来将一个元素与另一元素区分开。例如，第一表格可以被命名为第二表格，并且类似地，第二表格可以被命名为第一表格，而不背离各种所描述的实施例的范围。第一表格和第二表格都是表格，但是它们不是同一表格。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

本申请实施例提供的串口通信处理方法可以应用于手机、平板电脑、可穿戴设备、车载设备、增强现实(augmentedreality，ar)/虚拟现实(virtualreality，vr)设备、笔记本电脑、超级移动个人计算机(ultra-mobilepersonalcomputer，umpc)、上网本、个人数字助理(personaldigitalassistant，pda)等电子设备上，本申请实施例对电子设备的具体类型不作任何限制。

图5是本申请一实施例提供的电子设备的结构示意图。如图5所示，该实施例的电子设备5包括：至少一个处理器50(图5中仅示出一个)、存储器51，所述存储器51中存储有可在所述处理器50上运行的计算机程序52。所述处理器50执行所述计算机程序52时实现上述各个串口通信处理方法实施例中的步骤，例如图1所示的步骤101至106。或者，所述处理器50执行所述计算机程序52时实现上述各装置实施例中各模块/单元的功能，例如图4所示模块41至44的功能。

所述电子设备可包括，但不仅限于，处理器50、存储器51。本领域技术人员可以理解，图5仅仅是电子设备5的示例，并不构成对电子设备5的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述电子设备还可以包括输入发送设备、网络接入设备、总线等。

所称处理器50可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器51在一些实施例中可以是所述电子设备5的内部存储单元，例如电子设备5的硬盘或内存。所述存储器51也可以是所述电子设备5的外部存储设备，例如所述电子设备5上配备的插接式硬盘，智能存储卡(smartmediacard，smc)，安全数字(securedigital，sd)卡，闪存卡(flashcard)等。进一步地，所述存储器51还可以既包括所述电子设备5的内部存储单元也包括外部存储设备。所述存储器51用于存储操作系统、应用程序、引导装载程序(bootloader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器51还可以用于暂时地存储已经发送或者将要发送的数据。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。

所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、电载波信号、电信信号以及软件分发介质等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使对应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。