CN212675544U - Mcu自动构建和自动测试系统 - Google Patents

Abstract

一种MCU自动构建和自动测试系统，包括：第一上位机、开发板、测试设备以及串口、第二上位机，其中：所述第一上位机，与所述开发板耦接，适于烧录待测试程序至所述开发板，并承载SDK软件包的自动构建任务；所述开发板，与所述第一上位机、串口、所述测试设备均耦接，适于在所述第一上位机的触发下执行所述待测试程序，并将测试结果输出至所述串口；所述串口，与所述开发板以及所述第二上位机耦接，串联所述开发板与所述第二上位机；所述第二上位机，适于接收所述测试结果；所述测试设备，适于与所述开发板进行数据交互。上述方案能够自动编译源代码和自动构建开发环境，并提高对待测试程序进行测试的效率。

Description

MCU自动构建和自动测试系统

技术领域

本实用新型涉及软件编译及软件测试领域，尤其涉及一种MCU自动构建和自动测试系统。

背景技术

目前，MCU的外设越来越多，所需的功能也越来越复杂，导致外设例程的数量大大增加。对于一个功能强大的MCU而言，其可能会支持数十个甚至上百个例程。

现有技术中，通常通过开发人员编写对应的例程。而对于同一个MCU而言，它的所有例程的开发环境参数都是一致的，开发人员完全不必一一手动搭建环境。并且在完成例程的编写之后，为确定例程能够实现所需的功能，还需要开发人员或测试人员对例程进行测试。在对例程进行测试时，通常是采用手动的方式对例程进行单独的测试，存在效率低下的问题。

实用新型内容

本实用新型解决研发实施过程中，手动编译程序和手动生成测试程序并进行测试的低效率问题。

为解决上述问题，本实用新型提供一种MCU自动构建和自动测试系统，包括：第一上位机、开发板、测试设备以及串口、第二上位机，其中：所述第一上位机，与所述开发板耦接，适于将待测试程序烧录至所述开发板，并承载SDK软件包的自动构建任务；所述开发板，与所述第一上位机、串口、所述测试设备均耦接，适于在所述第一上位机的触发下执行所述待测试程序，并将测试结果输出至所述串口；所述串口，与所述开发板以及所述第二上位机耦接，串联所述开发板与所述第二上位机；所述第二上位机，适于通过串口接收所述测试结果并确认测试是否通过；所述测试设备，适于在所述开发板输出的测试信号的控制下与所述开发板进行数据交互。

可选的，通过有序组织源代码的文件目录，配合Python和SCons工具，实现自动化编译源代码和自动化构建开发环境的功能。

可选的，所述测试设备，还适于与所述开发板进行双向数据通信，用以验证所述待测试程序的数据交互功能。

可选的，所述待测试程序为基于Python脚本和SCons自动构建工具所生成的开发板的SDK软件开发包。

可选的，所述自动测试系统还包括：提示装置，与所述第二上位机耦接，适于接收所述第二上位机输出的测试结果并输出相应的提示信息。

可选的，所述串口为USB CDC串口。

与现有技术相比，本实用新型的技术方案具有以下优点：

根据组织有序的源代码目录，自动将源代码编译成待测试程序或构建源代码开发环境。通过第一上位机将待测试程序烧录至开发板，开发板在测试设备输出使能信号的控制下执行待测试程序并将测试结果输出至串口。与串口连接的第二上位机可以接收测试结果，进而确定待测试程序对应的功能是否正常实现。通过上述自动构建和自动测试系统，无需人工参与编译和测试，因此能够提升开发程序效率和测试程序效率。

附图说明

图1是本实用新型实施例中的一种自动测试系统的结构示意图；

图2是本实用新型实施例中的一种系统结构目录示意图；

图3是本实用新型实施例中的一种自动生成待测试程序的流程示意图。

具体实施方式

现有技术中，为确定例程能够实现所需的功能，还需要开发人员或测试人员对例程进行测试。在对例程进行测试时，通常是采用手动的方式对例程进行单独的测试，存在效率低下的问题。

在本实用新型实施例中，通过第一上位机将待测试程序烧录至开发板，开发板在第一上位机的控制下执行待测试程序并将测试结果输出至串口。与串口连接的第二上位机可以接收测试结果，进而确定待测试程序对应的功能是否正常实现。通过上述自动测试系统，无需人工参与测试，因此能够提升开发程序效率和测试程序效率。

为使本实用新型的上述目的、特征和优点能够更为明显易懂，下面结合附图对本实用新型的具体实施例做详细的说明。

在对本实用新型实施例提供的自动构建和自动测试系统进行详细说明之前，先对本实用新型涉及到的一些基础概念进行说明。

在实际应用中可知，Python是一种高级的、面向对象的脚本语言，它具有免费开源、易学习、易维护、可移植、跨平台的特点，是一种同时兼顾简单与功能强大的编程语言。Python适用于大型项目或小型的一次性程序(称为脚本)。

SCons是一个用Python写的自动化构建工具(构建工具是一种软件，它可以根据一定的规则或指令，配合编译器、汇编器、链接器等将源代码编译成可执行的二进制程序)，从构建这个角度来说它跟GNU make是同一类的工具。它是一种改进，是GNU make的替代工具。SCons是一个更简便，更可靠、更高效的编译软件。由于SCons使用Python语言编写的，所以可以通过Python脚本的方式来控制编译选项。

GCC编译器是Linux下默认的C/C++编译器，GCC编译器通常以Linux命令的形式在终端(Shell)中使用。它是一款优秀的、开源的编译器套件，通过命令行的方式控制编译过程。

Keil提供了包括C编译器、汇编器、链接器和一个功能强大的仿真调试器等在内的完整开发方案，通过一个集成开发环境(uVision)将这些部分组合在一起。Keil最初面向C8051内核单片机开发，2005年被ARM公司收购，支持ARM内核芯片开发。其方便易用的集成环境、强大的软件仿真调试工具令ARM嵌入式开发人员事半功倍。

IAR是全球领先的嵌入式系统工具和服务供应商IAR Systems发布的带有C/C++编译器和调试器的集成开发环境(IDE)。以其高度优化的编译器而闻名。每个C/C++编译器不仅包含一般全局性的优化，也包含针对特定芯片的低级优化，以充分利用芯片的所有特性，确保较小的代码尺寸。

可以理解的是，本实用新型可以移植至其他开发平台，说明书不一一展开进行叙述，实现过程和步骤类似。

本实用新型实施例提供了一种自动测试系统，参照图1。

在本实用新型实施例中，自动测试系统可以包括：第一上位机11、开发板12、测试设备15、串口13以及第二上位机14。

在具体实施中，第一上位机11可以与开发板12耦接，适于将待测试程序烧录至开发板12。具体而言，第一上位机11与开发板可以通过USB连接，也可以通过UART串口连接，还可以通过其他类型的接口或串口连接。将第一上位机11与开发板12连接的主要目的是将待测试程序烧录至开发板12。

在具体应用中，开发人员可以在第一上位机11上进行程序开发，在第一上位机11上生成待测试程序。

下面对本实用新型实施例中生成待测试程序的步骤进行说明，上述生成待测试程序的步骤可以在第一上位机11中实现。

在本实用新型实施例中，可以采用SDK自动构建单元来生成待测试程序。SDK自动构建单元可以运行在第一上位机11中。SDK自动构建单元可以包括源代码单元以及自动构建单元。源代码单元可以包含芯片的外设例程源代码，例如*.c文件和*.h文件。

自动构建单元，可以在源代码单元的基础上，使用Python脚本和SCons自动构建工具生成软件开发包，实现对外设例程的自动编译，便于排错。此外，还可以一键生成所有例程的Keil或IAR工程，方便使用IDE环境进行开发。

参照图3，给出了本实用新型实施例中的一种自动生成待测试程序的流程示意图。

步骤301，选择工作模式，可选直接编译模式或构建工程模式。

步骤302，判断是否直接进行编译。若直接进行编译，则可以执行步骤303；若不进行编译，则执行步骤306。

步骤303，获取源文件。

在具体实施中，源文件可以为*.c文件、*.h文件等。

步骤304，生成可执行文件。

在具体实施中，所生成的可执行文件可以为Hex格式的文件或者Bin格式的文件。

步骤305，判断是否所有外设例程(图2Peripheral x文件夹内)都分别编译完成。若是，则结束操作流程；若否，则重新执行步骤303。

步骤306，判断是否构建工程(使用IDE)。若判断构建工程，则执行步骤307；若无需构建工程，则结束操作流程。

步骤307，获取源文件。

在具体实施中，源文件可以为*.c文件、*.h文件等。

步骤308，生成Keil或IAR工程。

步骤309，判断是否所有外设例程(图2Peripheral x文件夹内)都分别构建完成。若是，则结束操作流程；若否，则重新执行步骤307。

上述步骤为实现自动构建软件开发包的步骤。在自动构建完成软件开发包的基础上，虽然能够实现源代码编译通过，但是并不一定能够确保每个例程的功能都能够正常实现。因此，在本实用新型实施例中，可以将所生成的待测试程序烧录至开发板12上运行，以实现对待测试程序代码正确性的验证。

可以理解的是，还可以采用现有的编程方式生成待测试程序，本实用新型实施例不做赘述。

在具体实施中，开发板12可以与第一上位机11、串口13以及测试设备15均耦接。具体的，开发板12可以包括数据输入端口、使能输入端口、输出端口，其中：开发板12的程序下载端口可以与第一上位机11耦接，接收第一上位机11输出的待测试程序；开发板12的使能输入端口可以与测试设备15耦接，接收测试设备15输出的使能信号；开发板12的输出端口可以与串口13耦接，开发板12在接收到第一上位机11使能信号后触发对待测试程序进行测试的操作，从而得到测试结果并输出至串口13。

在具体实施中，开发板12在接收到使能信号后，即可对其中烧录的待测试程序进行测试。对待测试程序进行测试，可以是对待测试程序的运行进行测试，以及对待测试程序所能实现的功能进行测试。在得到相应的测试结果后，开发板12将测试结果输出至串口13。

在具体实施中，串口13可以串联在开发板12与第二上位机14之间，也即第二上位机14与开发板12通过串口13进行数据传输。串口13可以为USB CDC串口，也可以为其他类型的串口，只要能够实现第二上位机14与开发板12之间的正常通信即可，本实用新型实施例不做赘述。

在具体实施中，第二上位机14在接收到测试结果之后，即可获知对待测试程序的测试结果是测试通过还是测试失败。为提醒测试人员，自动测试系统还可以包括提示装置，提示装置可以与第二上位机14耦接。第二上位机14可以将测试结果输出至提示装置，提示装置可以根据测试结果输出对应的提示信息。

例如，当测试结果为测试通过时，提示装置通过语音的方式提示待测试程序测试通过；当测试结果为测试错误时，提示装置通过语音的方式提示待测试程序为测试失败。

可以理解的是，提示装置提示测试结果的实现方式还可以包括其他方式，具体的如何进行测试结果的提示并不对本实用新型实施例所要保护的范围造成限制。

在具体实施中，测试设备15可以与开发板12的使能输入端口耦接。测试设备15可以输出使能信号至开发板12，开发板12在接收到使能信号后执行对待测试程序的测试操作。

在本实用新型实施例中，测试设备15可以自动生成使能信号并输入至开发板12。在本实用新型一实施例中，设置测试设备15生成使能信号的周期，周期性的触发使能信号的生成。

测试设备15也可以在接收到外部信号的触发后生成使能信号。例如，在接收到测试人员输入的触发指令时生成使能信号。

测试设备15生成使能信号的具体实现方式还可以包括其他方式，并不仅限于上述举例示意。

在具体实施中，开发板12还可以包括通信端口。测试设备15还可以与开发板12进行数据通信，以对待测试程序的功能进行测试。测试设备15还可以接收开发板12输出的与数据通信对应的结果，以获知待测试程序是否能够实现所要实现的功能。

在具体实施中，第一上位机11中可以存储有多个待测试程序。当完成对一个待测试程序的测试后，第一上位机11可以选择下一个待测试程序并烧录至开发板12中，以使得开发板12能够自动对下一个待测试程序进行测试。

在本实用新型实施例中，第二上位机14还可以与测试设备15、第一上位机11连接。第二上位机14在获知当前待测试程序测试通过时，可以向测试设备15发送触发指令，并向第一上位机11反馈测试结果为测试通过。第一上位机11在获知测试结果为测试通过后，将下一个待测试程序烧录至开发板12中。测试设备15在接收到触发指令时生成对应的使能信号，从而使得开发板12对下一个待测试程序进行测试。经过上述过程，可以实现对多个待测试程序的批量测试。

在具体实施中，第一上位机11与第二上位机14可以为同一个上位机，也可以为不同的上位机。

下面通过举例对本实用新型实施例中提供的自动测试系统以及待测试程序的构建进行说明。

参照图2，给出了本实用新型实施例中的一种为实现自动构建所约定的系统结构目录示意图。

由图2可知，Examples目录结构主要由以下四种组成：CMSIS、Template、Drivers、Example、Function。其具体作用描述如下：

CMSIS(Cortex Microcontroller Software Interface Standard，Cortex^TM微控制器软件接口标准)，是ARM公司对Cortex系列内核提供的一个标准软件接口，使用CMSIS，可以为处理器和外设实现一致且简单的软件接口，从而简化软件的重用、易于软件在各个平台的移植。在这个文件夹内的文件主要由ARM提供，另外还包括SCons工具的配置文件SConscript。

Template(工程模板)，在这个文件夹内存放Keil和IAR工程模板和SCons编译的配置文件。所有例程的工程都是以此模板为蓝本再加上各自的源文件而来的，这就保证了生成的每个例程的环境配置是一致的。

工程模板也是一个Keil或IAR工程，不同之处在于，它是一个不包含任何文件和参数的空白工程。每一个Keil或IAR工程都是在复制工程模板的基础上再添加必要的文件和参数而来的。工程模板及Keil或IAR工程都是一个xml文件，所以新建一个工程就是在工程模板的xml文件基础上按照规范添加内容即可。

Tools(工具)，在这个文件夹内存放必要的Python脚本，主要用于自动把可执行文件下载到芯片，并根据芯片返回状态码判断是否测试成功。

Drivers(驱动库)，这个文件夹内存放芯片的外设库文件(*.h和*.c文件)，它们是紧靠芯片底层(寄存器层)的一层，方便应用开发人员调用。另外还包括SCons工具的配置文件SConscript。

Peripheral(外设)，这个文件夹内存放具体的外设例程，比如定时器、串口、系统控制器等等，每个外设的所有演示都存放在同一个文件夹内，因此就会有多个外设文件夹。

Function(功能)，对于一个具体的Peripheral(外设)，可能具有很多功能，如定时器不仅可以用于定时，也可以用于输出波形。因此把每一个主要功能都单独做在一个文件夹内，方便用户使用。对于每一个Function，用户可能会习惯于使用两种不同开发平台，分别是Keil、IAR，为每一个平台分别用一个文件夹单独放置。但是不管用户使用哪种平台，Inc和Src文件夹内的文件都是公用的。在Src文件夹内除了源代码文件*.c外还包括SCons工具的配置文件SConscript。Function文件夹下的SConscript和SConstruct文件是SCons构建工具的配置文件。

根据以上的目录结构和所需的文件，接下来我们就可以进行构建和测试了，具体操作过程如下：

1)撰写SConstruct内容，配置编译环境及编译参数，指定工具链和所需的目标文件格式。

2)除了Function目录下的SConscript文件外，其它的SConscript文件主要功能是：包含当前文件夹内的所有源文件并且根据需要给这些源文件指定一个分组，这个分组就是构建工程时的分组。其它的SConscript文件是被Function目录下的SConscript调用的。

3)切换到SConstruct文件所在目录，控制台执行SCons命令。若一切正常就会自动生成可执行文件，可以下载到芯片运行。另外还可以添加其它命令到SCons，以实现特色功能，如SCons--target＝IAR自动生成IAR工程。

4)调用Python脚本配合上位机软件把生成的Hex或Bin文件下载到芯片运行，通过串口读取芯片执行结果，如果成功则继续下载下一个程序，依次操作。如果失败则发出提示，由开发人员排错。

综上可见，通过第一上位机将待测试程序烧录至开发板，开发板在测试设备输出使能信号的控制下执行待测试程序并将测试结果输出至串口。与串口连接的第二上位机可以接收测试结果，进而确定待测试程序对应的功能是否正常实现。通过上述自动测试系统，无需人工参与测试，因此能够提供测试效率

虽然本实用新型披露如上，但本实用新型并非限定于此。任何本领域技术人员，在不脱离本实用新型的精神和范围内，均可作各种更动与修改，因此本实用新型的保护范围应当以权利要求所限定的范围为准。

Claims (4)

1.一种MCU自动构建和自动测试系统，其特征在于，包括：第一上位机、开发板、测试设备以及串口、第二上位机，其中：

所述第一上位机，与所述开发板耦接，适于烧录待测试程序至所述开发板，并承载SDK软件包的自动构建任务；

所述开发板，与所述第一上位机、串口、所述测试设备均耦接，适于在所述第一上位机的触发下执行所述待测试程序，还适于与所述测试设备进行数据交互，并将测试结果输出至所述串口；

所述串口，与所述开发板以及所述第二上位机耦接，串联所述开发板与所述第二上位机；所述第二上位机，适于通过串口接收所述测试结果并确认测试是否通过；

所述测试设备，适于在所述开发板输出的测试信号的控制下与所述开发板进行数据交互。

2.如权利要求1所述的MCU自动构建和自动测试系统，其特征在于，所述测试设备，还适于与所述开发板进行双向数据通信，用以验证所述待测试程序的数据交互功能。

3.如权利要求1所述的MCU自动构建和自动测试系统，其特征在于，还包括：提示装置，与所述第二上位机耦接，适于接收所述第二上位机输出的测试结果并输出相应的提示信息。

4.如权利要求1所述的MCU自动构建和自动测试系统，其特征在于，所述串口为USB CDC串口。

Images