We often get customer requests for a platform that is suitable for running Adobe Flash applications. Unfortunately none of the desktop flash players are suitable for embedded devices. Finally Adobe has become aware of the huge market for embedded flash devices and produced a version of Flash targeted specifically at ARM based devices. To use Adobe's own words "Adobe Flash Lite is a highly optimized implementation of the Flash runtime for mobile phones, consumer electronic devices". First the good news.... We have successfully run Adobe's Flash Lite on our OMAP3530 Digital Video (DV) platform. While it will not play flash movies designed for high end desktop machines only (i.e. with lots of full screen scrolling), it performed much better than we expected with very smooth playback at 720p. Absolutely perfect for digital signage and kiosk type applications. The bad news.... Flash Lite is not open source and requires a royalty payment to Adobe (approximately US$7 per unit). The second limitation is that the latest version of Flash Lite (3) supports the equivalent of Flash 8 and hence does not support Action Script 3. Hence newer flash movies, designed for Flash 9 or 10 will not run. This is usually not a problem as the main reason customers want to use Flash is because of the developers familiarity with the development tools, and it is easy enough to target Flash Lite Players during content generation. Although there are a few limitations with Flash Lite, it is a very viable option for embedded platforms. Combined with the processing power of the Cortex A8 in the OMAP3530 there is finally a good embedded solution for Flash enabled products. A market space previously dominated by clunky, power hungry x86 platforms. For more information check out the Adobe website: http://www.adobe.com/products/flashlite/

Without hardware support for screen rotation the programmer is often left to rotate the content in software before it is placed into the frame buffer. This has a considerable impact on the performance of the product. An alternative on some devices is to use DMA to do the screen rotation. This requires the DMA engine to increment the SDRAM row between pixel reads and while it frees up the processor, it uses the SDRAM very inefficiently and can have similar performance impacts as doing the entire job in software. The OMAP3530 contains hardware support for screen rotation using a rotation engine called the Virtual Rotated Frame Buffer (VRFB). This is embedded into the SDRAM Controller and can be configured to issue multiple requests to the SDRAM ensuring a maximum of consecutive accesses is performed. By tuning the VRFB to the architecture of the SDRAM the impact of page-miss penalties can be decreased and accordingly memory access performance is improved. For the programmer the VRFB provides four virtual frame buffers; 0, 90, 180 and 270 degrees. Normally the display controller is programmed to read from the unrotated location and the content to be displayed is written to the virtual address of the required rotation. We have recently implemented this feature in our Snapper-DV product. By using the combination of hardware rotation and hardware scaling the customer can pick and choose how their content is displayed on a variety of screens.

We have just completed a design based around Texas Instrument's OMAP3530 microcontroller. This is a high-end chip with lots of CPU performance (2000 Dhrystone MIPS) and a built-in 6-core DSP. We have tied it together with 4GB of flash and 256MB of DDR memory and lots of graphics output features to make something which we think will have great application in the digital signage market. So far we have the platform playing MPEG4 video with an alpha-blended overlay. It looks very slick for such a tiny wee board, and we are not even beginning to use the full features of the platform. As the Open Source support for this chip grows, it is going to be interesting to see what develops. The key difference between an OMAP3530 and a desktop PC CPU like the Pentium 4 is the level of integration. The OMAP chip includes a DSP capable of H.264 4CIF resolution full duplex real-time encode and decode, something your average modern PC struggles with. Without the DSP, the OMAP would struggle too. The OMAP chip includes video scaling and rotation hardware, something delegated to the graphics controller in a PC. The OMAP chip includes a NAND flash controller for storage, rather than the SATA used in a PC - but my laptop has a solid state drive which actually includes NAND flash, so the SATA is really just getting in the way. The OMAP chip also has a built-in USB controller, 3D graphics acceleration, SD card controllers and a direct CMOS sensor interface. The PC's processor (Pentium or whatever) uses separate chips, boards or even products for each for these. So the interest question is how long will it take for the PC to head down the integration route? The OMAP CPU is fast enough (or nearly) for most modern PC requirements such as web, email and office documents. For a limited portable screen resolution of 1024x768 or so it puts across a good effort. It seems to me that at least the bottom of the PC market may one day be served by devices such as the OMAP3530 and its successors. As if on cue, Ubuntu and ARM annouced recently that they are working on an Ubuntu release for higher end ARM platforms.

“The release of a full Ubuntu desktop distribution supporting latest ARM technology will enable rapid growth, with internet everywhere, connected ultra portable devices,” said Ian Drew, vice president of Marketing, ARM.  “The always-on experience available with mobile devices is rapidly expanding to new device categories such as netbooks, laptops and other internet connected products. Working with Canonical will pave the way for the development of new features and innovations to all connected platforms.”

The focus is of course portable devices. But I wonder whether in 5 years time we will be using anything else?

The new release of software (3.3) for the RealView ICE supports Texas Instruments' range of OMAP3 processors. An interesting feature of the OMAP3 family of processors is that the ARM Cortex-A8 core is not automatically added to the scan chain and cannot be auto-detected. Instead the OMAP3 uses a TAP router (JTAG Route Controller) that must be programmed with what is available on the chain. Luckily ARM has provided "templates" for the OMAP3 family that allow the user to select which processor they have connected to. The template provides the RealView ICE all it needs to know for easily connecting to the ARM core. An example of the OMAP3530 scan chain is shown below. Also be aware that TI uses a non standard 14 pin JTAG connector. If you need to connect any of the standard ARM JTAG tools to a TI (such as the OMAP3 family) processor, you will need a TI JTAG adapter such as the ARM provided HBI-0027B (Schematic). Make sure you mention you need to connect to a TI device when you purchase your next RealView ICE!

The Atom was the reason why Intel had to sell the XScale division. Unfortunately the XScale CPU wasn't all it should have been, lacking debug capability or the performance leap promised by its StrongARM heritage. While Intel sold a few chips to people for WinCE PDAs, and even a few Motorola cellphones, the market was small compared to that available to TI and the like. Free from its ownership of a competing architecture, one which has wiped the floor with Intel, its execs obviously feel comfortable letting rip at ARM. Intel is no-doubt hugely frustrated at its inability to compete in the fast-growing cellphone market, and the Apple iPhone is just another sign of ARM's dominance in this sector. So here is the I'm referring to:

Kedia didn't just stop at the iPhone, claiming ARM was a malaise afflicting smartphones in general. "The smartphone of today is not very smart," he said. "The problem they have today is they use ARM." Wall believed the situation was unlikely to change anytime soon, saying Intel was two years ahead of the rival company. He didn't believe fast, full internet would receive a début with ARM-based devices in the near future. "Even if they do have full capability, the performance will be so poor," he said.

Of course this guy is just venting, during a trip to Taiwan. Perhaps he met with a number of potential customers there who all told him they were using ARM and very happy with it.

But also, it simply isn't true. Tom's Hardware shows Atom's power consumption (for CPU alone) of about 2.5W, with 5W including the required companion chip. We should point out, though, that the two chipsets to be used with the Atom N200s are power users: the Atom 230s use an i945GC that consumes 22W (4W for the CPU) and the Atom N270s ship with an i945GSE that burns 5.5W (2.4W for the CPU).

This is for a 1.6GHz CPU. By comparison the OMAP3530, a dual core 600MHz CPU with integrated video DSP, 3D graphics, NEON SIMD machine, DDR interface (i.e. Atom + support chip) consumes under 2W total (and that's the maximum from the datasheet and the - with power management OFF!). It is a mystery why Intel chips consume so much power. Some say it is the Byzantine x86 instruction set. Others say that Intel aims for speed rather than power. Who knows... So in terms of power consumption, Intel isn't even able to play the game yet. It is perhaps 3-5 years behind ARM on this one. The claim that the Internet isn't usable on an ARM CPU is also bogus. From what little I have seen of the iPhone it seems usable enough. My Nokia E90 certainly runs ok on the web, although I agree it could do with more speed (it is an ARM11 design). I think Intel will be shocked at the capability of the Cortex-A8 devices when they come out in the new year. Of course Intel needs to attack ARM - ARM owns the lower power market space and it is the only way that Intel can make inroads into it. But Intel needs to get its products in order first. Perhaps Intel should swallow its pride, take an ARM architectural license and put its A team on the project. The C team didn't do a great job, but everyone knows Intel has great chip engineers - just look at the Pentium range. Take away the x86 baggage and who knows what might be achieved?