XXX -X-XXXX -XXXX -XXXXX.00 20XX IEEE Design and simulation of a multi controller solution [615371]

XXX -X-XXXX -XXXX -X/XX/$XX.00 ©20XX IEEE Design and simulation of a multi controller solution
for a temperature control system

SANDRU Florin -Daniel
Politehnica University of Timisoara
Faculty of Automation and
Computers
Timisoara, Romania
[anonimizat] SILEA Ioan
Politehnica University of Timisoara
Faculty of Automation and
Computers
Timisoara, Romania
[anonimizat]
MICLEA Razvan -Catalin
Politehnica University of Timisoara
Faculty of Automation and
Computers
Timisoara, Romania
[anonimizat]
Abstract—This article focuses on pr esenting the advantages of
using a simulation -based approac h in the desig n an d validation of
embedded systems. An existing system was extended to present
the necessary steps that need to be taken in the design ,
implementation and test phases. The use of a virtual system and
virtual measurement and test equipment presents certain
advantages in over development on a p hysical system like the
reduce d cos ts, the speed of development and complete
environmental control .
Keywords —circuit design , circuit simulation , data
communication , multi controller , Proteus simulation
I. INTRODUCTION

The design of a complete embedded system poses challenge
regarding both hardware and software design, if the two
disciplines relay on each other’s milestones certain activities
might be delay ed on both sides. The usage of such tools like
Labcenter’s Proteus PCB Design & Simulation software
permits the design and simulation of a complete system without
the need for a physical equipment. The tool has many
advantages in the educational sector as well giving the
opportunity for students to realize a hardware design and test
the implemented software through the set of virtual instruments
of the application. .

II. SYSTEM DESCRIPTION AND EXTENSION

A. Base system used for analisys
The starting po int is a temperature control system proposed
as an educat ional example for closed loop control systems . The
block d iagram of the system is pre sented in Figure 1 [1].
The task of the system consists in maintaining a
temperature close to the reference temperature .

Fig. 1 Temperature control system
B. System extension
For an extension focused on microcontroller data
communications the system was altered to the following
presented in Figure 2 .

Figure 2 . Extension of the temperature control system
The previously described system is more complex than
other implementations [ 2] that proposed a sing le chip solution .

The main reason for this is that the article focuse s on the data
communication in the solution rather tha n the most economical
solution.
III. HARDWARE EQUIVALENTS OF THE BLOCK DIAGRAM

The three microcontrollers are from the 8 -bit AVR based
MCUs with the following functions:
a) ATMEGA 8 [3], this microcontroller implements the
following funct ions:
1) Acquisition of temperature using the analo g-
digital converter
2) Output of the computed temperature on an LCD
display using the microcontrollers UART
interface
3) Output of the comp uted temperature to a
second ary microcontroller using the I2C (TWI)
interface
b) ATMEGA328P [4], this microcontroller implements
the following funct ions:
1) Reading the value f or com mutation from the
EEPROM memory
2) Reading the temperature transmitted by the I2C
master( ATMEGA8 )
3) Sending the switch command to t he third MCU
via UART
c) ATMEGA16 [5], this microcontroller implements the
following funct ions:
1) Read the command issued through the UART
interface
2) Set the GPIO state according to the command
received
As a temperature sensor a n LM 35 was used and for an
EEPROM circuit the 25LC040A was used. For better
visualization of the output command the relay was switched
with a n LED , from the so ftware point of view the command
logic being the same f or bo th.

The hardware equivalent of the block diagram is shown in
Figure 3.

Figure 3 Hardware design of the temperature contro l system
IV. SOFTWARE COMPONENTS
A. Software behaviour

The so ftware components are described in the form of a flow
chart , there separation is done based on the target controller.
For the ATMEGA8 microcontroller the software component is
described in Figure 4 .

Figure 4 Software component for the ATM EGA8
microcontroller

For the ATMEG 16 microcontroller the software component is
described in Figure 5.

Figure 5 Software component for the ATM EGA 16
microcontroller

For the ATMEGA 328P microcontroller the software
component is described in Figure 6.

Figure 6 Software component for the ATM EGA 328P
microcontroller B. Software build

For the software components the AVR Studio environment
was used, this platform offers all the necessary tools for
developing the applications based on the AVR
microcontrollers. The software components where written in
C.

V. SYSTEM SIMULATION AND VALIDATION

After the virtual hardware system design and software
development are finished the developed software can be tested
on the virtual environment, this being a great ad vantage over
the “classical” approach where a physical equipment is needed
and additional test instruments. The system validation will be
done from a functional point of view and from a data
communication point of view.

A. Asynchronous serial communication (UART)
A common configuration was used for all mic rocontrollers,
this configuration consisted of the following parameters :

Baud rate: 9600
Data bits: 8
Parity: None
Stop bits: 1

Two of the instruments provided by the Proteus environment
where considered extremely useful in debugging of the UART
driver, the logic analyzer and the virtual termina l one example
setup is presented in Figure 7.

Figure 7 Connection of th e virtual terminal and logic analyzer

The virtual logic analyzer output is extremely useful in
determining activity on the bus as shown in Figure 8 but is
harder to use if interpreting the data is required, as the virtual
logic analyzer has no option of automatic serial communication
interpretation the virtual terminal can be used for achieving this

task. Figure 9 shows the interpreted data on the virtual
terminal.

Figure 8 Output of the logic analyzer

Figure 9 Outpu t of the virtual terminal
B. I2C communication

An I2C compatible communication is realized using the
TWI interface of the ADMEGA8 and ATMEGA328P, in this
communication the ADMEGA8 acts as a master for the I2C
communication rending the integer value of the temperature to
the ATMEGA328P microcontroller, the role s could also be
reversed for the information to be sent on request. The virtual
instruments considered useful for debugging and validating the
solution are the logic analyzer and the I2C debugger, the logic
analyzer maintains its role for visualizing logic al transitions of
the outputs and the I2C debugger has a role in automatically
interpreting the I2C frame but also features the possibility to
send data on the bus. Figure 10 features the data transmission
on the I2C bus .

Figure 10 I2C debugger output C. SPI communication
The SPI interface of the ATMEGA328P microcontroller
was used for reading values form an external EEPROM
memory, those values are used as a reference for switching the
heating element on and off. The SPI debugger was used f or
testing the connection and the data flow to and from the
external EEPROM. The connection presented in Figure 11 sets
the SPI debugger to the perspective of the master and Figure
12 represents the read operation.

Figure 11 Connection of the SPI Debug ger

Figure 12 Output of the SPI Debug ger

D. System wide validation

With all main components verified a system wide test can
be made figures 13 and 14 correspond to the actions taken for
a temperature below the min imal temperature for heating and
above the temperature required for heating .

Figure 13 System reaction in case the temperature is under
the threshold

Figure 14 System reaction in case the temperature is over
the threshold

VI. CONCLUSIONS
This article demonstrates some of the advantages of using
a virtual environment for designing and testing an embedded
system and the data communicati ons associated with it. The
tools provided by the PROTEUS application helped the
software and hardware development. Using such tools has also
it’s disadvantages as certain real -life scenarios can’t be easily
simulated like heat transfers or certain noises that are present
in a real -life environment.

REFERENCES
[1] Sorin NANU , “EDUCATIONAL ASPECTS IN CONTROL SYSTEM
DESIGN TECHNOLOGY ” International Symposium “Research and
Education in an Innovation Era”, Section III, November 16 -18, 2006,
"Aurel Vlaicu" University of Arad, Romania.
[2] X. Xiumei and P. Jinfeng, "The simulation of temperature and humidity
control system based on PROTEUS," 2011 International Conference on
Mechatronic Science, Electric Engineering and Computer (MEC), Jilin,
2011, pp. 1896 -1898. [3] Microchip , ATmega8(L) – Complete Datasheet ,
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel -2486 -8-bit-
AVR -microcontrolle r-ATmega8_L_datasheet.pdf
[4] Microchip , ATmega328/P DATASHEET COMPLETE ,
http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel -42735 -8-
bit-AVR -Microcontroller -ATmega328 -328P_Datasheet.pdf
[5] Microchip , ATmega16(L) – Complete D atasheet ,
http://ww1.microchip.com/downloads/en/DeviceDoc/doc2466.pdf