Energy Micro, the Norwegian ARM licensee, have expanded their Gecko Cortex-M3 product line with 100 new processors. These provide a range of features, from a huge 1MB of memory on the Giant Gecko family, to a tiny 400nA back-up power mode for power saving devices.

Available for as little as $2.47, these micros offer an excellent option for low power, high functionality devices.

For further details, see here.

The 2.6.34 release of the mainline Linux kernel now includes support for Bluewater Systems . Support is included for the Ethernet, frame buffer, NAND flash and I2C peripherals, with support for the SPI bus and I2S audio expected to be merged in the next few releases.

Other code which has been committed to the mainline Linux kernel by Bluewater Systems includes:

• Driver for the SST25L SPI flash
• Driver for the DS2782 battery gas-gauge
• Generic GPIO support for the AT91 ARM processors, which is used by our , and the upcoming 9G45 modules.

The XScale PXA255 processor has been around for about 7 years now and is coming to the end of its production life with no direct replacement available. Originally made by Intel but then moved to Marvell the PXA255's last time buy date has been pushed out over the last few years. Now it is drawing to an end with the last orders being accepted no later than the end of June and final delivery at the end of 2010.

http://en.wikipedia.org/wiki/XScale

The PXA255 is the heart of the Snapper 255 designed by Bluewater Systems back in 2004-05.

It has been used in a number of products since then, with notable success coming from the .

It's out with the old and in with the new Snappers that are on their way. So cast your lines and hook into the new Snappers to be announced !

We have recently been working on a project which involved implementing a Bluetooth stack on an ARM Cortex M3 micro, with only 48kB of memory and 256kB of flash. We chose to use the Light-weight Bluetooth library (lwBT), which is a small, cross platform, Bluetooth library designed for embedded environments.

The lwBT library provides basic functionality for the , L2CAP, SDP and Bluetooth layers. Additionaly, we implemented an OBEX layer with support for pushing files to remote devices and providing an OBEX push profile to allow files to be received from other Bluetooth devices. We also implemented a basic serial port profile (SPP) on top of the RFCOMM layer in lwBT which provides wireless serial communication. This can be used, for example, with the standard Linux BlueZ RFCOMM serial utilities. The entire lwBT stack fits in under 24kB of flash storage and uses between 5 and 10kB of memory depending on configuration options.

The lwBT stack provides a lot of the core Bluetooth functionality, but the interface to the library is very raw. Our Bluetooth API provides a set of simple access functions for common tasks such as sending and receiving data over an RFCOMM link and pushing files to other devices via OBEX. Our Bluetooth library was also designed to be as platform independent as possible. Only a thin platform specific layer must be written in order to move the Bluetooth library to a new device.

The following diagram shows the structure of the Bluetooth stack provided by our library:

A common use of our (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.