When using the Realview ICE, there are normally portions of the development that are often repeated. Loading and executing a specific image for example, or configuring the SDRAM controller to allow normal development to proceed. These are typically done either in a simple compiled program, or using the inbuilt scripting available in the Realview Debugger. When using the graphical environment however, even when using a single executable, the time taken to click on all the buttons to execute the task can seem laborious. However there is another method available - using the RDDI network protocol to communicate directly with the ICE unit. This protocol allows for all of the standard JTAG operations to be performed automatically from code. At Bluewater we have developed a minimal scripting interface which communicates over this API to automate the tasks which we often perform. This means that with a single click we can bring up a completely un-programmed board into a running state, upload the latest version of our code, and begin executing it with no further interaction. When dealing with a large variety of different development boards, this can be vital in ensuring that information on how to deal with each one is not lost - the script provides all the information necessary. As the details of the actual JTAG operations are still left with the ICE, all the performance advantages of the ICE are still in effect. Operations available from the RDDI network protocol include:

• Resetting the target
• Setting & retrieving register values
• Uploading images to memory
• Downloading images from memory

For our Big-Eye project (a 3.1 Megapixel network camera for security and remote monitoring applications), we needed an efficient software algorithm for converting the Bayer-format data used by the image sensor to RGB data suitable for sending across the network / JPEG compression. A simple C algorithm was coded which did the job. However, it was very slow - about 1.7 seconds to convert a single frame. This was using GCC 4.1.1. The code was fairly well written, using word operations to move through the three lines of the image, two pixels at a time. It was not looking good. After spending a bit of time trying a few basic optimisation techniques, we decided to try the RealView compiler. This now supports most of the GNU options and it is fairly easy to build software using it. The result was pretty astounding. With no code changes, RealView produced an execution time of around 0.3 seconds! A bit of additional fiddling suggested that further improvements might be possible. The main difference seems to be that RealView makes much better use of registers, and thus needs a lot less load/store on the stack. This is probably a common feature of many image processing algorithms. If written with efficiency in mind, they will push the register set quite hard. Much assembler optimisation relies on using the register set more efficiently. But if the compiler can do it for you, so much the better. We could easily have spent a few days working on this part of the code, and with RealView it was just a re-compile. In the end we have moved all the code over to RealView and this is now the standard build environment.

Traditionally, Linux-based applications have been built using GNU tools. Even today, Bluewater uses mostly GNU tools for application development, and always for the Linux kernel. For many years, Symbian used the GNU tools also. The rationale was that GNU tools are cheap and functional, and allow access to the widest possible developer base. However, this strategy broke with companies like Nokia and Ericsson. These companies were very happy with the idea of investing significant sums of money in better tools, and regarded the use of GNU as a missed opportunity. Symbian has therefore moved to a dual approach, with serious developers using RealView and casual developers using GNU. The benefits of RealView include a better compiler (faster and smaller code, more features, better documentation) and better debugging support. Microsoft has followed a different approach with Windows CE. Microsoft uses their own compiler with a number of vendor-specific extensions, and has little interest in encouraging other tools vendors. While this approach provides a highly functional, customised and integrated IDE, it forces customers to rely on the Microsoft ARM compiler, which is not exactly the best in the world. It seems that Linux is moving to the dual-tools approach used by Symbian. This will offer the best of both worlds - low cost GNU tools and highly functional RealView tools. To illustrate the potential benefits, recently we build a bayer filter algorithm with both GNU and RealView. This was for our Bigeye Camera project. The RealView-compiled code executed in about 400ms, versus 1.7 seconds for GNU, so RealView code was 4 times faster! This is an extreme case (other results show around a 10-20% benefit) but it does illustrate the potential benefits of using RealView. A few years ago ARM introduced a --gnu flag into their RealView compiler. Using this, Bluewater Systems has written an applications note for ARM on how to build application software and libraries for Linux using RealView. Today, building Linux applications using RealView requires a fair bit of fiddling, and detailed tools knowledge. But ARM is working on this, as evidenced by the better support in each release for the last several years. The goal seems to be to replace GNU entirely in the tools chain. Bluewater uses RealView tools for bringup, debugging Linux kernels and for debugging WinCE via EXDI2. Our engineers are itching to get a better development environment (particularly in debug) than that offered by GNU. We already have a foot in the water in this area. The next major step for us will be building our Snapper-targeted OpenEmbedded release using RealView. Time frames are unclear at the moment, but even with the current RealView tools we have been able to develop a script which handles translation of most common command-line arguments. The next 12 months should see a big leap forward in Linux tools support, and resulting software performance and engineer productivity. We will keep you posted on our progress. Availability of RealView tools looks like it's becoming a key benefit of using Linux.

The secret to maximising your productivity is ensuring you have the correct tools for the job. When it comes to bringing up a new kernel for a processor that you have not supported before, an embedded ICE is a must have. Before now Windows CE has lacked a set of high quality tools for kernel bringup. Normally the first step in CE development is the creation of a the Kernel Independent Transport Layer (KITL) so that you can debug your kernel drivers over Ethernet. The problem with this is that you need a large portion of the kernel and Ethernet driver to be working before you can do any debugging. As soon as any problems occur in the kernel, the entire debugging session locks up. We have been lucky as an ARM tools distributer to be able to trial a pre-beta version of the Windows CE 6.0 eXDI2 drivers for the Real View ICE. The driver plugs directly into Visual Studio and provides source level kernel debugging of an embedded platform as if it was a desktop application. It has allowed us to single step through the kernel of our AT91SAM9260 platform before the kernel was up and running. No longer do we need to toggle LED's in a seemingly random sequence of pulses to indicate boot progress! The Windows CE 5.0 eXDI2 plugin for Platform Builder is available for general release by registering on the ARM website. http://www.arm.com/products/DevTools/eXDI2RVI.html The Windows CE 6.0 eXDI2 plugin will be available for general beta testing in the very near future.