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.

Over the past 18 months or so, Atmel have put a real push into getting the most out of their ARM9EJS-based CPUs. They have managed to boost the clock speed, increase the peripheral set, reduce the power, and reduce the cost all in one go. These new chips, the AT91SAM9G20, AT91SAM9G45, and very recently release AT91SAM9M10 all run at 400MHz, with peripherals covering image sensors, ethernet, video playback (hardware accelerated on the M10!), as well as the usual set of UARTS, I²C, etc.

The big breakthrough with Atmel however has really been the power consumption and price. The AT91SAM9G20 core consumes only 80mW at full speed, and can be purchased for as little as $16 in single quantities, down to $7 in larger volumes.

Here at Bluewater we have taken great interest in these Atmel development, and have incorporated these into our new module, as well as our (upcoming) 9G45 design.

In drawing up the schematics for a new design, it is very easy to add new components willy nilly as and when required. Then - once happy with the design - move on and produce a masterpiece of a PCB layout. After the PCB layout send the files out for quote and move on to purchasing components. It's at this point that you may find yourself confronted with a large BOM (Bill of Materials) to buy before you can build your board. The time to find and buy these components is not the end of it either. A large BOM has the following drawbacks:

1. The more discrete part types in a design, the lower the volume of each will be, and the cost benifit of buying in bulk can not be realised
2. The inavalibility of any part can stall a build. The more parts in a build, the more likely this is to happen
3. More parts means longer machine setup times and more feeder requirements - possibly even a double pass through the machine. These all add to build cost
4. More components to track and keep inventory of which costs time

On most boards there are a variety of very simple things that can be done for very low cost to mitigate these problems - the initial cost will more than pay for itself in reduced future costs and reduced risk.

The BOM rationalisation step should be performed after the schematic phase - NOT after the PCB phase. Often BOM simplification requires trivial changes in the schematics, but once the PCB layout is done changes may result in a lot of work needing to be redone.

There are many things that can be done to reduce the BOM count. Resistors and Capacitors are the simplest place to start: often there is a wide range of these in any design and these are by far the easiest target. There will often be many components of which there is only one or two used. Several things can be done in this case:

1. Check if the odd-ball specific value is actually required, or can it be replaced by a more common component on the design. Pull-up resistors are a common culprit here
2. If the value is required, see if it can be produced by a parallel or series combination of common components. It is quite suprising how often this technique can be used.
3. Voltage dividers. These can be a special case of the above technique. In one recent design, it was discovered that a 100k, 120k and 330k could produce over 60 different divider ratios with one or two high side resistors, and one or two low side ones. The spread was quite even too.

Power supplies can often be simplified too:

1. Using an adjustable version of a power supply, and tailoring it to several different voltage rails will use fewer different ICs than using the pre-programmed ones. When it comes to production, a shortage of any IC could put a halt to productio, so the fewer different IC types, the better
2. Adjustable supplies normally have a voltage divider to set the output - take advantage of the voltage divider options as discussed above. Remember that a 3.3v supply doesn't need to be 3.300000000v: 3.27453v is more than acceptable for the vast majority of systems!
3. Inductors can often be reused on switch mode supplies even though it is a different voltage rail. It may sacrifice a minor % of efficiency, or on the surface cost a few cents more - though doubling the volume will more than likely cancel this out.
4. Don't be afraid to understand and modify the 'webbench' recommendation. TI, National, etc all have really easy to use web based tools for designing power supplies, but don't take the design they provide as the end of it. There is scope for adjustment and fine tuning to suit your particular board
5. Some switch mode ICs can be configured as a DC/DC converter, or as a current source for driving an LED backlight. Look into these options at design time and use the same switch mode IC for both

Similar components can often crop up in designs. If there are multiple different types of MOSFETS, BJTS, or diodes these can be reviewed to ensure that there is a good reason for them to all be different. This is most often a problem when portions of several designs are combined to make a new one.

Use configurable logic gates - TI for one make some small ICs (SN74AUP1G57 for example) that can be wired up as an AND gate, an OR gate, or some other odd-ball gate. These can have their advantages if there are several different gate types in the design that can each be replaced by a different version of the single configurable gate.

Consider for some applications using transistors and resistors to replace a one-off logic IC.

There are many more things that can be done. The majority take very little effort at the schematic phase. It is easy to be of the mindset that that 12.7k resistor only costs a few cents, so why bother removing it, however the issue is not the cost of the component - it is the cost of supporting the component! The 5min to design it out pales when compared to the what it would cost to support it through the lifetime of the product through purchasing, stocking, machine setup, and risk of it being temporarily unavailable.

Here at Bluewater we strive to keep BOM counts down and this approach has produced dividends both in simpler prototype and production builds. The benefit is easier stock tracking and reduced time spent on component managment.