編譯型PLC的設計與實現

賈翔宇，劉 淼，金 星，

（1.中國科學院 上海微系統與信息技術研究所，上?！?00050；2.上?？萍即髮W 上?！?00031；3.浙江中科領航汽車電子有限公司 浙江 杭州　311228）

編譯型PLC的設計與實現

賈翔宇1，2，劉 淼3，金 星1，2，3

（1.中國科學院 上海微系統與信息技術研究所，上海200050；2.上?？萍即髮W 上海200031；3.浙江中科領航汽車電子有限公司 浙江 杭州311228）

傳統的PLC采用解釋執行的方式，效率低。而傳統的編譯型PLC雖然執行效率高，但是移植性差?；谶@種情況，該文提出一種先把指令表語言編譯為C語言，再編譯C代碼的方案。而且，主函數和功能函數分開編譯并燒錄在flash的不同地址塊，能夠有效節省編譯、燒錄時間，提升開發效率。

編譯；PLC；指令表；不同地址塊

PLC（Programmable Logic Controller），全稱為可編程邏輯控制器，是一種專門用于工業控制的微型計算機。隨著計算機的不斷發展、技術不斷的進步，工業控制迫切需要性能更加可靠、技術更加先進的控制單元。而與要求不斷提高相對應的卻是PLC控制系統越來越大、越來越復雜，這使得傳統的解釋執行方式在PLC中逐漸成為瓶頸，成為制約PLC性能的重要因素［1］。

本文介紹一種方式，在PLC上實行編譯執行的方式，具有良好的移植性，并且能夠有效減少編譯、燒錄時間，提升開發效率。

1　指令執行方式

1993年國際電工委員會（IEC）正式頒布了可編程控制器的國際標準IEC 1131（以后改稱IEC 61131），其中的第三部分關于編程語言的標準，規范了可編程控制器的編程語言及其基本元素。主要包括指令表語言 （IL）、結構化文本語言（ST）、梯形圖語言（LD）、功能塊圖語言（FBD）和順序功能圖（SFC）。自從IEC61131-3正式公布以后，國際上各大PLC廠商都宣布其產品遵循該標準的規范。正因為有了IEC61131-3，才真正使得PLC程序不必依賴于特定的硬件產品，為程序在不同機型之間的移植提供了可能。

PLC中指令的執行方式主要分為解釋執行和編譯執行。解釋執行的方式如圖1所示，它沒有將用戶的源代碼直接生產目標文件，而是對源代碼進行掃描，逐句解釋執行。每一條用戶指令，在下位機的運行軟件中都對應著一個相應的函數，當掃描到一條指令時，就跳轉到其對應的函數上。

圖1　解釋執行方式

解釋執行的優勢是：具有良好的移植性，并且開發難度較小。但它也有明顯的缺點：執行效率低，嚴重影響PLC控制的實時性［1］。

編譯執行方式是將用戶編寫的源代碼通過編譯器直接翻譯為目標機器所能識別的機器碼，它遵循編譯原理，從源程序輸入，經過詞法分析、語法分析、語義分析、源代碼優化、代碼生成和目標代碼優化等六個主要階段，如圖2所示。編譯型PLC將整個編譯系統放在上位機（PC機）運行，有效減少了目標機器的資源消耗。編譯型PLC占用資源少，執行效率高。但是，一旦針對特定機型的目標機設計完成一個編譯系統，該系統就只能用于同類體系結構的目標機，而不能用于其他體系結構的目標機，可移植性幾乎等于沒有，通用性極差［2］。

圖2　編譯執行方式

圖3　系統總體框架圖

由于傳統編譯執行方式的移植性問題，本文采用把IL指令表語言編譯為C語言，然后調用C編譯器的方式。這是因為C語言非常成熟，相應的C編譯器非常多，能夠有效解決移植性的問題。整個系統的框架圖如圖3所示。編譯器實現IL指令表語言到C語言的編譯。編譯出來的C代碼被封裝成一個功能函數，然后通過交叉編譯，生成hex1文件。主函數是在IDE集成開發環境中編輯編譯的，它主要是執行與外設IO的數據交換，并通過指針跳轉來循環調用指令表程序編譯出來的C函數。最后把兩個hex文件分別燒錄在stm32中flash的不同地址塊。

2　編譯器的設計實現

如圖3所示，編譯器主要是實現IL指令表語言到C語言的轉換。它主要包括以下幾個部分：掃描程序、語法分析程序、語義分析程序和代碼生成程序［4］，如圖4所示。

圖4　編譯器流程圖

掃描程序執行詞法分析（Lexical analysis），它將字符序列收集到稱作記號（token）的單元中，每一個記號由一個或多個字符組成。語法分析程序從掃描程序中獲取記號形式的源代碼，并完成定義程序結構的語法分析，生成一棵抽象語法樹。語義分析程序就是計算編譯過程中所需要的附加信息，對抽象語法樹的各個節點進行注釋。代碼生成程序生成所需要的C代碼。符號表和錯誤處理程序存在于編譯過程的各個階段，每個階段都有自己相應的操作。

與單個副詞的研究成果相比，結構研究顯得遜色很多。比如副詞和副詞性結構的差異，副詞組合結構的功能，這些都有待進一步的研究。

2.1掃描程序

編譯器的掃描或詞法分析階段可將源程序讀作字符文件并將其分為若干個記號，每一個記號都是表示源程序中信息單元的字符序列。例如：關鍵字（keyword），它們是字母的固定串；標識符（identifier），它們是由用戶定義的串，通常由字母和數字組成并由字母開頭；特殊符號（special symbol），例如算術符號+、*等。

本文采用flex（fast lex）［5］自動生成掃描程序。Flex的源文件 （通常帶有一個.l后綴）由3個部分組成：定義集（definitions）、規則集（rules）以及輔助程序集（auxiliary routines）。這3個部分由雙百分號分開，格式如下：

定義集出現在第一個雙百分號之前。在定義集中，需要特別注意的是在分隔符 “%｛”和 “%｝”之間要添加頭文件#include“***.tab.h”，這是因為這個頭文件中包含有所有詞法單元的定義。

規則集由一連串帶有C代碼的正則表達式組成，當輸入的字符匹配到相對應的正則表達式時，這些C代碼就會被執行。例如：

輔助程序集包含著一些C代碼，它們是自定義的，會被完整地拷貝到生成的C代碼中。

語法分析程序的任務是從掃描程序產生的記號中確定程序的語法結構，以及或顯示或隱示地構造出表示該結構的分析樹或語法樹［6］。

例如，IL指令表語言中的一段代碼：

這部分代碼的分析樹可以表示為如圖5所示。

圖5　語法分析樹

分析樹的內部節點是非終結符，葉子節點表示的是輸入中的記號序列。本文采用bison語法分析生成器來生成語法分析程序。Bison語法分析生成器將IL指令表語言的LALR （1）的上下文無關文法描述轉化為分析該文法的C程序［5］。Bison取到一個源文件（通常帶有一個.y后綴）并產生一個由分析程序的C代碼組成的輸出文件［5］。特別注意，在生成過程中，要添加-d參數，生成一個頭文件***.tab.h。它包含有所有記號的定義，并且會被包含在flex源文件中的定義集中。

Bison的源文件和flex源文件具有相似的格式，均包含有定義部分、規則部分和輔助程序部分。定義部分包括了bison需要用來建立分析程序的有關記號、數據類型以及文法規則的信息。規則部分包括Backus-Naus范式（BNF）中的文法規則以及將在識別出相關的文法規則時被執行的C代碼中的動作。輔助程序部分包括了一些函數，它們會被原封不動的拷貝進生成的.c文件。

2.3語義分析程序

程序的語義就是它的“意思”，它與語法或結構不同，它確定程序的運行。編譯器中的語義分析程序主要做的是靜態語義分析，因為動態語義分析只有在程序運行的時候才能確定［7］。本文的靜態語義分析主要包括聲明和類型檢查。由語義分析程序計算的額外信息（諸如數據類型）將作為注釋或“裝飾”增加到語法樹中。

語義分析程序將用所有的表達式類型來標注語法分析程序生成的抽象語法樹，并檢查賦值是否使這些類型有意義了，如若沒有，則聲明一個類型匹配錯誤。

2.4代碼生成程序

IL指令表語言是一種類匯編語言，而C語言是高級語言，它們有不同的指令規則，要實現轉換需要建立它們的映射關系，將IL指令表的所有指令定義為C語言函數形式。例如：指令LD對應的函數為

2.5符號表和錯誤處理程序

符號表在編譯過程中存放指令表程序中出現的有關標識符的屬性信息，符號表中所登記的信息在編譯的不同階段都要用到。在詞法分析階段，掃描器識別出一個標識符后，編譯程序查詢符號表，看其是否在符號表中，如果不在，就把這個標識符添加進符號表。在語義分析階段，符號表所記錄的內容將用于語義檢查（如檢查一個名字的使用和原先的說明是否一致）。在代碼生成階段，符號表是進行地址分配的依據。

錯誤處理程序存在于編譯過程的各個階段中，每個階段檢測到錯誤后，將以各自的方式進行錯誤處理。在詞法分析階段，flex的源文件中添加%option yylineno，使得生成的掃描器能夠跟蹤正在分析的指令行，了解到當前分析的記號在程序中的位置［8］。這樣，當有錯誤發生時，可以很快定位到錯誤的位置。語法分析階段，bison提供了yyerror錯誤處理報告函數。語義分析階段，會進行類型檢查，當出現不匹配的類型時，就會報類型匹配錯誤。

2.6一個實例

下面是一個以IEC61131-3編程語言中的IL指令表語言編寫的一段程序，它實現了最簡單的輸入A控制輸出B的功能。

經過編譯器的編譯，我們可以得到兩個文件，POU.h和POU.c。POU.h中主要包括變量和函數的聲明，POU.c中包括變量的初始化以及函數的主體。其中，函數的主體部分如下所示：

3　移植到stm32上

本文最終在stm32F103系列的硬件平臺上進行驗證。整個嵌入式軟件分為兩個部分，一部分是功能函數function（），它是指令表程序編譯得到的C代碼封裝成的；另一部分是PLCRun程序，主要是主函數以及外設的初始化。

如圖6所示，function函數被寫在flash中一個固定的地址塊中，例如以0x08020000起始的地址塊。PLCRun程序從0x08000000處開始，且在主函數中通過指針跳轉循環掃描function函數，得到實時的輸入輸出狀態。

圖6　Flash地址

3.1交叉編譯環境

指令表程序編譯得到的C代碼，可以封裝成一個功能函數function（）。本文采用在linux系統下搭建交叉編譯環境的方法來進行編譯，并自己編寫Makefile文件以及linker.ld文件。

交叉編譯技術是一種在異構平臺上編譯出目標平臺程序的技術。通俗理解，就是構建一種在母平臺上運行、編譯的工具，編譯生成的程序能運行在體系結構不同的另一種平臺上。本文，則是在X86硬件平臺ubuntu操作系統上編譯出能運行于Cortex-M3內核的ARM平臺上的程序。

本文采用GNU推出的ARM交叉編譯工具arm-noneeabi-gcc（ARM architecture，no vendor，not target an operating system，compiles with the ARM EABI）。使用命令arm-noneeabi-ar把stm32庫文件打包為靜態庫libstm32.a。由于這里只是編譯一個函數，所以編譯過程中不需要stm32的啟動文件startup.c。編譯過程中，工具鏈的參數配置如下：-g-mcpu= cortex-m3-mthumb-fno-exceptions-ffunction-sectionsfdata-sections-llibstm32.a-nostartfiles-Wl，--gc-sections，-Tlinker.ld。其中，-g會在編譯的時候產生調試信息；-mcpu= cortex-m3-mthumb指定目標 cpu為 cortex-m3，并采用thumb指令集；-fno-exceptions會在編譯時禁用異常機制；-ffunction-sections-fdata-sections會使編譯器為每個function 和data item分配獨立的section；-llibstm32.a會在編譯過程中鏈接靜態庫libstm32.a；-nostartfiles鏈接時不適用標準系統的啟動文件；-Wl選項告訴編譯器將后面的參數傳遞給鏈接器；--gc-sections會使 ld刪除沒有被使用的 section；-Tlinker.ld使用linker.ld鏈接腳本。

Linker.ld腳本文件能夠對鏈接過程提供精確和全面的控制。鏈接腳本最開始就會指定程序運行開始的地方，ENTRY（function）。而且，鏈接腳本在編譯時會告訴編譯器把代碼放到什么位置，MEMORY｛FLASH（RX）:ORIGIN= 0x08020000，LENGTH=128K｝（這里的地址0x08020000是自己設定的一個程序的開始地址，且大小為128Kbyte）。

編譯最后會生成*.elf可執行文件，通過命令arm-noneeabi-objdopy-O ihex*.elf*.hex，生成函數的hex文件，即hex1。

3.2程序跳轉

PLCRun程序部分主要是包括外設的驅動、初始化，以及主函數，它是在集成開發環境中編輯編譯的。主函數while （1）循環中實現程序跳轉的功能，即通過拉指針的方式，把當前的pc指針直接指向function（）函數所在的地址，函數執行完后，再跳轉回來。這里會編譯生成hex2文件，需要注意的是hex2文件的大小，如果hex2文件超過分配空間的大?。?x08020000-0x08000000，也就是128Kbyte），就需要重新分配地址空間，把function（）函數的初始地址設在地址值更大的位置。

最終，把兩部分hex文件都燒錄在stm32的flash中，經過驗證，程序運行結果與預期結果一致。而且，在外設IO固定的情況下，主函數部分只需編譯、燒錄一次。而每次指令表程序修改，只需要編譯、燒錄功能函數部分，有效地節省了編譯燒錄的時間。

4　測　試

本文主要進行了兩方面的測試，一是執行效率的測試，二是代碼占用空間的測試。

在效率測試中，測量PLC執行1000條指令所需要的時間［1］。硬件平臺都是stm32F103系列芯片，且芯片主頻均為72MHz。編譯執行1000條指令所需時間約為450-500us，而解釋執行需要10ms，編譯執行效率約為解釋執行的20倍。

代碼占用空間方面，解釋型PLC生成的bin文件為92.4Kbyte（其中包含有外設的驅動、初始化等，不只是解釋器），相同指令的編譯型PLC生成的bin文件為84Kbyte，其中，主函數部分為74.3Kbyte，功能函數部分為9.7Kbyte，節省了8.4Kbyte的flash空間。綜合結果如表1所示。

表1　測試結果

5　結　論

解釋型PLC開發難度小，便于移植，但是其執行效率低，不能滿足現代工業控制的要求。編譯型PLC，其執行效率大大提升，并且能夠節省一定的內存空間。但傳統的編譯型PLC移植性差，本文提出的把指令表語言編譯為C語言，功能函數和主函數分開編譯并燒錄在不同地址塊的方案，具有良好的移植性，并且能夠節省一定的編譯燒錄時間，提升開發效率。

［1］趙涌，趙雪飛，張紅芳，等.編譯執行在可編程邏輯控制器上的實現［J］.自動化與儀表，2011，26（12）:52-55.

［2］劉正.工程機械嵌入式PLC即時編譯系統的研究與實現［D］.中南大學，2014.

［3］王蔚庭.解析工業編程語言國際標準IEC61131-3［J］.國內外機電一體化技術，2007，（2）:47-62.

［4］姜娟，馮萍，康繼昌.嵌入式軟PLC開發系統研究［J］.科學技術與工程，2011，11（3）:494-498.

［5］王亞男，陳嬋娟.基于Flex與Bison的軟PLC編譯模塊的研究［J］.制造業自動化，2011，（17）:76-79.

［6］Yuan Xiaohong，Zhou Sisi.The research of syntax tree of the compiler based on programmable logic controller ladder diagram［C］//BusinessManagementandElectronic Information（BMEI），2011 International Conference on. IEEE，2011:100-102.

［7］Tisserant E，Bessard L，De Sousa M.An Open Source IEC 61131-3 Integrated Development Environment［C］//Industrial Informatics，IEEE International Conference on.IEEE，2007: 183-187.

［8］郭書杰，馬躍，王品.基于IEC61131-3的IL編譯器的設計與實現［J］.計算機工程與設計，2010，31（10）:2300-2302.

Research and implementation of compiled PLC

JIA Xiang-yu1，2，LIU Miao3，JIN Xing1，2，3
（1.Shanghai Institute of Microsystem and Information Technology，Chinese Academy of Sciences，Shanghai 200050，China；2.Shanghai Tech.University，Shanghai 200031，China；3.Autorock Electronics（Zhejiang）Co.，Ltd，Hangzhou 311228，China）

Traditional PLC works inefficiently by using interpreted mode.And the PLC works efficiently by using compiled mode，but it has bad portability.Based on this situation，this paper proposes a new scheme，which converts from instruction list to C language，and then compiles the C code.In addition，the main function and functional function compile separately and download to different address block of the flash.This way can save the time of compiling and downloading efficiently，and can improve the development efficiency.

compile；PLC；instruction list；different address block

TP31

A

1674-6236（2016）14-0040-04

2015-07-31稿件編號：201507199

賈翔宇（1992—），男，山西長治人，碩士研究生。研究方向：嵌入式軟件。