单片机开发平台的制作方法

本发明涉及通信领域，具体而言，涉及一种单片机开发平台。

背景技术：

目前，单片机的软件开发多是在windows下采用专用集成开发环境(integrateddevelopmentenvironment，简称ide)来进行开发的，ide的图形界面操作方便快捷，非常适合初学者的使用，但是其编译速度慢，适应性低，如果更换单片机类型，可能就要重新搭建开发环境，且要移植所有项目代码。这样会极大的降低软件开发效率并且后期的维护成本也会较高。

此外linux的开发环境尤其是各种开源的工具的使用是整个嵌入式行业的一个趋势。对于熟悉linux系统的开发人员来说也更倾向于选择gnu编译器套装(gnucompilercollection，简称gcc)这种命令行工具来进行编程。其适应性强，编译效率高，且可以自由的组合使用各类工具，配合makefile、脚本等，更容易实现自动化编译及项目管理。本软件平台支持在linux服务器上进行开发和使用，配合脚本及其他配置文件的使用，可实现项目自动化管理。

关于软件架构方面，目前单片机软件开发还没有统一的一种架构模式，单片机的软件系统结构比较混乱，缺乏规范性、通用性，往往一个小小的需求变动就会导致大量代码的变动。目前，提及最多的嵌入式软件架构是采用模块化方式，根据不同的应用划分为不同的模块，每个模块可独立开发，增加了模块开发的协同性，但是模块代码格式、模块之间的耦合性以及模块的可配置性缺乏规范及很好的应用，且外部设备驱动及应用模块并没用真正做到硬件无关性。

目前存在的单片机软件系统都不能同时支持多种类型单片机，不能在一个系统上同时进行多种类型单片机的开发，当不同类型的单片机需要使用相同的应用模块时，就需要将模块代码重新复制移植一份，这无形中就增加了人力、时间及代码维护成本。

在调试手段方面，目前单片机比较常用的调试手段是利用仿真器在线仿真调试，通过仿真器跟踪可直观全面地看到单片机内部程序的运行情况，可大大缩短开发调试的时间，但是仿真器的使用可能会受到环境的限制，如某些开发pc不提供连接仿真器的接口或在产品使用故障现场不便使用仿真器定位问题，且仿真器还会占用目标板的一些软硬件资源等。

通过上述可以看出目前单片机嵌入式软件开发缺少统一的平台开发架构，造成开发混乱、人力成本过高等问题。

针对相关技术中的上述技术问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种单片机开发平台，以至少解决相关技术中单片机嵌入式软件开发缺少统一的平台开发架构的问题。

根据本发明的一个实施例，提供了一种单片机开发平台，包括：arch层，操作系统层和单板配置层；其中，arch层用于存储两种以上类型的单片机的控制器对应的软件，其中，每种类型的单片机的控制器对外输出统一的接口封装格式；操作系统层，用于存放运行单片机所需要的操作系统的信息；单板配置层，用于配置单片机的信息。

可选地，arch层还包括：arch接口，其中，该arch接口包括与控制器的核对应的接口和控制器的内部设备控制器的接口。

可选地，单片机开发平台还包括：驱动层和应用层；其中，驱动层用于存放外部设备的驱动程序；应用层用于存储应用程序。

可选地，单片机开发平台还包括：中间层，其中，中间层位于驱动层和应用层之间，中间层包括：串口命令行机制模块，用于解析响应各种串口命令，以利用解析的串口命令调试单片机。

可选地，串口命令行机制模块还用于利用解析的串口命令开启或关闭模块化打印功能。

可选地，串口命令行机制模块包括命令解析器，其中，命令解析器用于接收用户终端输入的命令，根据预先存储的命令索引表查找与命令对应的处理函数，依据与命令对应的处理函数执行对应的功能；其中，命令索引表中存放有多个命令与多个处理函数的对应关系。

可选地，中间层还包括：hal接口，用于隔离驱动层和应用层。

可选地，中间层还包括：内存管理模块，用于对内存进行扩展管理。

可选地，内存管理模块，还用于对内存的使用情况和故障情况进行检测。

可选地，驱动层还包括标准应用程序编程接口(applicationprogramminginterface，简称api)接口，其中，api接口用于对预先存储的设备列表中的设备进行操作。

可选地，单片机开发平台，还包括：项目特有接口层，其中，项目特有接口层用于对同一个项目中多个单板公有的接口进行分类和配置。

可选地，单板配置层，还用于存放同一个项目中多个单板存在差异的程序。

通过本发明，由于提供了一种单片机开发平台，在该平台中包括arch层，该arch层用于存储两种以上类型的单片机的控制器对应的软件，其中，每种类型的单片机的控制器对外输出统一的接口封装格式，进而可以使得提供的单片机开发平台可以同时支持多种类型的单片机，具有很强的通用性，实用性和可移植性，因此，可以解决相关技术中单片机嵌入式软件开发缺少统一的平台开发架构的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的单片机开发平台的架构图；

图2是根据本发明优选实施例提供的软件架构的示意图；

图3是根据本发明优选实施例提供的arch层的软件结构示意图；

图4是根据本发明优选实施例提供的软件平台的设备驱动模型图；

图5是根据本发明优选实施例提供的hal层接口示意图；

图6是根据本发明优选实施例提供的命令解析器机制的示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

实施例1

在本实施例中提供了一种单片机开发平台，图1是根据本发明实施例的单片机开发平台的架构图，如图1所示，该单片机开发平台包括：arch层12，操作系统层14和单板配置层16；其中，arch层12用于存储两种以上类型的单片机的控制器对应的软件，其中，每种类型的单片机的控制器对外输出统一的接口封装格式；操作系统层14，用于存放运行单片机所需要的操作系统的信息；单板配置层16，用于配置单片机的信息.

通过本发明实施例提供的一种单片机开发平台，在该平台中包括arch层，该arch层用于存储两种以上类型的单片机的控制器对应的软件，其中，每种类型的单片机的控制器对外输出统一的接口封装格式，进而可以使得提供的单片机开发平台可以同时支持多种类型的单片机，具有很强的通用性，实用性和可移植性，因此，可以解决相关技术中单片机嵌入式软件开发缺少统一的平台开发架构的问题。

需要说明的是，上述操作系统层贯穿于整个软件系统中，是整个软件系统运行的基础，可以提供任务管理、时间管理、信号量、消息列队和内存管理等功能，但并不限于此，上述操作系统层可以是嵌入式操作系统，但并不限于此。

需要说明的是，上述操作系统层可以与上述arch层和上述单板配置层进行交互，比如可以调用arch层和/或上述单板配置层中存放的程序，但并不限于此。

在本发明的一个实施例中，上述arch层还可以包括：arch接口，其中，该arch接口包括与控制器的核对应的接口和控制器的内部设备控制器的接口。

需要说明的是，上述arch口对外输出一个arch.h头文件，所有相关的定义都放在这个头文件里，移植一个新的控制器到单片机分支，首先要创建的是这个头文件，arch目录下以控制器的核进行区分，每种架构下应该有一个core目录，然后，每个/类芯片应该有一个独立的目录。

在本发明的一个实施例中，上述单片机开发平台还包括：驱动层和应用层；其中，驱动层用于存放外部设备的驱动程序；应用层用于存储应用程序。

需要说明的是，驱动层还包括api接口，该api接口用于对预先存储的设备列表中的设备进行操作。

需要说明的是，上述api接口可以是虚拟化文件操作接口，比如openclosereadwriteioct1等五个接口，但并不限于此。

需要说明的是，上述应用层可以采用模块化设计，模块代码都放在模块目录下，每个目录代表一个模块，模块里可以调用单片机平台中其他层的任何接口，也可以调用该应用层中其他模块的对外接口，每个模块可以对应输出一个设计、使用说明文档。

在本发明的一个实施例中，上述单片机开发平台还包括：中间层，其中，中间层位于驱动层和应用层之间，中间层包括：串口命令行机制模块，用于解析响应各种串口命令，以利用解析的串口命令调试单片机。

需要说明的是，上述串口命令行机制模块还可以用于利用解析的串口命令开启或关闭模块化打印功能。

需要说明的是，该模块化打印功能可对应一个模块化打印接口，在接口上电时，该功能被关闭，在需要的时候，通过命令开启和/或关闭。需要说明的是，上述模块化打印功能可以是针对模块的打印功能，即在该功能开启的情况下，可以针对模块打印一些信息，但并不限于此。

需要说明的是，上述串口命令行机制模块包括命令解析器，其中，命令解析器用于接收用户终端输入的命令，根据预先存储的命令索引表查找与命令对应的处理函数，依据与命令对应的处理函数执行对应的功能；其中，命令索引表中存放有多个命令与多个处理函数的对应关系。

通过上述串口命令行机制模块可以通过串口命令以及打印信息进行软件功能的调试及故障的定位，只需开发人员在编写代码时添加一些关键命令及调试打印接口即可，因而节省了大量的硬件资源，同时也节省了人力。

需要说明的是，中间层还包括：hal接口，用于隔离驱动层和应用层。

需要说明的是，中间层还包括：内存管理模块，用于对内存进行扩展管理。

需要说明的是，上述内存管理模块，还可以用于对内存的使用情况和故障情况进行检测。

在本发明的一个实施例中，上述单片机开发平台，还可以包括：项目特有接口层，其中，项目特有接口层用于对同一个项目中多个单板公有的接口进行分类和配置。通过该项目特有接口层可以简化项目单板开发的目的，便于统一管理和维护。

需要说明的是，上述单板配置层，还用于存放同一个项目中多个单板存在差异的程序。

需要说明的是，本发明实施例提供的单片机开发平台采用分层式软件架构的放肆，其可以使得整个软件系统具有很强的实用性、可扩展性、大大降低了软件开发及维护的时间，以及人力成本。

为了更好地理解本发明实施例，以下结合优选的实施例对本发明做进一步解释。

本发明优选实施例的宗旨在于提供一种基于嵌入式操作系统的单片机公共软件架构设计，此架构设计可同时支持多种类型单片机，具有很强通用性、实用性及可移植性。

开发环境方面，本软件平台支持在linux/unix的开发环境下进行单片机软件的开发。可以充分的利用各种开源的开发工具以实现高效的软件开发。

架构设计思想，本软件平台采用模块化思想进行设计，采用分层式软件架构，将外部设备驱动与应用程序真正做到与单片机硬件无关，每个驱动模块对外接口统一进行管理，并提供接口说明文档。并使用代码格式化工具，在编译代码时自动更改统一化代码格式。

兼容性方面，本软件平台将单片机芯片层独立出来，每种类型的单片机都对外提供统一的接口封装格式，既能完全适配硬件的特殊性，也可以隔离外部模块对物理差异的感知。这样外部模块不需要任何改动就可供不同单片机使用。

调试手段方面，本软件平台同时实现了一个系统级别的命令解析器，通过通用串口命令及一些打印信息即可进行软件功能的调试及故障的定位，只需开发人员在编写代码时添加一些关键命令及调试打印接口即可。

本发明优选实施例提供了一种基于嵌入式操作系统的单片机软件平台架构，所述的软件平台采用分层式软件架构进行设计，包括arch层、驱动层、中间层和应用层，以及贯穿整个软件系统的操作系统层、项目特有接口层和单板配置层。

所述的arch层是与单片机控制器相关的软件，包含的都是芯片厂商提供的软件接口，主要包括两部分，一部分是与控制器核相关的接口，如m0、m3核等，一部分是控制器内部设备控制器接口，如uart、iic等，每种控制器都对外输出统一的接口形式。

所述的驱动层主要由驱动程序和标准api接口组成。驱动程序对设备进行驱动，并通过注册的方式将驱动注册到驱动列表里。标准api接口为虚拟化文件操作接口openclosereadwriteioctl五个接口，通过这五个接口可以对设备列表里的设备进行操作。

所述的中间层包含一些通用模块和hal接口。其中通用模块主要包括内存管理和串口命令行机制模块。hal接口用来隔离应用层和驱动层。

所述的内存管理模块主要是在操作系统提供的内存管理策略的基础上对其进行特殊的扩展管理以适应不同的内存应用场景，同时启用一个守护任务对内存的使用情况及异常情况进行检测。

所述的串口命令行机制实现的是一个系统级别的命令解析器，可以解析响应各种串口命令，实现对系统的各种调试，并支持模块化打印功能。

所述的应用层是应用程序部分，采用模块化技术进行开发。

所述的操作系统层为嵌入式操作系统，如freertos，是整个软件系统运行的基础。提供任务管理、时间管理、信号量、消息队列、内存管理等功能。

所述的项目特有接口层为项目相关接口，设立项目独立接口层的目的，是为了将同一个项目中多个单板公有的接口提炼出来，并对其进行分类，且可配置，最终达到简化项目单板开发的目的，且便于统一管理和维护。

所述的单板配置层主要为单板配置代码及配置文件，可以配置单片机的信息、项目相关的信息、以及所支持的驱动和模块的信息等，编译脚本会根据这些配置信息对单板进行编译及版本构建等。

本软件平台采用分层式软件架构进行设计，其串口命令行机制、设备驱动模型、模块化技术开发以及单板可配置等的实现使整个软件系统具有很强的实用性、可扩展性，大大降低了软件开发及维护的时间及人力成本。

本发明优选实施例所述软件平台采用分层式软件架构进行设计，图2是根据本发明优选实施例提供的软件架构的示意图，如图2所示，包括arch层、驱动层、中间层、应用层、操作系统层、项目特有接口层和单板配置层。中间层可以包括：内存管理，hal，命令行机制，其他通用件等但并不限于此。

本发明优选实施例所述平台搭建及应用方法如下所述：

所述arch层存放的都是处理器相关的代码，arch接口基本都是来源于芯片厂商，主要包括两个部分，一部分为mcu核相关的接口，一部分为mcu内部设备控制器的接口，例如gpio、uart等，图3是根据本发明优选实施例提供的arch层的软件结构示意图，如图3所示。arch接口对外输出一个arch.h头文件，所有相关的定义都放在这个头文件里，移植一个新的mcu到单片机分支，首先要创建的就是这个头文件。arch目录下应该是以mcu核的架构进行区分，每种架构下应该有一个core目录，然后每个/类芯片应该有一个独立的目录。

所述驱动层存放的是外部设备驱动程序，如eeprom、spi等，为了最大化的公用代码，此软件系统设计了一个驱动模型，这个模型的思想来源于linux的驱动模型，不过对其进行了简化。整个驱动模型里最核心的是两张表，一张表为设备驱动索引表，另外一张为设备节点索引表，它们的关系如图4所示，图4是根据本发明优选实施例提供的软件平台的设备驱动模型图。设备驱动索引表的表项是一个结构体，这个结构体分为两部分，一部分是设备驱动的名称，是一个字符串，设备名称是这张表比对的唯一标示；第二部分是5个文件访问的标准接口，所有驱动代码对外都应该提供这个5个标准接口，且仅需要提供这5个标准接口。设备节点索引表的表项同样也是一个结构体，包含了设备驱动信息、设备私有数据等。通过提炼设备驱动中的关键数据，将那些和设备本身无关，但是会因为单板设计方式不同而改变的数据提炼出来，作为设备私有数据放到设备节点中去。例如一个eeprom的驱动，eeprom的容量、页大小、起始地址等信息就会因为硬件设计而改变，这些数据就应该提炼出来。

所述hal接口用来隔离应用层和驱动层。hal接口是对驱动层api接口的再次封装，对同一类型的多个设备进行预编号(贴上标签)，然后应用层在使用相应设备的时候，通过这个编号来进行调用，如图5所示，图5是根据本发明优选实施例提供的hal层接口示意图。

所述的内存管理模块主要采用操作系统提供的内存管理策略，并对其进行扩展，同时启用一个守护任务检测内存是否有越界的情况发生。

所述的串口命令行机制实现的是一个命令解析器，此命令解析器的核心是建立了一张命令索引表，这个表单里至少存放了命令关键字和处理函数的入口。当用户输入一个命令，只需要遍历这个表里的所有数据项，就可以找到相应的处理函数进行处理了，如图6所示，图6是根据本发明优选实施例提供的命令解析器机制的示意图。关于如何创建这张表，一般有两种方式：1.在编写代码时，创建一张静态表，将所有支持的命令都填到这张表里；2.在系统启动时，创建一张动态表，每个任务在启动的时候，将需要支持的命令注册进这张动态表；上述两种办法各有千秋，应用的场景也各不相同。但是对于一个要求可以裁剪的系统，方法1显然不适合，方法2虽然可以在可裁剪的系统里工作，但是却需要任务在初始化时进行注册，这对于驱动层和arch层来说是一个致命的问题，因为你不知道它们会在那个任务被使用，也不知道什么时候会被初始化，甚至有些小模块根本不需要初始化。为了寻求一种更好的办法来建立这张索引表，这里参考借鉴了u-boot里的命令行解决方案，索引表应该是由许多表项组成的，每一个表项代表着一个命令，将每个表项声明成一个结构体变量或者常量，而且各个表项的声明可以放到不同的目录中不同的c文件中，并不需要集中到一个数组里去，只需要用关键字__attribute__((section("xxx")))把它们定义到同一个数据段即可。我们的软件平台里用一个宏将这个表项的声明进行了封装，这样每添加一个新的命令时，用这个宏进行声明即可。这样，既不用手动在代码里去维护一张静态的索引表，也不用费事的在每个任务启动时去动态注册表项，只是利用了一下编译器、连接器的特性，就能动态的获取到一张静态索引表，从而满足在一个可裁剪的系统上进行开发的需求。此命令解析器还可支持模块化打印功能，模块化打印接口在上电时，一般都会被关闭，在需要的时候在串口终端通过命令实时开启和关闭，同样的模块化打印的机制也需要一张索引表，实现方式和命令索引表是一样的。

所述应用层采用的是模块化设计，模块代码都放在模块目录下，每个目录代表一个模块，模块里可以调用前面提到的任何接口，也可以调用其他模块提供的对外接口，每个模块都应该输出一个设计、使用说明文档。

所述操作系统层存放的是嵌入式操作系统相关代码，如freertos。

所述的项目特有接口层存放的是项目相关代码，将同一个项目，多个单板公有的接口提炼出来，并对其进行分类，且可配置。

所述的单板配置层存放的是各个单板有差异的代码和配置信息，可以配置单片机的信息、项目相关的信息、以及所支持的驱动和模块的信息等。

需要说明的是，单片机软件平台架构或者本软件平台，相当于上述实施例中的单片机开发平台。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。