**5. Sample system implemented with this hardware platform**

This section presents a specific development of a Remote Terminal Unit (RTU) which implements the standard IEC-60870-5 application-layer protocol for telecontrol messaging stacks. Both the hardware and the operating system are based on the platform already presented in this chapter and we discuss the main tasks required to customize our developments to fit the target system and also describe some of the advantages of using our embedded platform.

In a typical telecontrol scenario one station (primary station, called CC), controls the communication with other stations (secondary stations, also called RTUs), so IEC 60870-5 specification allows online telecontrol applications to take place. In this sense, the IEC defines a set of functions (profiles) that performs standard procedures for telecontrol system. A typical scenario for this kind of communication is shown in figure 3.

The transmission channels available within the design RTU are RF (Radio Frequency), GSM (Global System Mobile) and GPRS (General Packet Radio System). We had to provide the hardware platform with these devices and to integrate everything in the kernel drivers so they were addressable by the user level applications.

For RF transmission an ICOM IC-V82 (VHF transceiver) device was used, with the digital unit UT-118. This device is D-star capable, and can be connected to any RS232 device for data 10 Will-be-set-by-IN-TECH

applications, source code, and shared libraries. Debian tools leave the software developer environment ready inside of platform and the software compilations can be made easily. At this point the software can be developed inside of SoC, the software is also able to be debugged

Once the developing process has finished, this platform has some advantages during its lifetime. Having the ability of upgrade in the field is a common task today and is an advantage over closed systems. Upgrading the software or fix critical bugs are easy tasks becouse Debian community maintains its repository and, the software upgrades are automated when packages machinary is used. Other embedded SoCs require external tools to update the firmware, instead, this platform has the ability of autoupgrade if its necessary, eg. using

Another important aspect is the improvement in the process of developing drivers for this platform. By running 2.6 kernels it is possible to load devices drivers in the kernel under demand. With this, we obtain two advantages, one concerning to the resources used and the

One of improvements is the capacity to add all avaliable device drivers with the kernel. Although most of the device drivers are not necessary at same time, the capabilities of the platform is not affected by including all. In fact, only the necessary device drivers are loaded into memory on demand, while the rest of them remain stored at disk. With this, the system maintains all functionality and, it saves resources for the rest of the tasks. On the other hand, new device drivers are developed without touching the binary kernel that is running into platform. Since the new drivers are loaded and unloaded dynamically, the driver developer can debug inside the platform. This is an advantage over other SOCs where, the kernel must be fully recompiled and loaded into the SOC for each change in the drivers thus, making the

This section presents a specific development of a Remote Terminal Unit (RTU) which implements the standard IEC-60870-5 application-layer protocol for telecontrol messaging stacks. Both the hardware and the operating system are based on the platform already presented in this chapter and we discuss the main tasks required to customize our developments to fit the target system and also describe some of the advantages of using our

In a typical telecontrol scenario one station (primary station, called CC), controls the communication with other stations (secondary stations, also called RTUs), so IEC 60870-5 specification allows online telecontrol applications to take place. In this sense, the IEC defines a set of functions (profiles) that performs standard procedures for telecontrol system. A typical

The transmission channels available within the design RTU are RF (Radio Frequency), GSM (Global System Mobile) and GPRS (General Packet Radio System). We had to provide the hardware platform with these devices and to integrate everything in the kernel drivers so

For RF transmission an ICOM IC-V82 (VHF transceiver) device was used, with the digital unit UT-118. This device is D-star capable, and can be connected to any RS232 device for data

other, in the devices drivers developing process. Both are now explained in detail.

**5. Sample system implemented with this hardware platform**

scenario for this kind of communication is shown in figure 3.

they were addressable by the user level applications.

inside using the debug tools included.

debugging process of drivers difficult.

network connection.

embedded platform.

Fig. 3. IEC 60870-5 transmission scenario

transmission, with a data transmission speed of 1200bps. The GSM modem was a Wavecom Fastrack M1306B, which behaves as a standard AT-command modem via a RS232 port, so the modem is connected to the RTU this way. According to device specifications, it allows a data transmission of up to 14.400 bps for GSM but this feature depends on the GSM operator used, so it might not be available (in fact, our tests ran at 9600bps).

In order to get those devices into the design we needed some serial ports and so we integrated a fully capable UART 16550A compatible peripheral, which improves the default UART integrated with LEON microprocessor, by using all the transmit, receive & handshaking lines and also adding two onchip FIFO buffers for improved usability.

We started the development of the UART with one of the free IP cores from OpenCores community (written in Verilog) and we had to interface the Wishbone bus interconnection architecture to the AMBA-2.0 APB (ARM Corp., 1999) peripheral connection LEON manages (the one for relatively slow and simple devices like this). The main issue when interfacing those two protocols is that the AMBA-APB bus does not have a signal for acknowledgement, so every operation always has the same duration, while the Wishbone peripherals usually insert wait states in the communication to the bus master using that ACK line. Finally some Plug & Play information was added to the system so it enable the identification and allocation of the peripheral automatically on the LEON based system startup.

In figure 4 a picture of a prototype of the platform is shown, where you can see the GPS device, the GPRS modem fitted in a custom expansion card with some more serial ports, a compact flash card to hold the Linux local filesystems and the FPGA which holds the embedded design. The prototype has been implemented on the development board XC3S GR-1500. This board includes a Xilinx XC1500 FPGA Spartan3. Also, the board provide others features needed to run the system: 64Mbytes of SDRAM, 64 Mbit of Flash memory, Ethernet PHY transceivers R232, etc. In order to connect both the GPS and GSM modem and Compact Flash card has been necessary to develop adaptive PCBs as shown in figure 4.

**6. Conclusions**

The breakthrough in the capabilities and performance of FPGAs has made becoming an alternative to the MCU in the design and implementation of embedded systems. The main differences between the two alternatives are in fact that the design with FPGAs need to design not only the SoC software but also hardware. This can be very advantageous in many cases because the hardware can be adapted to the specific needs of an embedded system. However, there are still significant differences in the software design methodology due to the development tools available to the MCU are far more advanced than the software

Open Development Platform for Embedded Systems 323

In this chapter we present a platform hw / sw implementable on FPGA which greatly facilitates the process of software development. This platform has several significant advantages such as it is based on open components (LEON3 microprocessor and operating system Linux, Debian), tools that facilitate the development of hardware platform, etc.. But, fundamentally, the main advantage is based on having implemented the Linux operating system with the Debian distribution. This distribution is prepared to run on a standard PC. This means that all the software available for Debian is easily installed. It also has a large set of libraries for developing software applications that can be implemented and used in the

To demonstrate the efficiency of embedded systems development based on this platform we have designed a terminal of geolocation. Thus, it has completed the design of both hardware platform and software applications running on the terminal unit. Software development has demonstrated the advantage and versatility that means having both a large set of available

This work has been partially supported by the Ministerio de Economía y Competitividad of the Spanish Government through project HIPERSYS (TEC2011-27936) and the European

Sangiovanni-Vincentelli, A. and Martin, G. 2001. "Platform-Based Design and Software Design

Beeckler, J.S. , Gross, W.J., 2007. "A Methodology for Prototyping Flexible Embedded

A. Ben Atitallah, P. Kadionik, N. Masmoudi, H. Levi. "FPGA implementation of a HW/SW

Salewski, F., Wilking, D., and Kowalewski, S. 2005. "Diverse hardware platforms in embedded

E. Ostua, J. Viejo, M. J. Bellido, A. Millan, J. Juan, A. Muñoz, 2008, "Digital Data Processing

(2008) 12: 293âA ¸ ˘ S311, DOI 10.1007/s10617-008-9030-2

Methodology for Embedded Systems" *IEEE Design & Test of Computers*, 18, 6 (Nov.

Systems" *CCECE: Canadian Conference on Electrical and Computer Engineering*, 2007.

platform for multimedia embedded systems" *Design Automation for Embedded Systems*

systems lab courses: a way to teach the differences" *SIGBED* Rev. 2, 4 (Oct. 2005),

Peripheral Design for an Embedded Application Based on the Microblaze Soft Core",

development environment for microprocessors that are implemented in FPGAs.

libraries and development environments equivalent to those of a standard PC.

embedded system that is based on this platform.

**7. Acknowledgements**

**8. References**

Regional Development Fund (ERDF).

pp. 1679-1682

2001), 23-33. DOI:10.1109/54.970421

70-74. DOI:10.1145/1121812.1121825

Fig. 4. Hardware Platform Prototype

Regarding the software development, there is no open source applications available for the IEC standard protocols, so both the data-link layer and the application layer have to be implemented from scratch. Anyway, as we're using Linux on our platform we already have a TCP/IP stack and standard development tools and libraries, so the data transport and other concrete IEC specifications were built.

The software project was divided into a few different modules, but the most interesting one is the Remote Module, (RTU module). Modules have been developed in C++ language, under a typical software development IDE on a hardware platform x86 (PC) running Linux operating system. Only standard libraries have been used in the development. After the initial setup and debugging the software toolkit also has been compiled for LEON (SPARC) architecture. As LEON has a standard Linux Debian distribution with standard C++ libraries, getting a binary file running is as simple as compiling the same source code developed in the PC in the embedded Linux by using the standard C compilers for the architecture. A GCC compiler has been used to compile and link the RTU source code inside LEON.

In order to test the full system, two parameters were analyzed, initialization time (IT), mean time required to complete the initialization on a RTU, and Poll Time (PT), mean time required to complete a poll over a RTU. Also two scenarios were tested. In one the CC and RTU were PCs and in the other the RTU was LEON. Full details on the application solution implemented and main results were presented in (Medina, 2009).
