Symbolic Access To Embedded Controllers

Symbolic Access To Embedded Controllers

Odd A. S. Olsen and Petter H. Heyerdahl

Odd A.S. Olsen and Petter H. Heyerdahl received their Master of Engineering degrees in Engineering Cybernetics at the Norwegian Institute of Technology, where Mr. Olsen later received a Ph.D. He is currently an independent consultant, developing electronics and programs for embedded controllers. Mr. Heyerdahl is associate professor at the Agricultural University of Norway, Department of Agricultural Engineering. Odd may be contacted at Jutulveien 11, N-0852 Oslo, Norway or by the Internet: odd. [email protected].

Introduction

A symbol table is an efficient solution to the consistency problem because it allows the data structures of the PC and controller to develop separately, yet links the two systems with a simple communication protocol. By this method, which resembles the message format found in the general-purpose interface bus (GPIB), values are referenced by their symbolic name, e.g. measured_pH, heater_power etc. We used this principle to control a group of bioreactors. Each reactor is controlled by an embedded controller which communicates with a supervising PC for operator instructions and data logging.

How Things are Connected

The Symbol Tables

typedef struct {
    char *name;
    int ival;
    double fval;
    void *(*scalefunc)(void *);
    char eeProm;
    char file;} symTabEntry;

The user interface is also oriented to the symbol table. The user can change parameters by choosing a parameter window. Each parameter entry field knows the pointer to its entry in the symbol table. It can thus read and write the value and call the scaling function. When the user changes a parameter, the new value is immediately scaled from floating-point to integer and transmitted to the controller. Because values are referred to by name rather than by pointer, the set-up of the parameter windows is simplified.

The symbol tables are alphabetically sorted, which allows the processor to use a binary search when looking for a name. (A binary search is faster than a linear search, but if the tables were large, I would consider using hash-tables.) The programmer will now and then insert new entries to the tables at a wrong position. On start-up both the PC and controller programs therefore go through their tables and check for alphabetic order. If unordered elements are found, the function issues an error message.

The structure of controller's symbol table is

typedef struct {
    char *name;
    int ival;
    char *(*func)(char *);
    int eeOffset;} symTabEntry;

The controller's program runs periodically, e.g. every five seconds. The program first reads all measurements and stores the values in the symbol table. The control algorithms then take their values and parameters from the symbol table and calculate responses. The results are stored into the table and output to actuators. Both measured values and actuator states are thus available to the PC.

To understand the use of the symbol table, say the control algorithm is pHerror=pHsetpoint-pHmeasured. This can be programmed as:

FindSymbol ("pHerror")->ival = 
    FindSymbol ("pHsetpoint")->ival - FindSymbol ("pHmeasured")->ival;

int *ppHerror;
ppHerror= &FindSymbol ("pHerror")->ival;

*ppHerror= *ppHsetpoint - *ppHmeasured;

Message Format

Each message consists of one or more submessages. The submessages and their elements can be separated by spaces and have the following format:

<name><operator>[<value>]

To add other value types the programmer need only define new operators and modify the structures and programs accordingly. A floating-point type is useful in some systems. A string type can also be of use, for example to transfer strings directly to an operator display on the controller. In a multi-processor embedded system, the string type can be used to transfer messages verbatim to subprocessors.

The following message transfers temp_setp=20 to EEPROM, sends delay=10 to the symbol table, requests the present value of temp, and executes the function pwr_sav:

temp_setp>20 delay:10 temp? pwr_sav!

temp:22 pwr_sav#16

Message Interpretation

typedef struct {
    int command;
    int type;
    char *name;
    int value; } toDoList;

In the controller the interpreter and reply assembler are integrated. In the PC, however, parameters are sent through a message assembler and replies decoded in a separate interpreter. The receiver is interrupt driven and executes the interpreter after a full message has arrived. The interpreter places the received values into the symbol table and transfers error messages to the user interface. The PC interpreter resembles the controller interpreter, which I am about to describe.

A Sample Application

The main program reads a message from the keyboard. It parses the message, then prints and executes the task list toDo. The task list is a list of structures with one entry for each subcommand. The Parse function assumes the message is formated as defined in Table 1. Since the grammar is quite simple, there is no need for recursive descent or other strategies used in compilers. There are several tests that check adherence to the format, and issue error messages if discrepancies are found. (This is most valuable during program development.) Finding an error stops the message interpretation. Inserting an EMPTY command terminates the list.

GetNextToken reads the next token in the message string. If the first character encountered is a letter, the token is a name. If it is a digit, the token is a value. If the first character is neither a name nor a value, the token is an operator. The function then copies the token into the token string of the parser and sets the type parameter according to the type. The size of the token-string (MAX_TOKNE_LEN) must be larger than the longest token that can occur. The type parameter is set equal to the operator's defined constant.

Parser calls StroreToken to save the encountered names in a string pool. This pool is recycled for each message by setting pPool=stringPool. The pool size (STRINGPOOL) must be large enough to store all the names can occur in one message. The address of the names is stored in the name element of the structure.

The task list ToDo can now be processed by calling DoCommands. This functin is essentially a loop which executes the commands through a switch statement. However, it first initializes a pointer to the beginning of the txBuffer, where the response message is stored. This buffer might be local to the more hardware-dependent parts of the program and not globally accessible, so this requires a function call to obtain the pointer. All function called in the DoCommands maintain the buffer pointer by accepting it as an argument and returning the possibly changed value.

SayError writes an error message to the transmit buffer. It receives a pointer to the task list, where it finds the name relating to the error, and error number.

The functions Assign, Request, ToEeprom, and RunCommand each begin by getting a name from the task list and looking it up in the symbol table. If the name isn't found, they write an error message to the transmit buffer.

The Assign function inserts the value in the symbol table. The Request function reads the value from the symbol table and generates a response submessage. ToEeprom puts the value into the symbol table and checks if the parameter has a place in the EEPROM. If eeOffset is greater than or equal to zero, it writes the value. If not, it issues an error message. RunCommand executes the program pointed to in the symbol structure. If the pointer is NULL, RunCommand generates an error message.

Assign, Request and ToEeprom all check for a function hook before returning. If they find one they call it. Assign, Request, and ToEeprom also maintain the transmitter buffer pointer so they can write to the buffer.

The program was compiled with Borland TurboC++ version 3.0. The library functions are all UNIX and ANSI defined, so using other compilers should not present any problem.

Final Thoughts