1 2008 rzonca sadolewski

JOURNAL OF APPLIED COMPUTER SCIENCE Vol. 16. No 1(2008), pp. 49-67

Programming controllers in Structured Text language of IEC 61131-3 standard

Dariusz Rzoca, Jan Sadolewski, Andrzej Stec Zbigniew wider, Bartosz Trybus, Leszek Trybus

Rzeszw University of Technology Division of Computer Science and Control

ul. W.Pola 2, 35-959 Rzeszw, Poland email: {drzonca, janeks, astec, swiderzb,

btrybus, ltrybus}@prz-rzeszow.pl

Abstract. Programming industrial controllers by means of Control Program Developer (CPDev) package* in IEC 61131-3 Structured Text (ST) language is presented. The package involves ST compiler that generates an universal code executed on different platforms by Java-like virtual machines. Operation of compiler components, i.e. scanner, parser and code generator is presented in details. Virtual machine executes universal code using hardware allocation map for particular platform. The CPDev package is open in terms of software and hardware, what means that the user can create libraries, and hardware designers can program external interfaces. First application for programming a small distributed control-and-measurement system from LUMEL Zielona Gra is described.

1. Introduction

General purpose of IEC 61131-3 standard introduced in 1998 was to improve quality of software for programmable controllers. Now the standard is also a Polish law (PN-EN 61131-3). The IEC (number will be dropped for brevity) defines five programming languages, namely LD, IL, FBD, ST and SFC, allowing the user to choose one suitable for particular application, corresponding to his expertise. Instruction list IL and Structured Text ST are text languages, whereas Ladder Diagram LD, Function Block Diagram FBD and Sequential Function Chart SFC are graphical ones (SFC is not an independent

* Developed under MNiSzW grant no. R02 058 03.

D. Rzoca, J. Sadowski, A. Stec, Z. wider, B. Trybus, L. Trybus 50

language, since it requires components written in the other languages). Relatively simple languages LD and IL are used for small applications. FBD, ST and SFC are appropriate for medium-scale and large applications. John and Tiegelkamp's and Kasprzyk's books [1,2] are good sources to learn IEC programming.

ST is a high level language originated from Pascal, Ada and C, especially suitable for complicated algorithms. Equivalent code for a program written in any of the other four languages can be developed in ST, but not vice versa. Hence most of engineering packages use ST as a default language for programming user function blocks. Due to such reasons, ST has been selected as a base language for software package for programming control-and-measurement devices and small distributed systems, being developed by the authors under the sponsorship of Ministry of Science and Higher Education. The package called CPDev (Control Program Developer) is written in C# at Microsoft .NET Framework 2.0 [3]. Initial information has been presented in [4] and [5] at the recent Real Time Systems conference. Here we describe CPDev in more details, paying particular attention to compilation and explaining how the compiled code is executed on different hardware platforms.

The paper is organized as follows. Basic facts on programming in ST, i.e. data types, Program Organization Units (POUs) and an example of a function block code are presented in Sec. 2. Next section includes structure of CPDev, user interface, standard functions and libraries. The user can create his own POUs and libraries. Components of ST compiler, i.e. scanner, parser and code generator, are described in Sec. 4 together with classes of related objects. Section 5 presents the example of ST program compilation for standard up-counter, beginning from source code up to binary, universal code executed by Java-like virtual machine. Realization of the virtual machine, followed by first application of CPDev for programming distributed mini-system from LUMEL Zielona Gra, is described in Sec. 6.

2. Programming in Structured Text

2.1. Data types

Data types, literals (constants) and variables are common components of the five IEC languages. Variable names are typical, although there is no distinction between capital and small characters. The standard defines twenty elementary data types listed in Table 1 together with memory sizes and ranges (left part). BOOL, INT, REAL and TIME are most common. FALSE, 13, -4.1415 and T#1m25s are examples of corresponding constants.


51

Table 1. Elementary data types of IEC 61131-3 standard

Type Size (range) Type Size SINT 1B (-128 .. 127) BOOL 1B (0, 1) INT 2B (-32768 .. 32767) BYTE 1B DINT 4B (-231 .. 231 1) WORD 2B LINT 8B (-263 .. 263 1) DWORD 4B USINT 1B (0 .. 255) LWORD 8B UINT 2B (0 .. 65535) TIME 4B UDINT 4B (0 .. 232 1) DATE 4B ULINT 8B (0 .. 264 1) TIME_OF_DAY 4B REAL 4B, IEEE-754 format DATE_AND_TIME 8B LREAL 8B, IEEE-754 format STRING Variable length

The standard defines three levels for accessing variables, i.e. LOCAL, GLOBAL and ACCESS. LOCALs are available in the program, function block or function. GLOBALs can be used in the whole project, but programs, blocks or functions must declare them as EXTERNAL. ACCESS variables exchange data between different systems.

2.2. POU units

Well structured software consists of programs, function blocks and functions, i.e. Program Organization Units (POUs). Function blocks, designed for reuse in different parts of the program, are of crucial importance. A block involves inputs, outputs and memory for data from previous executions. The IEC defines small set of standard blocks listed further in Sec 3.2. Three of them are shown in Fig. 1.

Programs written in ST begin with declarations of variables and instances of function blocks placed between VAR and END_VAR keywords. The declarations are followed by list of instructions. The instructions involve expressions which, when evaluated, yield result in one of defined data types, i.e. elementary (Table 1) or derived, such as alias, array or structure. The following operators are available (in descending priority): parenthesis, function evaluation, negation, power, arithmetic operators, Boolean operators.


Fig. 1. Examples of IEC 61131-3 standard function blocks with time diagrams: SR flip-flop, TON on-delay timer, CTU up-counter

ST language provides five types of instructions: assignment := (Pascal symbol), selection IF, CASE, loop FOR, WHILE, REPEAT,

Table 2. ST source code for the CTU standard up-counter FUNCTION_BLOCK CTU (* CTU up-counter *) VAR_INPUT CU : BOOL; (* count up *) RESET : BOOL; (* reset *) PV : INT; (* preset value *) END_VAR VAR_OUTPUT Q : BOOL; (* signaling output *) CV : INT; (* current value *) END_VAR VAR CUp : BOOL := FALSE; (* previous CU input *) END_VAR IF RESET THEN (* if reset *) CV := 0; ELSE IF (CU AND NOT CUp) THEN (* if rising edge at CU input *) IF (CV < PV) THEN CV := CV + 1; END_IF END_IF END_IF Q := CV >= PV; (* Q := TRUE, if CV >= PV *) CUp := CU; (* previous value of CU *) END_FUNCTION_BLOCK


53

control RETURN, EXIT, END, function block call (invocation).

Table 2 presents source code of the up-counter CTU from Fig. 1. Rising edge at the input CU (Count Up) increments the output CV (Current Value). When CV reaches PV (Preset Value), the output Q is set to TRUE. R (Reset) clears the counter.

Suppose an instance of the CTU counter has been declared by COUNTER:CTU. The following instructions implement the block call and use its outputs:

COUNTER (CU:=INCREASE, R:=CLEAR, PV:=UPPER_LIMIT); FULL:=COUNTER.Q; HOW_MANY:=COUNTER.CV;

3. CPDev package

3.1. Internal structure

The CPDev package consists of three programs executed by PC and one by the controller. The PC programs are as follows: CPDev compiler of ST language, CPSim simulator, CPCon configurer of hardware resources.

The programs exchange data through files in appropriate formats. The CPDev compiler (the same name as the package) generates universal code executed by virtual machine (VM) run by the controller. The VM operates as an interpreter. The universal code is a list of primitive instructions of the VM language called VMASM assembler. VMASM is not related to any particular processor, however it is close to typical assemblers. The VMASM and virtual machine are described in Secs. 4, 5 and 6.

Fig. 2 presents relation between CPDev, CPSim and CPCon. Separation of the package into logic and hardware layers simplifies implementation at different platforms. The ST source program is compiled into universal executable code at the logic layer. The compiler employs ST syntax rules, list of VMASM instructions and POUs from libraries. Besides the universal code the compiler generates some information for debugging and simulation. The addresses of directly represented variables [1,2], declared in ST by AT keyword, are relative addresses (called local here). They are sufficient for the CPSim simulator but not sufficient for the target platform.


Fig. 2. Structure of Control Program Developer

Configuration of hardware resources at the lower layer involves memory, input/output (I/O) and communication interfaces. Specifications define memory types and sizes, numbers and types of I/Os and communication channels, validity flags, etc. Allocation of hardware resources has the form of a map that assigns local addresses to physical ones. Virtual machine at the target platform, given the universal code and the map, is able to execute calculations.

3.2. User interface

Main window of CPDev user interface is shown in Fig. 3. The window consists of three areas: tree of project structure, on the left, program in ST language, center, message list, bottom.

Tree of the MOVE_UNIT project shown in the figure involves POU with the program PRG_MOVE_UNIT, eight global variables from START to NUMBER, task TSK_MOVE_UNIT, and two function blocks TP and CTU from the standard library IEC_61131.

CompilerCPDevST source code

Error list Debugger information

ST language syntax VMASM assemblerLibraries

SimulatorCPSim

Logic layer

Configurerof hardware resources

CPCon

Target platform

I/O interface specification

CommunicationInterface specification

Hardware layer

Universalexecutable code

Hardwareallocation map


55

Fig. 3. User interface in CPDev package

The program PRG_MOVE_UNIT is written according to ST language rules [1,2]. The first part declares local variables Count, sTime, dTime, and instances of the function blocks CYCLES:CTU and PAUSE_TIME:TP. Declarations of global variables are in the second part, and instructions of the program in the third one. The instructions will not be discussed here. We merely explain that following START, every 2 seconds the value TRUE appears at one of consecutive outputs OUT0 to OUT3 (moving unit). The variable Count indicates which output has the unit. The signal PAUSE generated by the PAUSE_TIME block stops the movement for 10 seconds. The output NUMBER of the counter CYCLES indicates number of turns (loops) of the moving unit. RESET clears all variables and blocks.

Global variables and tasks are defined in CPDev using separate windows (not shown here). According to IEC the variables can be assigned CONSTANT and RETAIN attributes, and relative local addresses (by AT keyword). A task can be executed once, cyclically with a given period, or as soon as the previous


execution is completed. There is no limit on the number of programs assigned to a task, however a program can be assigned only once.

3.3. Functions and function blocks

The CPDev package provides most of the standard functions defined in IEC. Six groups of them followed by examples are listed below:

type conversions: INT_TO_REAL, TIME_TO_DINT, TRUNC, numerical functions: ADD, SUB, MUL, DIV, SQRT, ABS, LN, Boolean and bit shift functions: AND, OR, NOT, SHL, ROR, selection and comparison functions: SEL, MAX, LIMIT, MUX, GE, EQ,

LT, character string functions: LEN, LEFT, CONCAT, INSERT, functions of time data types: ADD, SUB, MUL, DIV (IEC standard uses

the same names as for numerical functions). Variables of any numerical type, i.e. INT, DINT, UINT and REAL (called

ANY_NUM in IEC) can be arguments in most of relevant functions. Two libraries are available in CPDev so far: IEC_61131 standard library, Basic_blocks library with simple blocks supplementing the

standard. Table 3 lists the blocks from the first library (source program for CTU has

been presented in Table 2). The second library involves fairly simple blocks similar to the ones available in multifunction instruments and small programmable automation controllers (PACs).

Table 3. Blocks from IEC_61131 standard library

Bistable elements Edge detectors flip-flop RS rising R_TRIG flip-flop SR falling F_TRIG semaphore SEMA Timers Counters pulse TP up CTU on-delay TON down CTD off-delay TOF up-down CTUD real time clock RTC


57

4. Compiler components

4.1. Scanner, parser and code generator

The task of the compiler is to convert XML source file with the project in ST language into a file with universal executable code in binary format. General diagram of the compiler operation involving scanner, parser and code generator is shown in Fig. 4.

Fig. 4. Operation of the CPDev compiler

The scanner (lexical analyser) analyses character stream from the ST source file and decomposes it into lexical units, i.e. tokens. The tokens are classified into categories. Most important categories are listed in Table 4. The tokens with categories are collected on a list passed to the parser.

Table 4. Token categories recognized by the scanner

Category Example Category Example identifier PRG_MOVE_UNIT integer constant 50 keyword FUNCTION operator + typed constant DINT#1722211 delimiter , comment (* reset *) directive (*$READ*) real constant 18.32 white space string constant 'Temperature: ' invalid character \

The parser operates according to top-down scheme with syntax directed translation [5]. By employing the ST syntax the parser recognizes consecutive token constructions from the scanner list. White spaces and comments are dropped. When correct construction is recognized the parser replaces it by a set of mnemonic instructions of the VMASM assembler. To do so, the parser employs built in elementary data types (Table 1) and list of VMASM instructions. Examples of these instructions are presented in Table 5.


Table 5. VMASM assembler instructions of the virtual machine

Instruction Meaning ST oper. Instruction Meaning ADD Addition + OR Logical or SUB Subtraction - XOR Logical xor MUL Multiplication * NOT Binary negation DIV Division / MCD Constant initialization NEG Negation - MEMCP Memory copy EXPT Power ** SHL/SHR Shift left/right GT Greater > ROL/ROR Rotate left/right LT Less < JMP Unconditional jump GE Greater or equal >= JZ LE Less or equal


59

4.2. Parser and code generator classes

Basic elements of the compiler are defined as classes in C# language [3,6]. Each token selected by the scanner becomes an object of corresponding class. The classes inherit from an abstract STIdentifier class. During compilation, object identifiers are collected on appropriate lists. So there is a list of global identifiers and lists of local identifiers for functions, function blocks and programs (POUs). Predicates are applied to find identifiers on the lists, so cumbersome creation of hash tables is avoided. The identifiers on the lists are verified with respect to uniqueness. If two identical ones are detected, the compilation is stopped and error reported. Hiding a global identifier by local one produces a warning message in compilation report (lower area in Fig. 3).

Virtual machine instructions passed from the parser to code generator involve mnemonics and operand lists. Each instruction is stored as an object of VMInstruction class. The operand list is an object of VMOperand class being a field in VMInstruction. The use of lists at all stages of the compilation eliminates problems encountered with fixed-size tables.

Fig. 5. Classes of object representation of ST tokens


5. Compilation of the CTU counter

5.1. Block definition, declarations

Compilation steps will now be presented in details using the example of the CTU counter (Table 2). So suppose that after merging all items of the project, i.e. global variables, POUs, tasks and libraries, the ST code of the CTU counter (repeated in Fig. 6) is going to be compiled.

Fig. 6. Compilation process-scanning and compilation

As indicated before, in the first step the scanner decomposes input character stream into tokens, and classifies them into categories. Here the first token is FUNCTION_BLOCK from keyword category (Table 4). Hence the next token CTU is treated as a new identifier of STFunctionBlock class and registered on the list of global identifiers. The following token VAR_INPUT is a keyword that begins declaration clause. ST language requires declaration clauses to be finished by END_VAR. Interpretation of all clauses beginning with VAR, so VAR_INPUT, VAR_OUTPUT and VAR proceeds according to lexical diagram of Fig. 7. Taking into account the types (BOOL and INT here), the parser determines memory sizes for the variables declared. The sizes will be used by the code generator to resolve addresses (Sec. 5.3).


61

Fig. 7. Lexical diagram of the VAR declaration clause

5.2. Instruction compilation, instance initialization

If the next token does not match any declaration clause, compilation of the code implementing the operation begins. The ST body is compiled first, followed by generation of the instance, i.e. assignment of initial values to variables and initialization of other functions and blocks, if used by this block. Here the body begins with the keyword IF of the conditional instruction. This translates into the line 009 in Fig. 6, with the conditional jump dependent on the identifier RESET. If RESET is FALSE (ELSE clause), JZ jumps to the label :?CTUIF?B00E0 below. We explain that the names of auxiliary variables and labels generated automatically during compilation of conditional instructions, loops and complicated expressions are indicated by question marks? This makes them different from the names in ST (without question marks).

The MEMCP instruction in the line 010 copies two bytes (#0200) to the variable CV from the auxiliary variable ?LVAR?T00E1 that stores 0 (see below). Unconditional JMP in the line 011 jumps to the label :?CTUIF?E00E? completing the IF instruction. The lines 013 and 014 evaluate the Boolean expression CU AND NOT CUp from the second IF. NOT is executed first, as required by priority [1,2]. The line 018 evaluates CV:=CV+1 from the third IF, with ?LVAR?T00EC storing 1. Two assignment instructions below the last END_IF (middle of Fig. 6) translate into the lines 020 and 021. The function GE replaces the operator >=. RETURN completes compilation of the body.

Now the compiler initializes the instance of the block. Corresponding code shown in the lines 001 to 007 contains the MCD instructions (Table 5) for initialization of output, local and auxiliary variables by constant values, namely:

Boolean variables Q, CUp initialized by FALSE (#00), integer variable CV initialized by 0 (#0000), auxiliary integer variables ?LVAR?T001, ?LVAR?T00EC initialized by

0 and 1 (#0100), respectively.


As seen, two byte variables are in the Little Endian form. Similarly as before, RETURN completes the initialization section.

5.3. Binary code

In the third step the final executable code for the virtual machine is created. To do so, the compiler consolidates the codes of all modules and translates the overall mnemonic code into binary form by replacing: instruction mnemonics with corresponding digital identifiers, variable names by addresses (local) in the data memory, label names by code addresses (absolute or relative).

Digital identifiers of mnemonics are provided by the LCF configuration file mentioned before. A portion of this file with definition of the GE instruction (line 020 before) is shown in Fig. 8 (lower left part). The identifier 1102 assigned to the vmcode attribute appears at the address 006F in the binary code.

Fig. 8. Compilation process code generation and output files

Local addresses of variables are resolved using the sizes determined by the scanner at the beginning (Sec. 5.1). The first address is 0000. In our example the variables CU, RESET, PV, Q, CV and CUp are consecutively declared (Fig. 6). BOOL occupies one byte and INT two. So the variables are at the addresses 0000, 0001, 0002, 0004, 0005 and 0007, respectively. The


63

addresses of Q, CV and PV are seen at 006F and 0073 in the binary code (Fig. 8, Little Endian).

As mentioned before, the LCF configuration file is created independently for each virtual machine. So in one case the mnemonic GE can be replaced by 1102 and in another one by something else. Diversification of the vmcode attributes is the way to optimize the code for particular processors. Besides, by using elements of the LCF file (TYPES section) one can restrict the number of available data types. This provides flexibility of the CPDev package. By applying , the number of data types for SMC controller mentioned in the next section has been restricted to ten. So by means of the LCF files one can create dedicated compilers for particular applications.

6. Realization of virtual machine

6.1. Virtual machine

Deployment of executable software at the target platform is illustrated in Fig. 9. Binary files with the universal code and hardware allocation map from the CPCon configurer (Sec. 3.1) are downloaded into the controller, to be processed by virtual machine. Main features of the processing are characterized below.

Fig. 9. Deployment of executable software in the controller

Virtual machine is an automaton operating according to Fig. 10. The task consists of programs executed consecutively. The binary code involves digital identifiers of the instructions and addresses of operands (Fig. 8, middle). The machine, similarly as a real processor, maintains program counter with the address of instruction to be executed, and base address of the data area with operands (specified for each POU). Given the instruction address, the machine fetches the identifier, decodes it, fetches the operands, and executes the


instruction. Stack emulation and update of the base addresses permit multiple, concurrent calls of functions and function blocks.

Fig. 10. Operation of the virtual machine

Allocation of software to memory segments is shown in Fig. 11a. The instructions are in the code segment (read only). Data segment contains global, local and auxiliary variables, some of them with constant values (Sec. 5.2). The data segment can be accessed directly or indirectly by special registers (virtual). The machine's internal memory holds code of the interpreter, stacks and registers. There is no way of accessing internal memory from the program level.

As shown in Fig. 11b, the virtual machine consists of a few software modules to simplify implementation on different platforms. The universal modules remain unchanged (if one neglects compilation of the source code for a given processor). The platform dependent modules must be rewritten or modified (but without changing procedure calls, see below). For instance, the module Time&Clock is associated with particular hardware, as it employs time interrupts to handle TIME data. DATE_AND_TIME data require real-time clock (RTC) on board. The multitasking module is optional, since it employs mechanisms of the host operating system. In such environment the tasks create private copies of global variables to avoid conflicts (so-called process image mechanism).


65

Fig. 11. Virtual machine: a) memory organization, b) software modules

The universal part of the virtual machine has been written in industry standard ANSI C, so it can be directly applied to different processors. As indicated before, the number of data types and the way in which the machine instructions are executed are defined by the LCF configuration file. A set of general specifications has been developed in CPDev for handling processor components (interrupt system, RTC) and external interfaces (I/O, communications). The specifications are in the form of prototypes of corresponding procedures (names, types of inputs and returned outputs). The prototypes do not depend on processor and hardware solutions.

The file with the prototypes (*.h) is compiled together with the universal modules of the virtual machine. The contents (bodies) of the specification procedures can be prepared elsewhere and, as a binary file (e.g. *.obj), consolidated with the compiled universal modules. This gives the complete code of the virtual machine for the given platform.

We stress that the contents of the procedures, dependent on the processor and hardware solutions, may be written by controller designers themselves. This makes the CPDev package open also in the hardware sense.

7. Distributed mini-system with SMC controller

An SMC controller (Fig. 12a) introduced recently by LUMEL Zielona Gra [8] is the first control-and-measurement device programmed by the CPDev package. SMC has two RS-485 and RS-232/485 serial ports and USB interface, but does not have inputs and outputs of its own. Therefore it is


used as a central module in distributed mini-systems for control and monitoring of small technological processes. Example of such system is shown in Fig. 12b. Modbus RTU protocol handles communications [9].

a) b)

Fig. 12. a) SMC programmable controller; b) distributed control-and-measurement system from LUMEL Zielona Gra

Of twenty data types available in CPDev (Table 1), the SMC implements ten, namely BOOL, INT, DINT, UINT, REAL, WORD, DWORD, STRING, TIME and DATE_AND_TIME. Since SMC does not carry I/Os on board, the CPCon configurer configures communications only.

The SMC controller is equipped with 8-bit AVR ATmega 128 microcontroller [10]. This is a modern RISC microprocessor able to execute most of instructions in a single clock cycle, with separate buses for program and data memories. The universal modules of the virtual machine, i.e. VMASM assembler interpreter, stack emulator and data type handler (Fig. 11b) have been compiled by avr-gcc compiler from WinAVR package [11]. Hardware dependent software, i.e. interrupts, RTC and communication interfaces have been written by engineers from LUMEL and sent to the authors in binary format. Consolidation has produced a virtual machine which, written into SMC flash memory, executes ST programs compiled by CPDev package and downloaded from PC.

Another machine for ADuC841 microcontroller (MCS-51 core) has been also developed. The machine for PC is a part of CPSim simulator.

RS4

85

RS232

RS485

RS4

85

S MC

SMC


67

8. Conclusions

The CPDev package for programming controllers and other control-and-measurement devices in the ST language of IEC 61131-3 standard has been presented. The package is universal, since the compiled code can be executed on different platforms. However, the execution must be carried out by virtual machines dedicated for particular processors.

Operation of the CPDev compiler involving scanner, parser and code generator has been explained by means of a program for CTU counter. The compiler produces universal executable code which, together with hardware allocation map, is downloaded into the controller and executed by the virtual machine. The machine is configured by means of LCF Library Configuration File which enables selection of data types and some form of code optimization.

The CPDev package is open in terms of both software and hardware. The user can create libraries with POUs. Hardware designers can program external interfaces (drivers). Distributed mini-system from LUMEL is the first application of the package.

References [1] John K.H., Tiegelkamp M.: IEC 61131-3: Programming Industrial Automation

Systems. Berlin Heidelberg, Springer-Verlag, 2001. [2] Kasprzyk J.: Programming Industrial Controllers, WNT, Warsaw, 2006 (in Polish). [3] C# Language Specification

http://msdn2.microsoft.com/enus/vcsharp/aa336809.aspx [4] Rzoca D., Sadolewski J., Trybus B.: IEC 61131-3 standard ST compiler into

universal executable code. In: Real-Time Systems. Methods and Applications, WK, Warsaw, 189-198, 2007 (in Polish).

[5] Stec A., wider Z., Trybus L.: Functional characteristic of the prototype system for embedded systems programming. In: Real-Time Systems. Methods and Applications, WK, Warsaw, 179-188, 2007 (in Polish).

[6] Cooper K., Torczon L.: Engineering a Compiler. Morgan Kaufmann, San Francisco, 2003.

[7] Appel A., Palsberg J.: Modern compiler implementation in Java. Second edition. Cambridge University Press, 2002.

[8] LUMEL Ltd., Zielona Gra http://www.lumel.pl [9] Modicon MODBUS Protocol Reference Guide. MODICON, Inc., Industrial

Automation Systems, Massachusetts, 1996. http://www.modbus.org/docs/PI_MBUS_300.pdf

[10] ATmega 128 Datasheet. Atmel, 2007. http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf

[11] WinAVR Development Tools for the Atmel AVR. http://winavr.sourceforge.net/ [12] ADuc841 Datasheet. Analog Devices, 2003.

http://www.analog.com/UploadedFiles/Data_Sheets/ ADUC841_842_843.pdf

1 2008 rzonca sadolewski

Documents