A common use of our Snapper DV (OMAP3530) technology is to display digital video content on standard televisions or computer monitors. It is a fairly trival task to attach a DVI/HDMI transmitter to the RGB output of the OMAP3530 to provide a very versatile digital video solution. The trick is to detect what resolutions and frequencies are supported by the connected television. Luckily there is a standard for this.

The Display Data Channel (DDC) is a protocol that can be used to control a display/monitor via a two wire physical link. DDC is found on most recent computer monitors and is also part of the HDMI cable specification. The most common version of DDC is actually implemented as a standard I2C bus. A DDC compliant display acts as an I2C slave and allows available resolutions and settings to be requested over the bus.

The Extended Display Identification Data (EDID) is a data structure that describes information about the display. It is this structure that can be read over the DDC and is specified by the Video Electronics Standards Association (VESA). The most commonly used version is v1.3 and it is this version that is used by HDMI compliant devices.

Given most embedded devices have I2C busses, it is a trival task to connect to the DDC of an HDMI connector. So once you have a working I2C bus, reading the EDID is as simple as reading 128 bytes at I2C address 0x50. The "parse-edid" application which is part of the "read-edid" opensource package can be used to parse the binary blob that is the EDID to something that is human readable.

Critical to most embedded applications is parsing the supported resolutions. Unfortunately the information in the standard EDID is not always enough to make these decisions. This information is usually stored in "extension" blocks that are stored after the standard 128 byte EDID. Each extension block is of type audio, video, vendor specific or speaker. Each video extension block contains a supported resolution and suitable refresh frequencies.

While connecting off the shelf displays to embedded devices can by a very quick way to add large display capablilties, the reality is that most televisions and monitors are quite specific about the resolutions and refresh rates the need to operate at. Hence to properly support consumer displays, the DDC channel and EDID parsing must be implemented on the embedded device and resolution and pixel clock set accordingly.

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/

The Eclipse IDE has been used for embedded development for many years now, but it has always been a painful process to setup and use. In a couple of weeks version 3.5 of the Eclipse framework codenamed 'Galileo' will be released. At the same time the CDT team are planing to release version 6.0 of the C/C++ Development Tooling plugin. What makes this interesting to the embedded development community is that the Debugger Services Framework (DSF) has been integrated into this CDT release. The DSF provides an alternative to the Standard Debug Model API of the Eclipse platform and has been designed to help achieve better performance when debugging applications on slow or remote targets. To gauge how painless it really is is use the new version of Eclipse for embedded development we decided to give the current release candidate a try. We downloaded the "Classic" package and installed the CDT, Remote System Explorer (RSE) and Subversion source control plugins. The creation and cross-compilation of a simple "Hello World" application was straight forward. The setting up and configuration of the connection to the remote device (using SSH) was slightly more complicated, but worked well. The integrated remote file viewer, shell and GDB launcher are all very useful tools that make Eclipse that much better as an embedded device development IDE. So perhaps now Eclipse is finally ready for embedded development! We have added detailed instructions on how to setup and use Eclipse with our Snapper 9260 Quickstart Kits on the Bluewater quickstart pages.

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.

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!