一种开放式驱动器软件平台的制作方法

本发明涉及应用软件和驱动软件的平台系统领域，特别是驱动器的开放式驱动器软件平台。

背景技术：

如图1所示，各类驱动器产品(如变频器、交流伺服驱动器等)等，均没有对第三方用户提供二次开发接口与程序、变量空间。对于第三方用户在遇到需要专用功能时，只能通过上位机(如各类电脑，嵌入式板卡、plc等)实现工艺控制程序，或委托驱动器厂家开发专用程序。

(1)由于各类驱动器应用非常广泛，各种应用对驱动器功能的差异化要求也非常多，全部交由驱动器厂商去开发各种专用机，对于厂商来说将需要配备不少应用开发工程师，人员投入费用很大；

(2)专用机的开发需要对现场应用非常熟悉，厂商应用软件开发工程师刚接触这些行业应用时也是很陌生，整个开发周期可能会较长，甚至可能最后实现出来的功能与实际要求不符；

(3)由第三方采购各类plc、触摸屏等上位机程序进行开发，通过通信与驱动器进行控制与交互，增加大量成本，通信的实时性得不到保证，在需要实时性要求高的场合有局限性。

技术实现要素：

该驱动器软件系统的发明，是实现各类驱动器，如变频器、伺服驱动器等产品的应用软件和驱动软件的平台系统。同时，在此软件平台上，提供了第三方用户实施二次开发接口、程序空间和变量空间，以便第三方用户二次开发，实现各种专用扩功能，是通过如下技术方案实现的。

一种开放式驱动器软件平台，包括扩展应用程序空间、扩展应用接口、基础功能程序模块、底层核心驱动算法模块，其中，

所述扩展应用程序空间划分为多个空间；

第三方开发的扩展应用程序放置在扩展应用程序空间的存储扇区内，变量放置在相应的ram区；

第一次烧录标准程序由芯片厂商烧录，第二次烧录采用第三方的扩展应用程序通过扩展应用接口执行烧录。

进一步的，所述扩展应用程序空间的核心驱动存储器扇区和标准应用程序存储器扇区和第三方应用程序接口由驱动器厂商研发定制，驱动器厂商按照特定的协议提供标准应用程序和第三方应用程序交互的接口，第三方开发的扩展应用程序放置在相应存储扇区内，变量放置在相应的ram区。

进一步的，在现有mcu方案下通过对mcu片上flash及ram进行划分，提供各模块的程序存储空间及ram空间flash空间划分，将程序空间分成3部分：底层核心驱动程序空间、标准驱动器应用程序空间及第三方二次开发应用程序空间。

进一步的，flash空间划分，将ram空间同样也分成三部分：底层核心驱动程序变量空间、标准驱动器应用程序变量空间；及第三方二次开发应用程序变量空间。

进一步的，烧录工具能够在烧录第三方应用程序hex文件或bin文件时自动解锁和再次加密芯片。

本发明的有益效果是：省去了plc等上位机设备，降低成本、节省时间，第三方用户可以使产品应用更为广泛。

附图说明

图1是传统模式与开放式软件平台对比示意图。

图2是开放式软件平台结构图。

图3是存储空间地址分布及按功能模块划分示意图。

图4是扩展应用程序调用流程图。

图5是标准应用程序传递给扩展应用程序侧变量交互示意图。

图6是扩展应用程序传递给标准应用程序侧变量交互示意图。

图7是程序烧录流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图2所示，开放式驱动器软件平台，包括扩展应用程序空间、扩展应用接口、基础功能程序、底层核心驱动算法，其中，

所述扩展应用程序空间划分为多个空间；

第三方开发的扩展应用程序放置在扩展应用程序空间的存储扇区内，变量放置在相应的ram区；

烧录时，通过扩展应用接口执行烧录，第一次烧录标准程序通过芯片厂商的专用烧录工具烧录，第二次烧录采用第三方用户的应用程序烧录工具

如图2所示，核心驱动存储器扇区和标准应用程序存储器扇区和第三方应用程序接口由驱动器厂商研发定制，即图中扩展应用接口②、基础功能程序模块③、底层核心驱动算法模块④部分由驱动器厂商研发定制。驱动器厂商按照特定的协议提供标准应用程序和第三方应用程序交互的接口，第三方开发的扩展应用程序放置在相应存储扇区内，变量放置在相应的ram区，方便第三方用户二次开发。可以通过在现有mcu方案下通过对mcu片上flash及ram进行划分，提供各模块的程序存储空间及ram空间，也可以通过定制芯片实现相应功能。

在实施案例中，所使用芯片flash及ram存储空间地址分布及按功能模块划分，如图3所示。

1.flash空间和ram空间的划分。

将程序空间分成3部分：

①.sectorf、sectorg和sectorh作为底层核心驱动程序空间；

②.sectorc、sectord和sectore作为标准驱动器应用程序空间；

③.sectora和sectorb作为第三方二次开发应用程序空间。

将ram空间同样也分成3部分：

①.l3saram(length＝0x1000)作为底层核心驱动程序变量空间；

②.l0、l1和l2saram作为标准驱动器应用程序变量空间；

③.m0和m1saram作为第三方二次开发应用程序变量空间。

2.扩展应用程序接口实现，如图5所示：

(1)程序调用，扩展应用程序在标准应用程序中的调用流程如图所示，存储在第三方二次开发应用程序空间sectora，执行扩展应用程序“exfuneif”，在sectorb拓展应用程序返回。

(2)变量交互

标准应用程序侧变量信息传递给扩展应用功能侧实现方式，如图5所示。

通过芯片配置文件及预处理指令#pragmadata_section(extfpi,".bs2ext")，将指针变量地址分配至指定地址：

(uint16*)extfpi.var1指针变量地址:0x040(占2个word空间)；

(uint16*)extfpi.var2指针变量地址:0x042(占2个word空间)；

……

(uint16*)extfpi.var32指针变量地址:0x07e(占2个word空间)。

由于事先已约定好地址空间，标准应用程序侧宏定义:

#definebs2dexports(i)(0x040+(i<<1))

通过初始化函数bs2extprtinit()，标准应用程序侧将交互变量的地址分别赋值给扩展应用程序侧的结构体里的指针成员，指针指向了交互的变量地址，第三方程序只需要读取指针变量指向的地址的内容即可获取标准应用程序侧发送给扩展应用程序的信息。

扩展应用程序侧变量信息传递给标准应用程序侧实现方式，如图6所示。

扩展应用程序侧通过芯片配置文件以及预处理指令

#pragmacode_section(ex2bsvar,".ex2bs")，

将扩展应用程序侧传递给标准应用程序侧的变量地址放置在指定地址：

&exfunvar1放置在0x3e8004(占2个word空间)；

&exfunvar2放置在0x3e8006(占2个word空间)；

……

&exfunvar32放置在0x3e80042(占2个word空间)

由于事先已经约定好地址空间，在标准应用程序侧宏定义

#defineex2bsports(i)(0x03e8004+(i<<1))，

由于事先约定好0x03e8004存放的是&exfunvar1,0x03e8006存放的是&exfunvar2,以此类推，通过的初始化函数ex2bsprtinit()，将扩展应用程序侧要发送给标准应用程序侧的变量地址赋值给标准应用程序侧的指针变量，标准应用程序侧通过指针即可获取扩展应用程序侧发送的变量内容，在两个独立的开发工程下，最终产生的两个烧录文件，分布烧录指定区域，根据约定好的地址实现数据准确交互。

如图7所示，程序开发及烧录流程：程序烧录分两部分，厂家第一次烧录标准程序通过芯片厂商专用烧录工具烧录。为了方便第三方应用程序烧录，额外开发了用于第三方应用程序烧录工具。烧录流程如图7所示。厂家烧录工具具体原理不属于该发明范围，不再作过多说明。烧录工具能够在烧录第三方应用程序hex文件或bin文件时自动解锁和再次加密芯片，他人不再容易破解和抄袭，对知识产权实施保护。

结合上述三个步骤，实现了第三方用户的二次开发接口。方便用户在标准驱动器产品上开发和实现差异化功能。

本发明的有益效果在于：

(1)对于第三方用户通过二次开发接口，实现专用功能，省去了plc等上位机设备，降低成本。同时节省各种时间，更能及时满足客户的各种需求。

(2)对于代理商，在备货时，只需备标准产品即可，通过厂家实现的各种专用机，只需要厂家提供烧录工具和烧录文件即可。节省了备货量，也就节省了资金的压滞。

(3)对于驱动器厂商，节省了大量人员费用，具备一定技术开发实力的第三方用户就是最佳应用开发工程师，使产品应用更为广泛，极大提高产品销售量。