【产品应用】用 AWTK 和 AWPLC 快速开发嵌入式应用程序 (4)- 自定义功能块（上）

 

AWPLC 是 ZLG 自主研发的 PLC 系统（兼容 IEC61131-3)，本文用定时器为例介绍一下如何扩展自定义功能块。

 背景

AWTK 全称 Toolkit AnyWhere，是 ZLG 开发的开源 GUI 引擎，旨在为嵌入式系统、WEB、各种小程序、手机和 PC 打造的通用 GUI 引擎，为用户提供一个功能强大、高效可靠、简单易用、可轻松做出炫酷效果的 GUI 引擎。

AWPLC 是 ZLG 自主研发的 PLC 系统（兼容 IEC61131-3)，其中 AWPLC 的运行时库 (Runtime) 基于 ZLG TKC 开发，可以移植到到任何主流 RTOS 和 嵌入式系统。AWPLC 的集成开发环境 (IDE) 基于 AWTK 开发，可以运行在 Windows、MacOS 和 Linux 系统之上。AWPLC 的主要目标之一是把 PLC 中低代码开发方法引入到嵌入式软件，从而提高嵌入式软件的开发效率和可靠性。

 简介

在前一篇文章中，我们说过，AWPLC 的重要特色之一就是高度可扩展，而且会内置 ZLG 多年在嵌入式系统开发中积累的功能块，包括各种算法、协议和实用功能，这将大大简化嵌入式软件的开发。

那怎么去开发自定义的功能块呢？本文以 ZTIMER 为例介绍一下开发自定义功能块的方法。ZTIMER 是一个带计数功能的定时器，在前一篇文章中，我们用它实现了一个走马灯的演示，其使用方法如下：

在 AWPLC 中，自定义功能块和内置功能块具有同等待遇，因为它们都是按同样的方式加入进来的。在进入正题前，我们先聊一下，系统的可扩展性以及实现方法。1. 可扩展性的好处在设计一个复杂软件的架构时，可扩展性是必须考虑的因素。可扩展性至少带来以下几个好处：

• 可扩展性将软件的框架与具体的实现分离开来，有助于降低系统的复杂度。系统的复杂性太高，会带来一系列的问题，比如让可理解性、可维护性和可靠性的降低，很多项目因此陷入无法挣脱的焦油坑里，最后士气低落，人员流失，项目取消，公司蒙受巨大损失。在设计复杂软件时，一定要存有敬畏之心；
• 可扩展性将软件变化的部分隔离开来，不但可以让扩展的功能独立变化，也可以方便的扩展新功能。在 AWPLC 中， 以后会扩展各种协议和算法的功能块，必须保证 AWPLC 框架和这些扩展的功能块是独立的，才能让开发工作顺利进行；
• 可扩展性有利于团队的协作。 不同的通讯协议和算法，需要不同团队的专家去开发，可扩展性让大家只要按相应的接口去实现，就可以方便的集成起来，不需要太多跨团队的交互。

2. 如何保证可扩展性

让软件系统具有可扩展性，通常并不是什么难事，只要做到下面两点就可以了：

• 针对接口编程。这个是大家都知道的，在《软件设计模式》等书里，都反复强调了，这里不再赘述；
• 利用工厂模式隔离组件的创建。工厂模式也是人人都知道的，而且大家都觉得很"简单"。但是能把工厂模式用好的程序员其实并不多见，一个主要原因就是很多人只会套用《软件设计模式》的工厂模式，而《软件设计模式》里几个工厂模式在现实中并不实用。利用这些这些工厂模式，无法满足 SOLID 原则中的开放封闭原则，增加一个新的扩展时，仍然需要修改对应的工厂。

 AWPLC 功能块的接口

要让 AWPLC 支持扩展各种自定义的功能块，首要条件条件是定义好功能块的接口。

1. 功能块的基类在面向对象的 C 语言编程中，我们用结构 (struct) 来模拟类和接口。这里所说的接口是广义的接口，而不是 C++或其它语言中只包含纯虚函数的 interface，因为除了虚函数指针外，这里还有一些数据成员。

/**
 * @class aw_plc_fb_t
 * AWPLC 功能块接口。
 */
struct _aw_plc_fb_t {
  /** 
   * @property {bool_t} en
   * 是否启用。
   */
  uint8_t en : 1;
  /** 
   * @property {bool_t} eno
   * 是否启用输出。
   */
  uint8_t eno : 1;

  /*private*/
  const aw_plc_fb_vtable_t* vt; 

};

2. 功能块的虚函数

在功能块的虚函数表中，还定义了一些描述性的常量，让对象具有一点反射的能力，方便在运行时查询它的一些状态。顺便说一下，在定义接口的虚函数时，通常不会有创建函数，因为创建之前对象之前，是拿不到这个虚表对象的。但也不是绝对的，有时为了方便 clone，也可能提供一个 clone 函数或者 create 函数。

任何接口都要定义析构函数 (destroy)，在对象需要销毁时，框架可以以统一的方式销毁它。

typedef struct _aw_plc_fb_vtable_t {
  /*功能块的类型名*/
  const char* type;
  /*输入参数名称列表，以 NULL 结束的字符串数组*/
  const char* const* ins;
  /*输出参数名称列表，以 NULL 结束的字符串数组*/
  const char* const* outs;
  /*输入输出参数名称列表，以 NULL 结束的字符串数组*/
  const char* const* in_outs;
  /*执行函数*/
  aw_plc_fb_exec_t exec;
  /*执行函数（带参数）*/
  aw_plc_fb_exec_ex_t exec_ex;
  /*获取属性（输入输出参数）的值*/
  aw_plc_fb_get_prop_t get_prop;
  /*获取输出的值*/
  aw_plc_fb_get_output_t get_output;
  /*设置输出的值*/
  aw_plc_fb_set_input_t set_input;
  /*析构函数*/
  aw_plc_fb_destroy_t destroy;

} aw_plc_fb_vtable_t;

* 这个虚函数表和 AWTK/TKC 中的 object 虚函数表很相似，考虑到 object 为了做得通用，有点臃肿了，所以决定重新定义一套。

 

 AWPLC 功能块的工厂

前面我们说过，可扩展性除了针对接口编程外，离不开工厂模式的支持。功能块的工厂其任务当然是创建功能块了，所以提供了一个创建功能块的函数。参数 type 指定功能块的类型，函数返回对应类型的功能块：

/**
 * @method aw_plc_fb_factory_create_fb
 * 创建 fb。
 * @param {const char*} type 类型。
 *
 * @return {aw_plc_fb_t*} 返回 fb 对象。
 */

aw_plc_fb_t* aw_plc_fb_factory_create_fb(const char* type);

有了这个创建函数，确实把创建任务与功能块的实现分开了。但是请想一下，如果每次增加新的功能块，都要修改这个创建函数，而这个函数又属于框架的一部分，框架是不是还是依赖于具体实现了呢？为了解决这个问题，我们需要提供一种注册机制来实现依赖倒置，让功能块的实现者主动将创建函数注册进来：

/**
 * @method aw_plc_fb_factory_register
 * 注册创建函数。
 * @param {const char*} type 类型。
 * @param {aw_plc_fb_create_t} create 创建函数。
 *
 * @return {ret_t} 返回 RET_OK 表示成功，否则表示失败。
 */

ret_t aw_plc_fb_factory_register(const char* type, aw_plc_fb_create_t create);

这种机制非常好用，真正满足了 SOLID 原则中的开放封闭原则 (OCP)：扩展新的功能无需修改框架代码。在 ZLG 开源 GUI 引擎中，也大量使用了这种带注册功能的工厂模式，有兴趣的朋友可以去看看 AWTK 的代码。

 

 ZTIMER

前面我们说过，可扩展性除了针对接口编程外，离不开工厂模式的支持。功能块的工厂其任务当然是创建功能块了，所以提供了一个创建功能块的函数。参数 type 指定功能块的类型，函数返回对应类型的功能块：

1. ZTIMER 的结构

在 C 语言中，一般用结构来模拟类，把基类作为结构的第一个成员来模拟继承。这里必须让 aw_plc_fb_t 作为 aw_plc_fb_ztimer_t 的第一个成员。

/**
 * @class aw_plc_fb_ztimer_t
 * @parent aw_plc_fb_t
 * @annotation ["fb"]
 * 循环定时器。
 * 
 * > 当输入 IN 为 TRUE 时，开始计时，输出 Q 为 FALSE，ET 开始记录过去的时间。
 * > 定时时间到时，COUNT 增加 1， 输出 Q 在本次循环为 TRUE，ET 重置为 0。
 * > 输入 IN 为 FALSE 时重置定时器。
 */
typedef struct _aw_plc_fb_ztimer_t {
  aw_plc_fb_t fb; 

  /** 
   * @property {bool_t} in
   * @annotation ["in"]
   * 为 TRUE 开始计时，为 FALSE 时重置定时器。
   */
  bool_t in : 1;

  /** 
   * @property {iec_time_t} pt
   * @annotation ["in"]
   * 预设时间 (ms)。
   */
  iec_time_t pt;

...

} aw_plc_fb_ztimer_t;

这里的 API 注释采用了 AWTK 中定义的格式，但是对 annotation 做了一点扩展，增加了 3 个新的取值：

fb 表示这是一个功能块；

in 表示这是一个输入参数；

out 表示这是一个输出参数。

2. ZTIMER 的实现

每个功能块必须提供虚函数表中定义的函数，不过主要代码集中 exec 函数里（其它函数可以自动生成出来）：

static ret_t aw_plc_fb_ztimer_exec(aw_plc_fb_t* fb) {
  aw_plc_fb_ztimer_t* ztimer = AW_PLC_FB_ZTIMER(fb);

  if (aw_plc_fb_before_exec(fb) == RET_OK) {
    ztimer->current_time = aw_plc_now_ms();
    if (ztimer->state == 0 && !ztimer->prev_in && ztimer->in) {
      ztimer->state = 1;
      ztimer->q = FALSE;

      ztimer->et = 0;
      ztimer->count = 0;
      ztimer->start_time = ztimer->current_time;
    } else {
      if (!ztimer->in) {
        ztimer->q = FALSE;
        ztimer->state = 0;

        ztimer->et = 0;
        ztimer->count = 0;
        ztimer->start_time = ztimer->current_time;
      } else if (ztimer->state == 1) {
        if ((ztimer->start_time + ztimer->pt) <= ztimer->current_time) {
          ztimer->q = TRUE;

          ztimer->et = 0;
          ztimer->count++;
          ztimer->start_time = ztimer->current_time;
        } else {
          ztimer->q = FALSE;
          ztimer->et = ztimer->current_time - ztimer->start_time;
        }   
      }   
    }   
    ztimer->prev_in = ztimer->in;
  }

  return RET_OK;

}

3. 注册 ZTIMER

功能块需要注册到前面介绍的功能块工厂：

aw_plc_fb_factory_register(AW_PLC_FB_TYPE_ZTIMER, aw_plc_fb_ztimer_create);

坦白的讲，本文只是介绍了实现自定义功能块的关键步骤，实际工作要麻烦很多。如果手工去做这些工作，开发一个功能块还觉得好玩，而开发几十个甚至几百个功能块，人不会变疯就会变傻。下一篇文章会我们介绍一下，如何用代码生成器来完成这些单调的工作，让开发自定义功能块成为一项快乐的工作。

AWPLC 目前还处于开发阶段的早期，写这个系列文章的目的，除了用来验证目前所做的工作外，还希望得到大家的指点和反馈。如果您有任何疑问和建议，请在评论区留言。