基于CAN的远程下载技术开发及应用

0 引 言

变制冷剂流量(Variable Refrigerant Volume, VRV)空调系统是一种网络空调系统，由制冷剂管路网络和通讯信息流网络组成，并且一台室外机通过配管和通讯总线连接多台室内机，由在监控室的监控PC 机，监控整个系统的运行状态。系统结构简图如图1 所示。

VRV 空调系统结构简图

图 1 VRV 空调系统结构简图

系统控制信息通过通信网络传输，实现对制冷剂管路网络中制冷剂流量的精确调配，可使系统具有控温舒适可靠、节能环保、节省建筑空间等优势，近十几年得到迅猛的普及。

通讯信息流网络是VRV 系统的重要组成部分。下文为叙述方便，将监控PC 机称为主机端、室外机和室内机统称为目标端。

由于每套系统都有多个参数需要传感器实时检测，并且温度数据本身具有很大的时滞性，因而维护程序代码和功能调试非常困难。本文提出一种利用VRV 的通信网络和监控PC机进行程序远程下载的方法。

另外，VRV 空调系统的通信信息流网络目前还没有统一的总线标准，国际上各大厂家都是制定自己的总线标准，兼容性不够。我们在系统设计VRV 控制系统时，经多方比较，最后鉴于CAN 总线高安全性、故障自动退出等优势，选择CAN 总线作为系统的通讯总线。

VRV 系统的室外机和室内机选一款支持CAN 模块的Microchip公司的dsPIC33FJ 单片机作为主控制芯片。并且这款单片机本身支持Bootloader 功能，这为开发远程下载，进而实现系统维护和程序更新提供了一种可能。

本文开发出一种基于 CAN 总线，支持单点、多点及广播等多种方式的远程下载的技术，并具有软件复位、异常处理、数据加/解密等突出功能。这些功能极大方便了对VRV 空调控制系统的维护和应用，也为初期进行空系统的设计、开发、调试提供了一种极为便利的手段。

1 总体设计方案

1.1 远程下载原理

目标端复位后，在一个指定的时间内，目标端都监测与主机端相连的通讯总线是否有数据流活动。如果有，则跳转到Bootloader 自举程序，执行Bootloader 自举功能，将接收的数据，写入目标端的用户应用程序段，直到全部数据接收完成后，再跳转到用户应用程序段，执行刚接收到的新代码，实现用户应用程序的更新。如果超过时限，都没有监测到该总线上有数据流活动，则直接跳转到用户应用程序段，执行原有的程序功能。

在此一共有三段程序：

⑴目标端的自举程序和用户应用程序。这两个程序都是基于MAPLAB IDE 工具开发。

⑵主机端程序。这个程序是用Visual Studio C++开发，只有主机端程序才能主动发起与目标端自举程序间的通信。

整个通讯过程如图2 所示，其中：

(1)主机端程序读取和解析MAPLAB IDE 编译器生成的用户应用程序，并组织数据。

(2)通过CAN 总线将解析、重组后的数据传输给目标端器件。

(3)目标端自举程序(Bootloader)，将收到的数据加载到目标端器件相应的FALSH 段上。

通讯过程示意图

图 2 通讯过程示意图

1.2 系统功能设计

在整个设计开发中，关键之处是目标端 Bootloader 自举程序的开发。结合到VRV 空调系统的实际应用，整个系统应该至少具有以下功能：

(1)多种下载方式的提供。VRV 空调系统运行当中，可能需要根据实际情况采用不同的方式来进行远程下载。因而需要实现对单点、多点及广播等通讯方式的支持。

(2)软件复位功能。即便是目标端设备已经具备利用Bootloader 自举程序来实现远程下载的能力，但由于Bootloader 机制需要目标端先复位，才能重新再执行Bootloader 自举程序。

然而现场环境往往不能实施掉电或其他硬件方式复位目标端设备，这便需要有软件实现复位的手段。在此，将软件复位作为自定义的通讯协议中一个命令，由主机端发送给目标端，目标端的用户应用程序内接收到这一命令，经过解析、确认后进行复位。

(3)加/解密功能。鉴于多联机空调系统的商用价值，Bootloader 程序应当具备加密的功能，保护知识产权。这可以通过主机端和目标端之间采用一种密钥或加、解密算法，融合到通讯数据中实现。

(4)异常处理功能。在通讯过程中，很有可能出现如主机端出现故障，造成当前的数据不能继续成功发给目标端。目标端运行自举程序时，只有等到主机端数据全部通讯完毕，才可以跳转到用户应用程序，继续执行。此会造成目标端一直处于等待状态，效率低下或者接收错误数据并执行，以致出现严重后果。在系统设计开发时需要预留一个能够实现异常处理的命令以便主机端恢复后，将这个命令下发，目标段根据这个命令，重新接收正确的数据。

2 协议设计

要将系统的目标端和主机端之间，设计成支持单点、多点以及广播等多种远程下载方式，并且支持、软件复位和异常处理、加解密等功能，可以充分利用 CAN 总线数据帧的29 位（遵循CAN2.0B 协议）标识符来实现。定制的通讯协议中CAN 的帧格式如表1 所示，将CAN 的29 位标示符分为五段：优先级、控制域、通讯方式、节点编号、命令编号。

表 1 数据帧29 位标识符分配表

数据帧29 位标识符分配表

优先级：00->01->10->11 优先级别依次降低，默认优先级别为11，故障报警优先级最高为00，数据传输优先级为01，命令下传优先级为10，应答返回优先级为11。

控制域：ID26/ID22，用以表示当前的数据帧属于哪一种类型：故障为00、数据为01、命令10、应答11。

通讯方式：ID24/ID15，指定当前的数据帧是广播传输或者单点传输，全为0 是单点而全为1 是广播。

节点编号：ID14/ID8，共7 位，足够标识CAN 总线支持的多达112 个节点的最大负载。

命令编号：这里存放的是根据实际需要定制的一些命令，如软件复位命令、异常处理命令。主机端将定制的命令编号下发，目标端接收到命令后，解析后执行相应动作。仿照上表，配置各个目标端的接收过滤码和接收屏蔽码，便可以实现单点、多点以及广播通讯。另外，对于单点通讯方式下的远程下载，为保证主机端和目标端的通讯数据的正确和可靠传输，采用应答机制来实现，并定制了一套图3 所示的通讯链路机制。

主机端和目标端应答链路机制图

图 3 主机端和目标端应答链路机制图

远程下载的通讯只能由主机端开启。主机端先发送读取器件型号命令，读取目标端器件芯片型号，目标端收到这个命令，回复本身的型号数据作为一个应答，主机端根据这个型号，再开辟动态内存和组织要下传的数据。主机端接着下发一个读取器件PROM 命令，以获取目标端器件位于地址0x00 处的数据，将和从主机端读取并解析、组织后的HEX 文件一起下传。主机端收到这一步的应答后，开始发送写PROM 命令和PROM 数据，目标端将接收到的数据写入相应的地址段，每完成一页写操作，返回一个应答,接着接收主机端下传的下一页数据。PROM 写数据发送完后，主机端接着发送写CM 数据命令和写CM 数据，过程和写PROM 是一样的。最后，主机端下发一个跳转命令，目标端收到这个命令后，跳转到程序存储器的0x00 地址处。然后，目标端根据地址0x00 处存放的数据，跳转到用户应用程序。[page]

而对于多点或广播，通常都是对数百甚至上千目标端进行下载。如果目标端都应答，会造成总线上数据的堵塞，浪费大量的总线时间。所以采用非应答机制，直接烧写程序存储器。

此时主机端数据的下传，采用定时器触发方式。每当定时时间到达时，触发一次数据的发送。

直至最后，发送一个跳转命令。如果目标端没有执行跳转，那么认为当前目标端没能正确接收主机端发送的数据，主机端重新对当前目标端进行一次单点方式下的远程下载。

3 目标端设计方案

目标端Bootloader 自举程序一般只是一个简单的通讯程序，负责接收和发送数据，通常只需极少的存储空间，可以位于单片机程序存储器特定的Boot Segment 区域。程序存储器还有一段称为General Segment 区域可用于存储用户应用程序。单片机的程序存储器大多都是FLASH 闪存，数据是以一个个数据页的形式存储，必须先对当前存储页擦除，然后才能写入数据。自举程序还需使用dsPIC33 单片机器件中断向量表 (IVT) 中的复位向量实现程序的跳转、以及器件上的CAN 通信模块。单片机的程序存储器的地址映射如下图4 所示。

dsPIC33F 程序存储器地址映射图

图 4 dsPIC33F 程序存储器地址映射图

上图给出了dsPIC33 单片机器件的程序存储器的物理地址映射，由图可知用户应用代码应放置在用户应用程序地址段，而Bootloader 代码放在自举程序地址段。不论目标端自举程序(Bootloader)需多少存储空间，自举程序(Bootloader)和用户应用程序的存储位置都必须严格遵守目标端存储器构架。在具体设计中，须注意：

(1)慎用中断：Bootloader 自举程序不建议使用中断方式。目标端器件在写Flash 程序存储器时，有一个擦除程序存储器的操作，可能会擦除掉位于程序存储器上的中断向量表和备用中断向量表地址处的值，造成系统的死机。另外，一个功能强大的程序，一般都是用中断方式实现用户应用程序以提高实时性，这会生成一个中断向量表，存储在目标端器件程指定中断向量表和备用中断向量表地址处。如果在 Bootloader 自举程序也用中断方式，会使得一个目标端器件产生两个不一样的中断向量表和备用中断向量表区，造成系统的死机。

(2)存储位置：Bootloader 程序和用户应用程序不应处于同一页。自举程序(Bootloader)要先执行擦除程序存储器，才能将接收的新代码存入其中。如果处于同一页，在远程下载时，很可能擦除Bootloader 程序本身。

(3)自举延时：必须为目标端自举程序的执行指定一个延时值，这个延时值作为检测总线数据流活动的时限。

(4)链接文件配置：单片机默认的自举程序地址段是0X400 到0XC00。如果实际的自举程序代码量超过上述空间，需要修改链接文件，重新配置，以适合工程需要。

4 主机端设计方案

主机端的设计主要包含主机端通讯程序的实现，并为用户提供一个管理远程下载、软件复位、异常处理等功能的监控界面。主机端程序，采用了多线程的通信存储技术，一共包含线程:主线程、接收线程、远程下载线程，使得程序执行效率较高。

上位机软件界面图

图5 上位机软件界面图

软件界面如上图 5 所示，在这里实现的主要功能有：

(1)参数设置功能，包括CAN 的连接、断开、复位、启动、接收过滤码和接收屏蔽码等CAN 自身参数的设置。

(2)文件导入功能，载入存储在任意目录下目标端用户应用程序的HEX 文件。

(3)远程下载功能，这一功能由“更新按钮”触发产生，启动主机端程序和目标端的通信，实现远程下载。

(4)状态显示功能，由两个列表框，用于显示导入的HEX 文件的数据，和实时显示当前的通讯状态。

(5)软件复位功能，这一功能由“自举复位”触发产生，发送一个复位命令和异常处理命令，目标端根据命令进行相应操作。

5 结束语

本文结合VRV 空调控制系统开发的实际应用需求，以dsPIC33 单片机为硬件基础，开发了基于CAN 的远程下载系统。系统同时支持单点、多点、广播等下载方式，具有数据加密、软件复位、异常处理等以往所开发的远程下载技术所不具备的功能。

本文主机端程序的设计采用了多线程的通信存储技术，保证了程序的高效性和扩展性，并且可实时监测系统的状态，界面风格简洁明了，符合工程人员操作习惯。目标端严格按照dsPIC33F 单片机的体系构架，进行代码开发和链接文件的修改及配置，程序简洁易读、安全可靠。本系统2009 年初进行实验平台的联机调试，性能良好。

本文作者创新点：结合VRV 空调控制系统具有多传感器、温度数据具有时滞特性，利用VRV 空调系统的通讯信息网络，开发远程下载技术，节省成本提高效能；实现了软件复位和故障处理以及加解密等实际工况的需要，使得更为符合实际现场的需要。