Sei sulla pagina 1di 72

Implementation of Ethernet support and

In Application Programmable Storage on VME based

A dissertation Submitted to
School of Instrumentation, DAVV Indore(M.P.)


Abhas Jain
Roll No: DE1501129
In partial fulfillment for the award of the degree of
Master of Technology
Specialization in
Project work carried out at
Raja Ramanna Centre for Advanced Technology,
Department of Atomic Energy, Indore

Guide: Co-Guides:

Shri Amit Chauhan Dr Rishi Pal Yadav Shri Rahul Rana

Declaration by Candidate

I ,undersigned, solemnly declare that the dissertation entitled “Implementation of Ethernet

support and In Application Programmable Storage on VME based boards” in partial
fulfillment for the award of the Master of Technology with Specialization in Instrumentation
Engineering is an authentic record of my own work carried out during the course of my study
under the supervision of Shri Amit Chauhan, (SO/F), ACSD, RRCAT, Indore.

I assert that the statements made and conclusions drawn are an outcome of the project work.

Date: Abhas Jain

Enrollment No. DE1501129

Raja Ramanna Centre for Advanced Technology
Indore (M.P.)


This is to certify that that work contained under dissertation titled, “Implementation of
Ethernet support and In Application Programmable Storage on VME based boards” has
been prepared by Mr.Abhas Jain under our supervision. This work is in partial fulfillment of the
requirement for the degree of Master of Technology in Instrumentation Engineering from
School of Instrumentation, Devi Ahilya Vishwavidyalaya, Indore (M.P).

He has worked on this project during the period from 11th July 2016 to 31st May 2017. He has
put in adequate efforts during this project work and we wish him success in his future endeavors.

Head of the Division Guide Co-Guides

Shri Pravin Fatnani Shri Amit Chauhan Dr Rishi Pal Yadav


Shri Rahul Rana


School of Instrumentation, Devi Ahilya Vishwavidhyalaya


This is to certify that thesis entitled “Implementation of Ethernet support and In Application
Programmable Storage on VME based boards” submitted by Abhas Jain having enrollment
number DE1501129 to School of Instrumentation, DAVV, Indore in partial fulfillment for the
award of degree of Master of Technology in Instrumentation Engineering is a bonafied
record of the work carried out by him during the academic year 2016-2017 and is accepted for
being evaluated.

Dr. Ratnesh Gupta External

Professor and Head
School of Instrumentation
DAVV, Indore


First of all I would like to thank Sh.Pravin Fatnani, Head ACSD for giving me an opportunity
to carry out my project work in Accelerator Control Systems Division, RRCAT.

Special thanks to Sh.K.Saifee for providing the VME based Profi Communication board and
explaining its design details which served as the foundation of my project work.

I am thankful to Sh.Amit Chauhan, Dr.Rishi Pal Yadav and Sh.Rahul Rana for guiding me
through the project phase.

I also thank Sh.Samaresh Kar for helping me out during hardware preparation related work.

Abhas Jain


Chapter 1 Introduction Chapter

1.1 Aim
1.2 Project Methodology
1.3 Overview of VME based Control System

Chapter 2 VME Bus

2.1 VME Bus Fundamentals
2.2 Versions of VME Bus
2.3 Features of VME-32
2.4 VME bus Architecture
2.5 VME Components
2.6 Functional sub-buses of VME
2.7 Application of VME

Chapter 3 System Components and their features

3.1 Features of VME based Profi Communication Board
3.2 Features of Microcontroller 89C420
3.3 Arduino Mega 2560
3.4 Ethernet Shield W5100
3.5 Micro-Controller P89V51RD2

Chapter 4 Implementation of Ethernet Support

4.1 Present Scheme
4.2 Schematic of Profi slave
4.3 Approach towards new design
4.4 New Scheme
4.5 Working of New Scheme in field
4.6 Communication between CPU and Controller

Chapter 5 Software Development
5.1 Communication of VME with PC
5.2 Accessing Arduino’s Input and Output Ports
5.3 Arduino Programming
5.4 UDP Packet Format
5.5 Sending and Receiving Packets via UDP
5.6 Software Scheme
5.7 Packet Sender Utility

Chapter 6 Implementation of In-Application Programmable Storage

6.1 Overview of scheme
6.2 Characteristic of Flash in P89V51RD2
6.3 ISP vs IAP
6.4 Approach towards Firmware Development
6.5 Software Tools

Chapter 7 Testing
7.1 Testing of Ethernet Support on VME base board
7.2 Testing of In-Application Programmable Storage on VME
base board

Chapter 8 Result and Conclusion

8.1 Result from Implementation of Ethernet Support
8.2 Result from Implementation of In-Application Programmable


List of Abbreviations

AS* Address Strobe

BBSY* Bus Busy
BERR* Bus Error
CPU Central Processing Unit
DS* Data Strobes
DTACK* Data Acknowledgment
EC Equipment Control
IACK* Interrupt Acknowledgment
IACKIN* Interrupt Acknowledgment In
IACKOUT* Interrupt Acknowledgment Out
IAP In-Application Programming
ICSP In-Circuit Serial Programming
I/O Input / Output
IRQ* Interrupt Request
ISP In-System Programming
LWORD* Long Word
SC Supervisory Control
SPI Serial Peripheral Interface
SYSCLK System Clock
SYSFAIL System Failure
SYSRESET System Reset
UDP User Datagram Protocol
UI Layer User Interface Layer
VME Versa Modulo Eurocard

List of Figures

Fig 1.1 : Control System Architecture …………….......................................................

Fig 2.1 : Architecture of VME.......................................................................................
Fig 2.2 : VME Chassis...................................................................................................
Fig 2.3 : VME Components...........................................................................................
Fig 3.1 : Block Diagram of Profi Communication board ............................................
Fig 3.2 : Arduino Mega 2560........................................................................................
Fig 3.3 : Ethernet Shield W5100 ..................................................................................
Fig 3.4 : Block diagram of P89V51RD2.......................................................................
Fig 4.1 : Block Diagram of Present Scheme.................................................................
Fig 4.2 : Block Diagram of Profi Slave Board..............................................................
Fig 4.3 : Modification from Current Scheme to Proposed Scheme..............................
Fig 4.4 : Set up of new Scheme.....................................................................................
Fig 4.5 : Working of new Scheme.................................................................................
Fig 4.6 : Communication between CPU and Controller................................................
Fig 5.1 : Communication between PC and VME on RS 232 .......................................
Fig 5.2 : Screen shot of Hyper-terminal........................................................................
Fig 5.3 : Signaling sequence of Read Cycle..................................................................
Fig 5.4 : Signaling sequence of Write Cycle...............................................................
Fig 5.5 : VMEREQ and BG signal on Scope ...............................................................
Fig 5.6 : VMEREQ and BGACK signal on Scope......................................................
Fig 5.7 : User Datagram Format..................................................................................
Fig 5.8 : Flowchart of Software Scheme......................................................................
Fig 5.9 : UDP packet in RAM......................................................................................
Fig 5.10 : Screen-shot of Packets sent from utility.......................................................
Fig 6.1 : Flowchart of Firmware running on P89V51RD2...........................................
Fig 6.2 : Structure of Write Command..........................................................................
Fig 6.3 : Flowchart of Write operation.........................................................................
Fig 6.4 : Structure of Read Command.........................................................................
Fig 6.5 : Flowchart of Read operation.........................................................................
Fig 6.6 : Structure of Multiple Read Command..........................................................
Fig 6.7 : Structure of Multiple Write Command.........................................................

Fig 6.8 : Screen-shot of Keil uvision2..........................................................................
Fig 6.9 : Screen-shot of Flash Magic............................................................................
Fig 7.1 :Communication Board with Ethernet Support................................................
Fig 7.2 : Packets received on Arduino(seen on serial monitor).....................................
Fig 7.3: Packets received over Utility............................................................................
Fig 7.4: IAP Read Test...................................................................................................
Fig7.5: IAP Write Test....................................................................................................
Fig 7.6: IAP multi read and write test.............................................................................

List of Tables

Table 2.1 : Versions of VME bus..............................................................................

Table 2.2 : VME Bus Features.................................................................................
Table 2.3 : Functional modules available on VMEbus.............................................
Table 5.1 : Pin Mapping...........................................................................................
Table 8.1 : IAP function calls...................................................................................


Chapter1 tells about Aim, Project methodology and VME based control system.

Chapter2 discusses some details about VME Bus and components which include VME bus
fundamentals, features of VME-32 and its application in various fields, bus architecture and
functional sub-buses used by VME.

Chapter3 discuss about System components and their features which includes features of VME
based Profi Communication board and micro-controller present on board. It also includes
introduction to Arduino Mega 2560 and Ethernet Shield W5100.

Chapter4 aims at implementation of Ethernet support on VME based boards. It also discuss the
working of present scheme and also tells about approach towards developing new scheme.
Along with working of new scheme, communication between CPU and controller is also

Chapter5 handles the software environment of the Arduino.

Chapter6 aims at implementation of non volatile storage on VME based boards. It also includes
introduction towards the Flash memory and its programmable techniques i.e. In-Application
Programming (IAP) and In-System Programming(ISP). This chapter details about the
approach towards the development of firmware running on controller P89V51RD2.

Chapter7 is about testing of Ethernet Support on VME base board and In-Application
Programmable Storage on VME base board.

Chapter8 includes Result and Conclusion drawn from the project.


1.1 Aim
The Aim of this project work is Implementation of Ethernet Support and In-Application
Programmable Storage on VME based boards.

1.2 Project Methodology:

The methodology adopted for this project is to use an existing VME based slave board as the
base board for implementing the required functionalities. This approach obviates the need of
designing the VME board from scratch. An existing board provides a tested and working
platform upon which the new features can be implemented and tested in a reasonable time.

For this project a VME based Profi communication board has been used as the foundation upon
which the new required functionalities have been built. This board is based on Microcontroller
89C420 based and the required functionalities have been achieved by altering certain sections of
the board.

The project is divided in two parts:

Part-1 : Implementation of Ethernet support. In this, the existing microcontroller on the Profi
communication board has been replaced with Arduino based board. Also an Ethernet shield as
been used which provides network connectivity.

Part-2 : Providing In-Application programmable non-volatile storage. In this, the existing

microcontroller has been replaced with another microcontroller having In Application
programmable Flash. With the help of this feature the stored parameters can be modified on the
run and the data will be retained even when the power is not present.

1.3 Overview of VME based Control System
Accelerator Control System at RRCAT has a three layered architecture. Layer-1, known as User
Interface Layer consists of computers for operator console, file servers, data base servers, alarm
managers, consoles for software development etc. Layer-2, the Supervisory layer, consists of
Supervisory Controller (SC) VME stations that perform the task of supervisory control and data
acquisition. These stations are responsible for the proper operation of a single subsystem where
one station is assigned to one subsystem. Layer-3 consists of VME based Equipment Controllers
(EC) stations . All sensors, devices, instruments of the machine in the field are interfaced to
control system by ECs. Each EC controls and monitors the equipment it is interfaced with,
according to the tasks assigned by the SC to which it is connected.

ECs are interfaced to various accelerator subsystems like power supplies, vacuum pumps,
gauges and controllers, RF system equipment, safety and interlock systems etc. These are
designed around VME bus modular architecture and consist of CPU board, Profi-bus controller
board, analog & digital I/O boards and VME power supply. The CPU boards are based on
MC68000 microprocessor.

The Profibus slave Board in each of the Layer-3 station is connected to the Profibus Master
Board at Layer-2 in a multidrop fashion. Profibus is a field bus, which in this case uses RS-485
as physical media. EC’s continuously monitor the status of the equipment, read various
parameters for their current values, and send this information to concerned Supervisory
Controller on request. There are nearly 100 number of Layer-3 VME stations all around the
Indus-2 machine. The architecture of the Control System is shown in Figure 1.1.

Figure 1.1: Control System Architecture


2.1 VME Bus Fundamentals

VME Bus is a widely used computer bus standard. The VME Bus system is used in industrial,
scientific, commercial and military applications where systems requires a CPU board along with
various kinds of I/O boards to provide certain functionalities. A large variety of VME bus boards
are available to perform a wide range of tasks like data acquisition and control. The VME bus
supports multiple bus Masters & Slaves and high data transfer rates.

VME bus adopts a memory mapped approach. Every device on the VME bus can be viewed as
an address, or block of addresses depending upon how the particular system has been set up.
Data transfer on the VME Bus is asynchronous and this enables modules with a broad variety
response time to be supported.

2.2 Versions of VME bus

The various versions of VME bus is shown in Table 2.1.

Version Year Maximum Speed Maximum Address

(M Bytes/sec) Space (in bytes)
VME-32 1981 40 2^32
VME-64 1994 80 2^64
VME-64x 1997 160 2^64
VME-320 1997 320 2^64
Table 2.1: Versions of VME bus[7]

2.3 Feature of VME-32
Features of VME-32 Bus are given in Table 2.2.

Item Specification Notes

Architecture Master/slave

Transfer mechanism Asynchronous, No central clock used

Addressing range 16 bit (short I/O) Address range selected
24 bit (standard) dynamically
32bit (extended)
Data path width 8,16,24 or 32 bit Data path width selected
Transfer support Yes Compatible with most popular
Error detection Yes Using BERR*(optional)

Data transfer rate 0-40Mbytes/sec

Interrupt level 7 Priority interrupt system with

vector return
Multiprocessing 1-21 processors Flexible bus arbitration
System diagnostic Yes Using SYSFAIL*(optional)
Mechanical standard Single height 160 x 100 mm euro card
Double height 160 x 233 mm euro card
DIN 603-2 connected
International standard Yes IEC 821,IEEE 1014

Table 2.2: VME Bus Features[5]

2.4 VME Bus Architecture

Figure 2.1: Architecture of VME

VME Bus architecture is generally described using a concept of functional modules and it is
shown in Figure 2.1. These functional modules are a conceptual tool. However, in some cases
they also describe actual hardware. Table 2.3 describes all of the functional modules available on
VME Bus.

Functional Module Description

Master A Master module is the one that initiates data transfers between itself and a
Slave A module that does not initiate data transfers. It is a functional module that
detects DTB cycles initiated by a Master and when those cycles specify its
participation, transfers data between itself and the Master.
Location monitor Monitors the DTB and asserts on-board signals if certain addresses are

Bus timer Measures how long a DTB cycle takes.If a cycle takes too long, it asserts
BERR*. It is a type of watchdog timer.

Interrupter Generates interrupt requests.

Interrupt Handler Responds to requests from Interrupters.
IACK Drives the IACK* daisy chain.Usually part of the slot-11 system controller
Daisy-Chain Driver module.

Requester Used to request ownership of the DTB
Arbiter Monitors and grants ownership of the DTB
Table 2.3: Functional modules available on VMEbus[3]

2.5 VME Components

VME chassis: VME chassis forms the basis for the whole VME system. The VME crate or
chassis is where the VME boards are housed. It also contains the backplane and all the elements
such as power supplies, fan-tray etc. that enables the system to run. A typical VME Chassis is
shown in Figure 2.2 below :

Figure 2.2: VME Chassis

There are several elements that are contained within a VME chassis:
 VME bus backplane: The backplane consists of a printed circuit board on which the board
connectors are located.
 VME boards: These are the printed circuit boards that carry the required hardware to
implement the functionality required on the system. They may be any one of the many
forms of boards that have been developed for the VME system. These boards have P1
connector, and may also contain P2 connector when additional I/O capability is needed.
 Slots: The slot is the term for the position where a VME board may be located within the
back-plane. There can be a maximum of 21 slots in a chassis.
 Sub-rack/crate: VME sub-rack is the mechanical frame that supports the backplane and
boards. It also provides card guides, card locks etc., to ensure that the boards and backplane
mate properly. It also contains other entities like power supplies, cooling fans etc.

A VME Master, VME slave and a VME crate are shown in Figure 2.3 :

Figure 2.3 : VME Components[5]

2.6 Functional sub-buses of VME[5]

There are four functional sub-buses on the VME bus backplane to provide the required
functionalities needed:
 Arbitration Bus: It allows an Arbiter module and several Requester modules to coordinate
the use of Data Transfer Bus.
 Data Transfer Bus (DTB): It allows Master boards to transfer the data between themselves
and slave boards.
 Priority Interrupt Bus: It allows Interrupter modules to send interrupt requests to the
various Interrupt Handlers.
 Utility Bus: This bus includes signals that provide periodic timing and coordinate the
power-up and power-down of VME bus systems.

The advantages of the VME bus are that it is able to provide high speed of operation combined
with flexibility and accessibility for development and also running embedded applications. It is
possible to develop custom VME based hardware tailored to meet the user requirements.

Arbitration Bus
This bus allows an Arbiter module and several Requester modules to coordinate use of the DTB.

Bus Busy(BBSY*)
A module controlling the bus will drive the bus busy line (BBSY) low to show that it is in use. It
is driven by Masters and interrupt handlers when they are using the bus. It is an open-collector
class signal.
Bus Clear (BCLR*)
It is driven by the bus arbiter. It is a high current totem-pole class signal.

Bus Request Line(BR0*- BR3*)

These lines are asserted by a requester whenever its Master or interrupt handler needs the
bus .When busy line is not low the arbiter module will sample the bus request lines (BR0-BR3)
looking for a pending action. Requests on BR3 have the highest priority. These are Open -
collector signals.

Bus Grant Line

Requests of equal priority are handled by a daisy chain using the bus grant in lines
(BG0IN*-BG3IN*) and the bus grant out lines (BG0OUT*-BG3OUT*). These are driven by
arbiters and bus requesters. They are standard totem-pole class signals.

Data Transfer Bus

The Data Transfer Bus allows Masters to direct the transfer of binary data between themselves
and slaves. Data Transfer Bus is often abbreviated DTB. The Data Transfer Bus lines can be
grouped into three categories:
Addressing Lines Data Lines Control Lines
A01-A31 D00-D31 AS*
AM0-AM5 DS0*
DS0* DS1*

Addressing Lines

Address (A01-A31)
The address of the register being accessed is present on the address bus (A01-A23). The address
bus A01-A31 is driven by Masters and interrupt handlers. During data transfer cycle, they are
used to broadcast short I/O (16 bit), standard (24 bit) or extended (32 bit) addresses. During
these bus cycles the number of valid address lines is broadcast using the address modifier code

Address Modifier Lines(AM0-AM5)

The address modifier lines (AM0-AM5) indicate the length of the address, the kind of data cycle,
size and type of address transfer and the Master identifier. AM0-AM5 are standard three-state
class signals.

Data Strobe (DS0* and DS1*)

The data strobes (DS0,DS1) are used by the module controlling the transfer (Master) to signal
the presence and acceptance of valid data on the bus.
They serve two purposes:-
-When combined with LWORD* and A01 they indicate the size and type of data
-During a write cycle, they indicate valid data on the data bus and During a read cycle inform a
slave that it should place data onto the data bus. DSO* - DS1* are high current three-state class

Long word LWORD* is driven by Masters. It is used in conjunction with A01, DSO* and DS1*
to indicate the size of the current data-transfer. LWORD* is a standard three-state class signal.

Data (D00-D31)
VMEbus systems can be built with a back-plane configuration that provides either 16 data lines
(D00-D15), or 32 data lines (D00-D31). Back-plane configurations that provide 16 data lines
allow a Master to access only two byte locations simultaneously, while those with 32 data lines
allow up to four byte locations to be accessed.

Control Lines

AS*(Address Strobe)
A falling edge on this line informs all slave modules that the address is stable and can be

DS0*&DS1*(Data Strobe 0 & 1)

In addition to their function in selecting byte locations for data transfer,data strobes also serves
additional functions. On write cycles, the first data strobe failing edge indicates when the Master
has placed valid data on the data bus. On read cycles, the first rising edge tells the slave when it
can remove valid data from the data bus.

BERR*(Bus Error)
BERR* is driven low by the slave or by the bus timer to indicate to the Master that the data
transfer was unsuccessful. For example, if a Master tries to write to a location which contains
Read-Only Memory, the responding slave might drive BERR* low. If the Master tries to access a
location that is not provided by any slave, the bus timer would drive BERR* low after waiting a
specified period.

DTACK*(Data Transfer Acknowledge)

The slave drives DTACK* low to indicate that it has successfully received the data on a write
cycle. On a read cycle, the slave drives DTACK* low to indicate that it has placed data on the
data bus.

WRITE*(Read & Write)

WRITE* is a level significant signal line strobed by the falling edge of the first data strobe. It is
used by the Master to indicate the direction of data transfer operations. When WRITE* is driven
low, the data transfer direction is from the Master to the slave. When WRITE* is driven high, the
data transfer direction is from the slave to the Master.

Priority Interrupt Bus

The Priority Interrupt Bus allows Interrupter modules to send interrupt requests to Interrupt
Handler. The Data Transfer Bus, the Arbitration Bus and the Priority Interrupt Bus are all used in

the process of generating and handling bus interrupts. The Priority Interrupt Bus consists of
seven interrupt request signal lines, one interrupt acknowledge line, and one interrupt
acknowledge daisy-chain.

Interrupt Request Lines(IRQ7-IRQ1)

Interrupter request interrupts by driving an interrupt request line low. In a single handler system,
these interrupt request lines are prioritized, with IRQ7* having the highest priority.

Interrupt Acknowledge Line

Interrupt acknowledge IACK* is driven by interrupt handlers in response to interrupt requests.
In response to an interrupt, an address cycle is generated where the address indicates the request
being acknowledged. IACK* can be either an open-collector or a standard three-state class

Interrupt Acknowledge Daisy-Chain (IACKIN*/IACKOUT)

A daisy chain line, named IACKIN/OUT (Interrupt Acknowledge IN/OUT) is driven by the
IACK daisy chain driver. They are standard totem-pole class signals.

Utility Bus
This bus includes signals that provide periodic timing and coordinate the power-up and
power-down of VMEbus systems. The utility bus is a collection of signals used for system reset,
periodic timing, system diagnostics and power failures. Power is supplied to modules via pins at
+5 V, -12 V and +12 V. An optional battery backup of the +5 V supply (+5 STDBY) can also be

The utility bus supports an independent 16 MHz System Clock (SYSCLK). The frequency of
this clock indicates that 16 Mega cycles per second that the clock wave changes. SYSCLK is
generated by System Clock Driver. It is a high current totem-pole class signal.

The System Reset Line (SYSRESET) is used for initialization or reset the VME bus system. It
asserts by power monitor. It can be driven by any module and indicates that a reset (such as
power-up) is in. It is an open-collector class signal.


The system failure line (SYSFAIL) and AC power failure line (ACFAIL) are bus lines used to
indicate global problems. SYSFAIL* is a utility signal that can be used for system diagnostics. It
indicates that a failure has occurred in the system. ACFAIL* is asserted when the AC line
voltage stops. It is driven by power monitor. When asserted, it signals to all modules that the
system power source is about to stop. It is not used in all VME bus systems. It is an
open-collector class signal.


Additional data transfers can take place along the serial data line (SERDAT) and are
synchronized with the serial clock line (SERCLK). SERCLK is generated by serial clock driver.
The frequency of it depends upon the length of VME bus.

2.7 Application of VME

VME bus is used in a wide variety of applications. Some of the most popular includes:

Industrial controls: Factory automation, robotics, injection molding machines, automotive

body assembly and painting, sawmill controls, metal working, steel manufacturing, cardboard
cutters and many others.

Military: Battlefield command & control systems, ground and flight radar control
systems, tank and gun controls, communications, avionics and many others.

Aerospace: Avionics, fly-by-wire control systems, in-flight video servers, spacecraft experiment
control, missile countdown sequencers, and many others. In 1998 the Mars Pathfinder used a
VME bus computer to control spacecraft 9 operation on the planet Mars.

Transportation: Railway controls, smart highway systems and light-rail transit systems.

Telecom: Advanced intelligent node (AIN) switch gear, cellular telephone base stations, satellite
up-link and down-links and telephone switches. VME bus live insertion capabilities were also
designed for this application.

Simulation: Aircraft flight, earthquake, metal fatigue and various military simulation systems.

Medical: CATSCAN imaging, MRI imaging and various acoustical systems.

High Energy Physics: Particle accelerators, particle detectors.

System Components

3.1 Features of VME based Profi Communication Board

The Profi communication board is designed around a microcontroller. Following are the main
features of this board:

 Microcontroller Dallas 89C420 operating at 24 MHz.

 6KB EPROM for firmware and 16KB SRAM for Data Storage.
 16KB Shared-RAM that us shared between Profi Bus controller and VME Bus.
 Two asynchronous serial ports,one supporting communication over RS 232 and baud rate
programmable from 1.2K to 19.2K. Other port is user selectable either RS-232C or RS-485
and supports baud rates from 9.6K to 750K.
 Capable of Interrupting VME Master at levels 1,2,4 or 5 which is jumper selectable
 Configurable vector number through DIP switches.
 The Microcontroller can be interrupted by VME Master.
 1K bit serial EEPROM for parameter storage

Figure 3.1 : Block Diagram of Profi Communication board

3.2 Features of Microcontroller 89C420
The DS89C420 is one of the high speed flash microcontrollers. It featured a redesigned
processor core that executes 8051 instructions up to 12 times faster than the original for the same
crystal speed.

Key Features:
 80C52 Compatible
> 8051 Pin and Instruction-Set Compatible
> Four Bidirectional I/O ports
> Three 16 Bit Timer Counters
> 256 Bytes Scratchpad RAM

 On-Chip Memory
>16KB Flash Memory
>In-system Programmable through Serial Port

 ROM Size Feature

>Selects Internal Program Memory Size from 0 to 16K
>Allows access to entire External Memory Map
>Dynamically Adjustable by Software

 High Speed Architecture

> 1 Clock per Machine Cycle
> DC to 33MHz
> Single -Cycle Instruction in 30ns.
> Dual Data pointers with Auto Increment/Decrements and Toggle Select

 Power Management Mode

 Two Full-Duplex serial ports
 Programmable Watchdog Time
 13 Interrupt Sources (six external)

 Five Levels of Interrupt Priority
 Power fail Reset
 Early Warning Power-Fail Interrupt

3.3 Arduino MEGA 2560

Arduino is an open-source electronics platform based on easy-to-use hardware and software.
Arduino boards are able to read inputs and turn it into an output. The ATmega2560 is a
low-power CMOS 8-bit micro-controller based on the AVR enhanced RISC architecture. By
executing powerful instructions in a single clock cycle, the ATmega2560 achieves throughput
approaching 1 MIPS per MHz allowing the system designer to optimize power consumption
versus processing speed. Arduino Mega2560 is shown in Figure

Figure 3.2: Arduino Mega 2560[11]

The ATmega 2560 provides the following feature:-

 It has 256 bytes(of which 8KB used by boot-loader) of In-System Programmable Flash with
Read-While-Write capabilities
 4Kbytes EEPROM
 8Kbytes SRAM
 16MHz crystal
 ICSP Header
 USB Connection
 16 Analog inputs
 54 input/output pins

 32 general purpose working registers
 4 USARTs (Universal Synchronous Asynchronous Receiver and Transmitter
 16channel,10 bit ADC
 Programmable watchdog timer

The board can operate on an external supply of 6 to 20 volts. If supplied with less than 7V,
however, the 5V pin may supply less than than five volts and the board may become unstable. If
using more than 12V, the voltage regulator may overheat and damage the board. The
recommended range is 7 to 12 volts. The power pins are as follows:
 Vin. The input voltage to the board when it's using an external power source (as opposed to
5 volts from the USB connection or other regulated power source). User can supply voltage
through this pin, or, if supplying voltage via the power jack, access it through this pin.
 5V. This pin outputs a regulated 5V from the regulator on the board. The board can be
supplied with power either from the DC power jack (7 - 12V), the USB connector (5V), or
the VIN pin of the board (7-12V).
 3V3. A 3.3 volt supply generated by the on-board regulator. Maximum current draw is 50
 GND. Ground pins.
 IOREF. This pin on the board provides the voltage reference with which the microcontroller
operates. A properly configured shield can read the IOREF pin voltage and select the
appropriate power source or enable voltage translators on the outputs for working with the
5V or 3.3V.

Input and Output

Each of the 54 digital pins on the Mega can be used as an input or output, using pinMode(),
digitalWrite(), and digitalRead() functions. They operate at 5 volts. Each pin can provide or
receive 20 mA as recommended operating condition and has an internal pull-up resistor
(disconnected by default) of 20-50k ohm.

In addition some pin have specialized functions:
 Serial :
PIN 0 (RX) and PIN 1 (TX); Serial 1: PIN 19 (RX) and PIN 18 (TX); Serial 2: PIN 17 (RX) and
PIN 16 (TX)Serial 3: PIN 15 (RX) and PIN 14 (TX).

 External Interrupts :
PIN 2 - interrupt 0 PIN 3 - interrupt 1 PIN 18 - interrupt 5
PIN 19- interrupt 4 PIN 20 -interrupt 3 PIN 21 - interrupt 2
These pins can be configured to trigger an interrupt on a low level, a rising or falling edge, or a
change in level.

The SPI (Serial peripheral Interface) bus is a synchronous serial communication interface used
for short distance communication. SPI devices communicate in a full duplex mode using a
Master slave architecture with a single Master. The Master device originates the frame for
reading and writing. Multiple slave devices are supported through selection with individual slave
select (SS) lines.
PIN 50: Master In slave Out(MISO)
PIN 51: Master Out slave In(MOSI)
PIN 52: Serial Clock,Output from Master(SCK)
PIN 53: slave Select(SS)

There are couple of additional pins on the board:

 AREF: reference voltage for the analog inputs.
 Reset: Bring this line LOW to reset the microcontroller.

The Arduino Mega has a number of facilities for communicating with a computer. FTDI (Future
Technology Devices International) FT232RL on the board channels one of the UART over USB
and the FTDI drivers (included with Arduino software) provide a virtual COM port to software
on the computer. The Arduino software includes a serial monitor which allows simple textual
data to be sent to and from the Arduino board. The RX and TX LEDs on the board will flash

when data is being transmitted via the FTDI chip and USB connection to the computer (but not
for serial communication on pins 0 and 1).

The Mega 2560 board can be programmed with the Arduino Software (IDE). The ATmega2560
on the Mega 2560 comes preprogrammed with a bootloader that allows user to upload new code
to it without the use of an external hardware programmer. It communicates using the original
STK500 protocol. User can also bypass the boot-loader and program the microcontroller through
the ICSP (In-Circuit Serial Programming) header using Arduino ISP.

Shield Compatibility
The Mega is designed to be compatible with most shields. Digital pins 0 to 13 (and the adjacent
AREF and GND pins), analog inputs 0 to 5, the power header, and ICSP header are all in
equivalent locations. Further the main UART (serial port) is located on the same pins (0 and 1),
as are external interrupts 0 and 1 (pins 2 and 3 respectively). SPI is available through the ICSP

3.4 Ethernet Shield W5100

The Arduino Ethernet Shield connects Arduino to the internet. It is shown in Figure 3.3. It is
based on Wiznet W5100 Ethernet chip. The Wiznet W5100 provides a network (IP) stack
capable of both TCP and UDP. It supports up to four simultaneous socket connections. Using
Ethernet library user can write sketches which connect to the internet using the shield. The
Ethernet shield connects to an Arduino board using long wire-wrap headers which extend
through the shield. This keeps the pin layout intact and allows another shield to be stacked on
top. The latest version includes micro-SD card slot, which can be used to store files for serving
over the network, and reset controller, to ensure that the W5100 Ethernet module is properly
reset on power-up.

Figure 3.3: Ethernet Shield W5100[11]

Arduino communicates with both the W5100 and SD card using the SPI bus (through the ICSP
header). This is on digital pins 50, 51, and 52 on the Mega.Pin 10 is used to select the W5100
and pin 4 for the SD card. These pins cannot be used for general I/O. On the Mega, the hardware
SS pin, 53, is not used to select either the W5100 or the SD card, but it must be kept as an output
or the SPI interface won't work. Note that because the W5100 and SD card share the SPI bus,
only one can be active at a time. In case of using both peripherals in program, this should be
taken care of by the corresponding libraries. If one of the peripherals is not being used, however,
it should be explicitly deselected. To do this with the SD card, set pin 4 as an output and write a
high to it. For the W5100, set digital pin 10 as a high output. The shield provides a standard
RJ45 Ethernet jack. Reset button on the shield reset both the W5100 and the Arduino board.

The shield contains a number of informational LEDs:

 PWR: indicates that the board and shield are powered
 LINK: indicates the presence of a network link and flashes when the shield transmits or
receives data
 FULLD: indicates that the network connection is full duplex
 100M: indicates the presence of a 100 Mb/s network connection (as opposed to 10 Mb/s)
 RX: flashes when the shield receives data
 TX: flashes when the shield sends data
 COLL: flashes when network collisions are detected

3.5 Microcontroller P89V51RD2

3.5.1 Features of Microcontroller

The P89V51RB2/RC2/RD2 are 80C51 microcontrollers with 16/32/64 kB flash and 1024 B of
data RAM. ISP allows a device to be reprogrammed in the end product under software control.
The capability to field/update the application firmware makes a wide range of applications
possible. The P89V51RD2 is also In-Application Programmable (IAP), allowing the Flash
program memory to be reconfigured even while the application is running.

3.5.2 Block Diagram

Figure 3.4: Block diagram of P89V51RD2[8]

Functional description of the block diagram is as under:

 Flash provided in this controller can be programmed in both ways :
In-System Programmable and
In-Application Programmable
 All 8051 microcontrollers have four I/O ports each comprising 8 bits which can be
configured as inputs or outputs. Accordingly, in total of 32 input/output pins enabling the
microcontroller to be connected to peripheral devices are available for use.
 Oscillator works around 12MHz.

 The main criteria for UART communication is its baud rate. Both the devices Rx/Tx should
be set to same baud rate for successful communication. For the 8051 the Timer 1' is used to
generate the baud rate in Auto reload mode.
 The Serial Peripheral Interface (SPI) allows high-speed synchronous data transfer
between the P89V51RD2 and peripheral devices or between several P89V51RD2 devices.
 It has two 16 bit registers Timer0 and Timer1 which can be configured to operate either as
timers or event counters.
 Timer2 is a 16bit Timer/Counter which can operate as either an event timer or an event
counter as selected by bit in T2CON register. Timer 2 has four operating modes:
>Auto Reload
>Baud Rate Generator

 PCA (Programmable Counter Array) includes a special 16-bit timer that has five 16-bit
capture/compare modules associated with it. Each of the modules can be programmed to
operate in one of four modes: rising and/or falling edge capture, software timer, high-speed
output, or pulse width modulator.
 It has programmable Watchdog timer (WDT) for fail safe protection against software
deadlock. WDT is a hardware timer that automatically generates a system reset if the main
program neglects to periodically service it.

3.5.3 Memory Organization of P89V51RD2

The device has separate address spaces for program and data memory.

 Flash Program Memory: There are two internal flash memory blocks in the device. Block
0 has 64 kB and contains the user’s code. Block 1 contains the Philips-provided ISP/IAP
routines and may be enabled such that it overlays the first 8 kB of the user code memory.
The 64 KB Block 0 is organized as 512 sectors, each sector consists of 128 bytes.Access to
the IAP routines may be enabled by clearing the BSEL bit in the FCF register. However,
caution must be taken when dynamically changing the BSEL bit. Since this will cause
different physical memory to be mapped to the logical program address space, the user must

avoid clearing the BSEL bit when executing user code within the address range 0000H to

 Data Ram Memory:The data RAM has 1024 bytes of internal memory. The device can also
address up to 64 KB for external data memory.

Implementation of Ethernet Support

4.1 Present Scheme

There are multiple VME stations in the field which acquire data from the sensors and other
devices placed in the field. The aim is to send field data to the control room PC’s. In the present
scheme, Profi slave boards are used at various VME stations for communication. The Profi
slaves boards are based on 89C420 microcontroller and do not have Ethernet support. In order to
send data to a remote PC, the slave stations are first connected to a Profi master station over
multidrop RS-485 cable. Profi Master station has Motorola 68040 based CPU board which has
Ethernet support. This board then communicates with the remote PC over Ethernet link. This
scheme is depicted in Figure 4.1. The communication speed over Profi bus is 750Kbps.

Figure 4.1 : Block Diagram of Present Scheme

In this scheme command-response method is used for communication between master and its
slaves. When the master wants to poll data from a particular slave, it send a polling command
and in the reply slave sends the data. In order to set a parameter, the master sends a setting
command to the particular slave and the slave responds with an acknowledgment. There can be
maximum of 32 slaves which can be connected over RS-485 link.

4.2 Schematic of Profi slave
The block diagram of the Profi slave station is shown in Figure 4.2 :

Figure 4.2: Block Diagram of Profi Slave station

CPU and Profi Controller boards communicate with each other with the help of Shared RAM.

4.3 Approach towards new Design

In order to provide the Ethernet support feature, there can be two possible approaches:
-Design a new CPU board
-Provide features on slave Board
The first approach of designing a new CPU board, would have been a time intensive task as it
would have involved modifications in the Operating System. Therefore, we have adopted the
approach of providing these features on a slave board. Again, there were two alternatives in
providing features on a slave board:
-Design new slave board
-Modify existing slave having features of VME I/O and Communication
In designing a new slave board, time and more complexity could have involved therefore we
opted for modifying an existing slave which has basic features of VME I/O and communication.

4.4 New Scheme
In the new scheme Microcontroller present on board has been replaced with Arduino Mega 2560
as shown in Figure 4.3. In this scheme Arduino mimics the function of microcontroller.

Present Scheme New Scheme

Figure 4.3 : Modification from Current Scheme to new Scheme

An add-on Ethernet Shield W5100 has been placed over Arduino board to provide
communication over Ethernet(UDP/TCP). Shield is a term which is used in Arduino parlance to
refer to an add-on board. The scheme of this set up is shown in Figure 4.4.

Figure 4.4 : Set up of New Scheme

The existing microcontroller 89C420 was removed from its socket and with the help of 32
jumper wires, Arduino Mega 2560 is placed in its position.

4.5 Working of New Scheme in Field

With these modifications , these boards when used at VME stations can now directly send their
data to remote PC over Ethernet network. These stations are connected to network switch with
the help of Ethernet link. The Scheme is depicted in Figure 4.5.

Figure 4.5: Working of new Scheme

4.6 Communication between CPU and Controller

CPU communicates with controller with the help of Shared RAM. Shared RAM is logically
divided into three sections as shown in Figure 4.6.

Shared RAM

Figure 4.6: Communication between CPU and Controller

The CPU writes the data to be sent on UDP in the ‘Transmit Section’ of shared RAM . It then
interrupts Arduino by writing in the ‘Interrupt Section’. As a response to that interrupt Arduino

reads that data from SRAM and after verifying the checksum sends the data over UDP using
Ethernet link. Accordingly Arduino tells the CPU by writing in the Status section that the data
has been sent and if not, then the reason behind it i.e. whether the checksum was wrong or the
required number of bytes could not be sent.

When a packet is received on the UDP, Arduino extracts data from the packet, generates
checksum, writes in the ‘Receive Section’ of shared RAM and interrupts the CPU board by
raising an interrupt on a VME interrupt line.

Software Development

5.1 Communication of VME with PC

The VME CPU board communicates with PC through RS-232 link. Command and Data is send
from PC with the help of hyper-terminal(serial emulator). Figure 5.1 shows the communication
between PC and VME.

Figure 5.1: Communication between PC and VME over RS-232

When VME CPU is powered up it displays an initial message on the hyper-terminal screen.With
the help of RomBug Prompt and CW (change word) command user can write at different
memory location of shared RAM of VME slave board. Initially all the memory location have
FFFF stored. This can be modified and desired value or data can be written in the various section
of share RAM. In Figure 5.2 screen shot of Hyper-terminal is shown.

Figure 5.2: Screen shot of Hyper-terminal

5.2 Accessing Arduino’s Input and Output ports:
The Microcontroller on Arduino board has various ports. A port has multiple pins, thus, in order
to change the setting of one port, port pins of that corresponding port are required to be changed.
To change setting for one single pin of the port, change in particular bit in associated register is

Arduino Mega2560 has an 8-bit microcontroller. All of its ports are 8 bit wide. Every port has
three registers associated with it, each 8-bit wide. Every bit in these registers configure pins of
particular port. The registers are as follows:
(1) DDR register
(2) PORT register
(3) PIN register

(1) DDR Register:

DDR (Data Direction Register) configures data direction of port pins. Its setting determines
whether port pins will be used for input or output. Writing 0 to a bit in DDR makes
corresponding port pin as input, while writing 1 to a bit in DDR makes corresponding port pin as
To make all pins of port A as input pins :
DDRA = 0b00000000;
To make all pins of port A as output pins :
DDRA = 0b11111111;
To make lower nibble of port B as output and higher nibble as input :
DDRB = 0b00001111;

(2) PIN Register:

PIN (Port IN) used to read data from port pins. In order to read the data from port pin, first port’s
data direction is changed to input. This is done by setting bits in DDR to zero. If port is made
output, then reading PIN register will give data that has been output on port pins.
There are two input modes. Either use port pins as tri stated inputs or they can be used to
activate internal pull up.

Example :
To read data from port A.
DDRA = 0x00; //Set port a as input
x = PINA; //Read contents of port a

(3) PORT Register:

PORT is used for two purposes.

(i) To output data , when port is configured as output :

By setting bits in DDR to 1, corresponding pins becomes output pins. Now data can be
written into respective bits in PORT register. This will immediately change state of output
pins according to data written. In other words to output data on to port pins, user have to
write it into PORT register. However do not forget to set data direction as output.

Example :
To output 0xFF data on Port B
DDRB = 0b11111111; //set all pins of port b as outputs
PORTB = 0xFF; //write data on port

To output data in variable x on Port A

DDRA = 0xFF; //make port a as output
PORTA = x; //output variable on port

To output data on only 0th bit of Port C

DDRC = 0b00000001; //set only 0th pin of port c as output
PORTC = 0b00000001; //make it high.

(ii) To activate/deactivate pull up resistors – when port is configured as input

By setting bits in DDR to 0, i.e. make port pins as inputs, then corresponding bits in
PORT register are used to activate/deactivate pull-up registers associated with that pin. In
order to activate pull-up resister, set bit in PORT to 1, and to deactivate (i.e to make port pin
tri stated) set it to 0.

In Input mode, when pull-up is enabled, default state of pin becomes ‘1’. Even if user don’t
connect anything to pin and if try to read it, it will read as 1. On externally driving that pin to
zero(i.e. connect to ground / or pull-down), only then it will be read as 0.

However, if pin is configure as tri-state. Then pin goes into state of high impedance. We can say,
it is now simply connected to input of some operational amplifier inside the microcontroller and
no other circuit is driving it from microcontroller. Thus pin has very high impedance. In this case,
if pin is left floating (i.e. kept unconnected) then even small static charge present on surrounding
objects can change logic state of pin.
Thus while, taking inputs from pins always enable pull-up resistors on input pins. While using
on-chip ADC, ADC port pins must be configured as tri-stated input.

Example :
To make Port A as input with pull-ups enabled and read data from port a
DDRA = 0x00; //make port a as input
PORTA = 0xFF; //enable all pull-ups
y = PINA; //read data from port a pins

To make Port B as tri stated input

DDRB = 0x00; //make port b as input
PORTB = 0x00; //disable pull-ups and make it tri state

To make lower nibble of Port A as output, higher nibble as input with pull-ups enabled
DDRA = 0x0F; //lower nib> output, higher nib> input
PORTA = 0xF0; //lower nib> set output pins to 0,
//higher nib> enable pull-ups

5.3 Arduino Programming
Since, Arduino is required to mimic various functions of the previously placed microcontroller,
the Arduino board has been programmed to generate the timing sequence of following signals :
ALE: Address Latch Enable
RD*: Read Strobe
WR*: Write Strobe
AD0-AD7: Multiplexed low-order Address bus and Data bus
A8-A15: Higher Order Address bus

5.3.1 Pin Mapping

Table 5.1 shows how the different signals of Microcontroller 89C420 are mapped to the signals
of Arduino board. This has been achieved by placing jumper wires between the microcontroller’s
socket and the Arduino board
Signal Microcontroller DS89C420 Arduino MEGA2560

Address/Data Bus Port (P0.0-P0.7) Port (PA0-PA7)

EA* Pin 31 Vcc

PSEN* Pin 29 Vcc
Address Bus Port(P2.0-P2.7) Port(PC0-PC7)
READ P3.7 Port PG1
WRITE P3.6 Port PG0
ALE Pin 30 Port PG2
P3.2 Interrupt0
P1.5 Interrupt5
P1.6 Interrupt4
P1.7 Interrupt3
P1.1 Pin21-Interrupt
Table 5.1: Pin Mapping

5.3.2 Read Cycle:

Signaling sequence of Read cycle generated by microcontroller DS89C420 is depicted in
Figures 5.3. This has been programmed in the Arduino so that it can perform the read operation
on the existing base board designed around 89C420:

Figure 5.3: Signaling sequence of Read Cycle

5.3.3 Write Cycle:

Signaling sequence of Write cycle generated by microcontroller DS89C420 is depicted in
Figures 5.4. This has been programmed in the Arduino so that it can perform the write operation
on the existing base board designed around 89C420:

Figure 5.4: Signaling sequence of Write Cycle

In 8051 we have multiplexed Address and Data bus. AD0-AD7 carries Address A0-A7 when
address is sent and it carries Data D0-D7 when data is sent. When ALE goes HIGH, lower order
byte of address is latched on AD0-AD7 and when ALE goes LOW, data is latched on AD0-AD7.
Accordingly Read and Write strobes are signaled.

5.3.4 Bus Grant Routine

Initially, the control of the bus which is used to access shared RAM is with controller on board.
If VME CPU wants to read and write on shared RAM then it requests controller (VMEREQ) for
bus grant (BG) and if controller grants bus to it then it sent acknowledgment (BACK) to
controller. These signals VMEREQ, BG and BGACK is depicted in Figure 5.5 and 5.6.

Figure 5.5: VMEREQ and BG signal on Scope

Figure 5.6: VMEREQ and BGACK signal on Scope

5.4 UDP Packet Format :

UDP is a connectionless transport protocol. It performs limited error checking. UDP is simple
protocol using a minimum of overhead. If a process wants to send a small message it can use
UDP. Sending a small message by using UDP takes much less interaction between the sender
and receiver than using TCP. UDP packets, called ‘user datagrams’ have a fixed size header of
8-bytes. Figure 5.7 shows the format of a user datagram.

Figure 5.7:User Datagram format

The fields are as follows:

 Source port number: This is the port number used by the process running on the source
host.It is 16-bit long, which means that the port number can range from 0 to 65,535.
 Destination port number: This is the port number used by the process running on the
destination host. It is also 16-bits long.
 Length: This is a 16-bit field that defines the total length of the user datagram, header plus
 Checksum: This field is used to detect errors over the entire user datagram (header plus

5.5 Sending and Receiving Packets via UDP
Ethernet Shield and Arduino is used to send and receive packets via UDP protocol (Universal
Datagram Packet). Ethernet library is required to be installed. These libraries are designed to
work with the Arduino Ethernet Shield (using Ethernet.h). The libraries allow an Arduino board
to connect to the network. The libraries support up to four concurrent connection (incoming or
outgoing or a combination). Arduino communicates with the shield using the SPI bus. On the
Mega, the hardware Pin-53 SS (slave select), must be kept as an output or the SPI interface
won't work.

Note:The SPI library only works in Master mode, so the SS pin has to be set as an output. Even
when not using the SS pin it has to left in output because if it ever becomes input, that puts the
chip into slave mode.

Following functions of Ethernet library have been used in the development of code:

 Ethernet.begin(mac, ip)
It will initialize the Ethernet library and network settings.
mac: The MAC (Media access control) address for the device (array of 6 bytes).
This is the Ethernet hardware address of Shield.
ip: the IP address of the device (array of 4 bytes).

 Ethernet.localIP()
Obtains the IP address of the Ethernet shield. It returns the IP address.

 IPAddress(address)
Defines an IP address. It can be used to declare both local and remote addresses.

 EthernetUDP.begin(localPort)
Initializes the Ethernet UDP library and network settings

 UDP.parsePacket();
Checks for the presence of a UDP packet, and reports the size.

, MaxSize)
Reads UDP data from the specified buffer. If no arguments are given, it will return the next
character in the buffer.
packetBuffer: buffer to hold incoming packets (char)
MaxSize: maximum size of the buffer (int)

5.6 Software Scheme

The flowchart of program developed for Arduino is shown in Figure 5.7.

Figure 5.8: Flowchart of Software scheme

At the start, all the required ports are configured as input or output by writing 0 or 1 respectively
and interrupts are configured. After this the program enters a wait loop.

When a UDP packet arrives,it is stored in a buffer and Arduino comes out of the wait state. After
receiving packet in the buffer, data is extracted from the packet and checksum is generated.
Arduino writes checksum in the shared RAM and interrupts VME CPU.

The VME CPU writes in shared RAM and generates an interrupt to Arduino by writing in the
Interrupt section. As a response to that interrupt Arduino comes out of the wait loop and reads

data from shared RAM and after verifying the checksum, the data is sent over UDP using
Ethernet link. In the background, Bus Grant routine is also running which grants bus to CPU to
write data on to shared RAM. Initially the control of the bus is with microcontroller and VME
CPU requests controller for accessing the bus.

Figure 5.8 shows how this UDP packet is stored in the shared RAM. In the first location total
number of bytes received is stored. In the subsequent locations bytes received are stored
followed by the checksum of the bytes received which is simply the addition of all the bytes

Figure 5.9: UDP packet in RAM

5.7 Packet Sender Utility

Packet Sender is an open source utility to allow sending and receiving TCP and UDP packets.
Packet Sender supports mixed ASCII and HEX notations in Figure 5.8 is a screen-shot showing
the packets being sent from the utility.

Figure 5.10: Screen-shot of Packets sent from utility

In the address and port field the IP address and port number of the Ethernet Shield is given. Then
which type of packet is required to be sent is selected. The packet received by Arduino is seen on
the serial monitor of Arduino.

Implementation of In-Application Programmable

6.1 Overview of the scheme

In VME based systems a need was felt to provide a support of storing certain system parameters
in a non-volatile storage so that they are available at the system start-up without needing them to
be downloaded from an upper layer. Also it was desired to have the flexibility of changing these
parameters without needing to shut down the system.

The next purpose of the project is to develop a suitable firmware to provide non volatile data
storage using In Application Programming (IAP) support on a VME based board. For this an
existing Profi communication board has been chosen on which microcontroller 89C420, placed
on the board, has been replaced with another microcontroller 89V51RD2 that supports IAP flash.
API’s for reading and writing to flash has been developed that provides an interface at VME
level using custom development protocol to facilitate flash reading and writing.

6.2 Characteristic of FLASH in P89V51RD2[6,8]

Memory Architecture is basically divided into two categories
 Von Neumann Architecture - They have shared signals and memory for code and data.
 Harvard Architecture - It has physically separate signals and storage for code and data
The code memory FLASH in P89C51RD2 consists of two big blocks:

- Block0, 64kB, mapped at 0000h-FFFFh, intended to run the "normal" user application.
- Block1, 8kB, mapped at 0000h-1FFFh, containing the boot-loader.

There are three methods of erasing or programming the Flash memory. First, the Flash may be
programmed or erased in the end-user application by calling low-level routines through a
common entry point (IAP). Second, the on-chip ISP boot loader may be invoked. This ISP boot
loader will, in turn, call low-level routines through the same common entry point that can be

used by the end-user application. Third, the Flash may be programmed or erased using the
parallel method by using a commercially available EPROM programmer which supports this

When the micro controller programs its own Flash memory, all of the low level details are
handled by code that is contained in a Boot block that is separate from the user Flash memory. A
user program calls the common entry point in the Boot block with appropriate parameters to
accomplish the desired operation. Boot block operations include erase user code, program user
code, program security bits, etc.

In-application programming (IAP) of Block0 FLASH in P89V51RD2 is performed through

setting up a couple of registers, and making a call to a predetermined address -1FF0h- in Block1.
This, and a list of possible operations, listed in Table 6.1, together with the related registers can
be performed.

IAP Function IAP Call Parameters

Read Id Input Parameters:

R1 = 00h
DPH = 00H
DPL = 00H = mfgr id
DPL = 01H = device id 1
DPL = 02H = ISP version number
DPL = 03H = IAP version number

Return parameter(s):
ACC = requested parameter

Erase Block 0 Input parameters:

R1 = 01h

Return parameter(s):
ACC = 00 = pass

Program User Code Input parameters:
R1 = 02h
DPH = memory address MSB
DPL = memory address LSB
ACC = byte to program

Return parameter(s):
ACC = 00 = pass
Read User Code Input parameters:
R1 = 03h
DPH = memory address MSB
DPL = memory address LSB

Return parameter(s):
ACC = device data
Program Security Bit, Input parameters:
Double Clock R1 = 05h
DPL = 01H = security bit
DPL = 05H = Double Clock

Return parameter(s):
ACC = 00 = pass
Read Security Bit, Double Input parameters:
ACC = 07h
Return parameter(s):
ACC = 000 S/N-match 0 SB 0 DBL_CLK
Table 6.1: IAP function calls[8]

6.3 ISP vs IAP

When it comes to re-programming Flash memory there are two programming methods: ISP and

ISP: In-System Programming

ISP allows for re-programming of a Flash memory device while it is soldered into the target
hardware. However, the application needs to be stopped during the re-programming process.
Usually, ISP requires that a service technician manually starts the re-programming procedure by
halting the application and setting it into a special boot and/or programming mode. Only after

programming is completed, the application can be restarted.

IAP: In-Application Programming

IAP allows for re-programming of a Flash memory device while it is soldered into the target
hardware and while the application code is running. With IAP it is possible to implement
applications that can be re-programmed remotely without the need of a service technician to
actually be present. In IAP microcontroller fetches new program code and reprogram itself while
in system.

Several In-Application Programming (IAP) calls are available for use by an application program
to permit selective erasing, reading and programming of Flash sectors, pages, security bit,
configuration bytes, and device id.

With on-chip Flash, IAP is only possible if supported by the micro-controller. The Philips
89V51Rx2 parts support IAP also via the boot loader. The application code can call functions in
the boot loader area by loading parameters into the registers R0, R1 and DPTR and then calling
a specific address in the boot loader. To make these functions easier to use, the Embedded
Systems Academy provides a C library supporting all boot loader functions. This allows erasing
and programming directly from the C level, simply by calling C functions.

6.4 Approach towards Firmware development

Since, it is required to provide Read and Write features in Flash from VME, we have used 10
sectors of 128 bytes each. Therefore, a total of 1280 bytes of memory in flash is available. If it is
required to modify a single or multiple locations then, complete sector(s) in which the device is
located is first erased then backup of the whole sector is taken along with the modified data and
then whole backed up data is written into sector.

While backing up data, address of location and the sector number at which the location is present,
is required to be calculated. Sector number is calculated by dividing the location number with
size of sector and on the other hand, address is calculated by adding the starting address with
location number. Flowchart describes the flow of code running inside controller.

Figure 6.1: Flowchart of Firmware running on P89V51RD2

Description of Flowchart
Initialization and declaration of header files and variables-: Header files included in the code are
defined as under:

<stdio.h>This header file incorporates the standard input output function like scanf,printf
etc.”stdio.h” is a file that has commands for the preprocessor. Preprocessing in simple terms is
the process done before handing over the control to compiler. Preprocessing commands begin
with #.

<absacc.h>This includes files contains definition for macros that allows one to directly access
the different memory areas of 8051. XBYTE is a part of header file. XBYTE macro access
individual bytes in the external data memory of 8051.

<P89C51RD2.h> This header file defines specific address for all Special Function Register and

<iap.h> It is header file for iap.asm, implementing IAP core function for P89V51RD2

<iap_c.h> This includes IAP function call for function like erasing of sectors and writing of
Bus grant routine running in the background is discussed in previous section 5.3.4 under the
heading of Bus Grant Routine.

After declaring header files controller will wait for the interrupt from VME. Interrupt from VME
is generated by writing at a specific memory location in shared ram (198000) on pin 5 of Port1
of micro-controller.

With the occurrence of interrupt, Interrupt Service Routine is invoked. Controller reads 4 bytes
from Shared RAM. Out of those bytes starting two bytes tells the address number followed by
command and data each of 1byte at the successive memory locations.

Upon checking the command accordingly action will be initiated.

If command =01: Write operation will be processed.

Structure of Write command is shown in Figure6.2

Figure 6.2: Structure of Write Command

Steps for Write operation:
1. Sector number is calculated
2. Sector backup is taken with new data
3. Erase sector using IAP system call
4. Write the backed up data to the sector

Flowchart of Write command is shown in flowchart shown below in Figure8.3.

Figure 6.3: Flowchart of Write operation

If command =02: Read operation will be processed
Structure of Read command is shown in Figure6.4.

Figure 6.4: Structure of Read Command

Step for Read operation:
1. Address number which was accessed earlier from Shared RAM, that address number location
is read from internal flash.
Flowchart of Read command is shown in flowchart shown below in Figure8.4

Figure 6.5: Flowchart of Read operation

If command =03: Multiple Read operation will be processed.

Structure of Multiple Read command is shown in Figure6.6.

Figure 6.6: Structure of Multiple Read Command

If command =04: Multiple Write operation will be processed.

Structure of Multiple Write command is shown in Figure6.7.

Figure 6.7: Structure of Multiple Write Command

In the multiple write command, after specifying number of locations to be written, at the
subsequent addresses data which is required to be written is given.

After this as a verification, one can read specific memory location of SRAM on which address
number will be stored and as an acknowledgment “inverted command” and data is written on
successive memory location.

6.5 Software Tools

Keil uVision IDE

 uVision IDE(Integrated Development Environment) allows developers to create embedded
applications using the Keil development tools.
 Integrates a project manager(to create and maintain projects), make utility (for
assembling,compiling and linking embedded applications), source code editor, debugger and
simulator into one environment.

Figure 6.8: Screen-shot of Keil uvision2
Flash Magic
A tool for programming flash based micro-controller.

Figure 6.9: Screen-shot of Flash Magic


7.1 Testing of Ethernet Support on VME base board

The complete setup of VME with Arduino Mega 2560 and Ethernet Shield W5100 is shown in
Figure 6.1. With the help of jumper wires Arduino is connected to the socket of microcontroller
on the base board.

Figure 7.1: Communication Board with Ethernet support

Reading from and writing to shared RAM by VME CPU was tested. This utilizes Bus request &
Bus grant functions implemented in the code. Figure 6.2 and 6.3 shows signals (VMEREQ, BG,

BACK) generated programmatically on Arduino with the help of which Reading and Writing on
SRAM is done successfully.

With the help of Packet Sender Utility, UDP packets were sent. These packets sent over UDP are
received by Arduino and can be seen on serial monitor as shown in Figure 6.4. Upon receiving a
packet, Arduino writes the data along with calculated checksum in shared RAM and generate an
interrupt for VME CPU.

Figure 7.2: Packets received on Arduino(seen on serial monitor)

VME CPU writes data in RAM and interrupt Arduino. Arduino reads the data, verifies the
checksum and sends a UDP packet over the network. This Packet is seen on Packet Sender
Utility. This can be seen in Figure 6.5.

Figure 7.3: Packets received over Utility

7.2 Testing of In-Application Programmable Storage on VME base board

Commands for reading and writing flash is given through hyperterminal application on PC.
Structure of Read and Write command has been discussed earlier in section 9.1. In order to test
the designed firmware, some location from the flash of microcontroller were read and written
with the help of commands through hyperterminal.

Again those location were modified by writing some data at those locations,again by giving the
command through hyperterminal. It was found that the data was modified successfully. When
VME was powered OFF, and made again ON, it was found that the modified data was present in
the memory. Hence, provision for non volatile data storage was given to existing VME slave.

In Figure 10.1 IAP Read test is verified. At 19D004 address, location number which is required
to be read is given, for testing purpose it is 0000. In the next location i.e 19D006, 02 is written

Figure 7.4: IAP Read Test

which is command for reading a memory location from microcontroller. After this, Interrupt is
given by writing in the Interrupt section of Shared RAM i.e. at 198000. For verifying IAP read
has been done or not, Response section of Shared RAM is read. In Response section, at 19E004,
location which is read is present and as an acknowledgment for read, inverted command i.e. 20
is written at 19E006. Data present at location 0000 is read and stored at location 19E007 i.e.78.

Figure 7.5: IAP Write Test

In Figure 10.2 IAP Write test is verified. For testing the Write routine of IAP, first the location
for which write operation is to be performed, is read by following the previously discussed steps.
For testing of location 0078, it is read first and was found 78 is written at the location. At
19D004 location for which data is to be modified is written i.e 0078. At the next location
19D006 command for write operation is written i.e. 01 followed by the new data which is
required to be written at the location. After this, Interrupt is given by writing in the Interrupt
section of Shared RAM i.e. at 198000. In Response section, at 19E004, location which is read is

present and as an acknowledgment for write, inverted command i.e. 10 is written followed by
the new data at the location i.e 47.

Total 10 sectors were allocated for these Read and Write operations.testing of data was done at
various locations which also included the sector boundaries.
In Figure 10.3, multiple write and read operation is tested.

Figure 7.6: IAP multi read and write test

At 19D004 address location number from where we want to write multiple data is given. In the
subsequent locations command for multi write i.e. 04 and number of location to be written is
given. Then after generating an interrupt at 198000, we read back the locations which were
written earlier. Hence, both read and write routines were verified.

Result and Conclusion

8.1 Result from Implementation of Ethernet Support

Replacing RS-485 with Ethernet on a communication board can have multiple advantages which
are as under:

 In the existing board, communication is done with the help of RS-485 which has a
maximum data rate of 750 Kbps. After replacing this communication with Ethernet we can
get increase in speed upto 10 Mbps which is almost ten times higher than the previous case.

 If we want to add a new node in field ,it will be easier in case of Ethernet support on the
board. In case of RS-485, for adding a new node in field, it requires to modify the previous
termination of the multi-drop link which is not required in case of Ethernet. When the
termination resistance is not the same value as the characteristic impedance of the wiring,
reflections will occur as the signal travels down the cable.

 RS-485 cannot be connected directly over PC. One requires add-on board to provide
communication compatible with RS-485 over PC. In case of Ethernet no such add-on boards
are required as Ethernet ports are inbuilt in PCs. Thus the PC can directly communicate with
the VME station.

Future Scope

Presently the new scheme has been demonstrated by manually wiring the Arduino board to the
base board with the help of jumper wires and an Ethernet shield has been mounted on top of it.
Once the designed is qualified with more rigorous tests, a new schematic of the board can be
developed using the schematic of Arduino and the Ethernet shield , which are open source and
easily available. This integrated design will give field deployable version of the board.

8.2 Result from Implementation of In-Application Programmable Storage

When the system is powered on there is a need for some parameters and information which is
required to be configured at the time of power up. Without non-volatile memory these
parameters and information is required to be downloaded into the system from upper layers. In
doing so dependency on upper layers is involved. This dependency can be cut short by providing
a provision of non-volatile memory into the system. Since in non-volatile memory parameters
can be retained even if the power fails. These parameters would be fetched programmatically
from the non-volatile memory.


[1] Julien Bayle, “Talking over serial” in “C Programming for Arduino” Birmingham, May
[2] Michael Margolis, “Making the Sketch Do Your Bidding” in “Arduino Cookbook”,
Cambridge, O’Reilly,2011,Ch-2, pp 19-58.
[3] VMEbus Specification Manual, Revision C.1, October 1985, Third Printing.
[4] Mohit Bansal, documentation,“Temperature Monitoring System for Indus2” Accelerator
Control Section, RRCAT.
[5] Vaishali Sahu, “Development of a tool for the testing and qualification of VME bus Analyzer
Board” RRCAT, Indore, M.P. 2015.
[6] Jan Waclawek ,“P89V51RD2 and
In-Application Programming (IAP) ” last accessed on May 2017.
[7] last accessed on April,2017.
[8] Microcontroller DS89C420 Data
sheet & Basics, last accessed on Feb, 2017.
[9] CY6264 8K x 8 Static RAM. last accessed
on Feb, 2017.
[10] “Understanding VME Bus” Presentation by Michael Davidsaver.
[11] last accessed on March,2016.