console=ttyS0, 38400 root=/dev/hda1

platform is the possibility of designing a controller or peripheral specific for a particular application, which can be included in the SoC. It is also possible to reuse IP cores available for other systems. In these cases, it will make a design interface with the AMBA bus, which is the main bus that uses the hardware platform.

The most important improvement on this platform is under software developing since, the biggest effort in SOCs developing falls on the software and specifically in the interaction with peripherals. Our platform includes a operating system installed that solves the peripheral management through the device drivers. Even if a given driver is not avaliable for a new hardware, using Debian distribution we have tools to makes easy the developing. While with a conventional software developing methodology, some external tools are required: cross compilers, emulators, debug connection tools, etc., once installed the Debian distribution some advantages are achieved versus conventional software development methodologies of embedded systems.

We have achived significant improvements in the software tasks such as installing, compiling and developing, also, in the manage of devices drives or in high level applications. All this due some advantages of the using Debian as base software, it can be summarized as following:


Usually, is not an easy task to install any precompiled software in a SoC. Most medium-high complex software applications depend of other software as shared libraries or external tools. Software distributions give tools to solve applications dependences. Specifically, the main feature of Debian software distribution is the Debian package machinery. This resolves the software dependencies and creates a minimal configuration for each installed software. This minimal configuration allows the putting services on just after install processes and also, can be used as example of end software configuration.

Using precompiled software avoids the heavy task of compile software. Compile software for embeded systems is a heavy task due some of following reasons: one, is the dependence between applications and shared libraries making the compilation process complex. Usually one application needs an exact version of each required shared library. If there are several applications installed at the same time, the same library could appear several times, but with a different version number. In this situation install, upgrade and maintain the software is a tedious task.

Other reasons that make the task of compile software for SoCs complex is the use of cross compilers to generate software. Once compiled software, to test it, all necessary files must be transferred and installed: executable files, shared libraries, config files, etc. The steps of compiling and transference are repeated as many times as necessary to achieve the software to be ready. This process is improved when the Debian distribution is installed. It is possible to install all compiler tools in the platform and make the compilation process inside of platform. Also, this task is assisted by Debian tools since, it detects all dependencies between 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 inside using the debug tools included.

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 network connection.

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 other, in the devices drivers developing process. Both are now explained in detail.

Fig. 3. IEC 60870-5 transmission scenario

so it might not be available (in fact, our tests ran at 9600bps).

and also adding two onchip FIFO buffers for improved usability.

of the peripheral automatically on the LEON based system startup.

been necessary to develop adaptive PCBs as shown in figure 4.

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,

Open Development Platform for Embedded Systems 321

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

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

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

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 debugging process of drivers difficult.
