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.

When building embedded devices, one of the fundamental activities we do is coupling [suitable CPU A] with [selection of special-purpose peripherals B]. This gets you from having a feature-rich (but boring) SOM to a specialised device offered a wide range of sensory inputs and options. Being an embedded platform however, complexity, pin counts and space is at a premium - so instead of the more powerful IDE, PCI, PCIe or similar interfaces, words like I2C, SPI and RS232 tend to crop up a lot. In this note, I'd like to focus on I2C. I2C (Inter-Integraced Circuit,(http://en.wikipedia.org/wiki/I%C2%B2C), a.k.a. TWSI (Two-Wire Serial Interface), is a mostly-standardised interface using two control lines -- SDA (Serial Data) and SCL (Serial Clock) -- and in-band clocking. In practice, different I2C devices use very similar protocols -- with subtle differences: clocking behavior, addressing, transaction format, etc. Basically, they're all compatible, except when they're not of course. Under Linux, a wide variety of I2C  devices are supported; in addition, Bluewater regularly writes drivers as we use new I2C devices in our designs. At the time of writing, custom-supported I2C devices include:

• Chrontel CH7004 Video DAC ]
• Dallas Semiconductor DS1339 real time clock [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3470]
• Maxim/Dallas ds2782 Stand-Alone Fuel Gauge IC [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4779]
• Micron MT9T001 Image Sensor [http://download.micron.com/pdf/datasheets/imaging/MT9T001_3100_DS.pdf]
• Omnivision OV3640 3.1 mega-pixel camera [http://www.ovt.com/products/part_detail.asp?id=129]
• Analog Devices AD7414 temperature sensor [http://www.analog.com/en/temperature-sensing-and-thermal-management/digital-temperature-sensors/ad7414/products/product.html]
• Dallas Semiconductor Maxim DS4520 I/O expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4340]
• ST LIS3LV02DQ MEMS Intertial Sensor [http://www.st.com/stonline/products/literature/ds/11115.pdf]

In addition to Linux, we also use I2C devices in lightweight embedded solutions:

• Analog Devices AD5242 Dual-Channel Digital Potentiometer [http://www.analog.com/en/digital-to-analog-converters/digital-potentiometers/ad5242/products/product.html]
• Analog Devices ADG791G 4-Channel SPDT Switch [http://www.analog.com/en/switchesmultiplexers/analog-switches/adg791g/products/product.html
• Maxim/Dallas MAX7311 16-Bit I/O Port Expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3727
• Maxim/Dallas MAX7313 16-Port I/O Expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4101]

Of course, this list will keep expanding as additional devices are used in products.

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.

Two of us are attending an ARM meeting in Hong Kong this week. There is a quite a large turn-out of companies across Asia including Singapore, Taiwan, China, Korea, and of course New Zealand. What struck me as I looked at the group about to go out for dinner last night, was that there were more people there among ARM's tools distributors in just a single region, than worked for ARM in total when I joined just 14 years ago. ARM shipments passed the 10 billion mark last year and the current run rate is over 3 billion per annum. Of interest particularly is the massive growth in low-end ARM micros. The Cortex-M3 is 'only' shipping about a quarter of a billion units per annum, but volume is more than doubling each year. When the $1 micro was announced I wrote a short paper about the possible impact (available here). It seems that ARM is well on the way to making good on some of the benefits identified, particularly in terms of quality of tools, and the productivity of engineers developing with low-end microcontroller technology.

It has been a bit over two years since the Nvidia license was announced. At the time we were promised high definition video and high performance chips with a graphics focus. It takes a couple of years for a new licensee to get their feet under the table, so it's a good time to have a quick look at the results. This video shows some of the technology at work: It certainly looks compelling. From the specs, it can drive an large HD display as well as a Blu-ray player. Another video is (HTC Touch Diamond) showing the Opera browser. Nvidia has recently named their ARM line 'Tegra'. This is a 700MHz ARM11 MPcore (multi-core CPU) with high-end graphics capability. Support on the web site looks weak, and it seems to be aimed at Windows. The HTC Advantage is one consumer product I can see with this technology. It uses Windows too. The target market seems to be tier 2/3 Asian manufacturers of electronic gadgets. Nvidia sees its competition as the Intel Atom, but this is a strange choice. Sure, Tegra looks great against the Atom - 1/10th the size and 10th the power, they claim. But most ARM SOCs look good against the Atom. How does it stack up against TI's OMAP3530, for example? Surely this is the real competition - no one in their right mind is going to put Atom into a small mobile device. The focus on Windows perhaps just reflects the market they are in - as reported on Linux devices:

Asked about future Linux support, NVidia Spokesperson Andrew Humber replied, "Market demands will always dictate the direction in which we take a product, and this is true of all of NVidia's businesses. However, at this time we are focused entirely on Windows Mobile and Windows CE."

This is in strong contrast to both Intel and TI, who go to great lengths to support Linux on their products. Is Nvidia persuing the right strategy here? There is no need to argue with Intel about the merits of using ARM versus x86 in mobile devices - that argument was surely won years ago. And the focus on Windows (while it has advantages in concentrating Nvidia's limited resources into a single platform) plays into Intel's 'we are x86' story, and allows people to pidgeon-hole Nvidia into a customer base with limited software expertise and little chance of producing an iPod-killed. Could Nvidia aim higher?