We are currently working on two camera-based products: our own Big-Eye security camera system and a  small hand-held digital camera.  Both of these cameras have the requirement of a user being able to connect to them from a desktop computer to manage and download the images. However, the primary connection method for Big-Eye is Ethernet, while the other camera uses USB. There is a standardised protocol called PTP (Picture Transfer Protocol) which has specifications for both IP and USB. PTP is a widely recognised standard. It is used by most consumer digital cameras and is supported 'out of the box' by most major operating systems.

PTP allows users to download images (and other files) from a camera and delete unwanted images. It also supports camera properties which can be used to view and control the camera's date and time, exposure time, battery level, etc. In developing software support for PTP on our camera products we have written a generic, transport independent PTP layer, which implements each of the PTP commands and properties, and also contains code for managing the images on a camera. This generic layer calls transport specific (IP or USB) functions for sending and receiving data packets. The major benefit of this approach is that any new features, or bug fixes, we make to the generic PTP layer are automatically inherited by both the IP and USB cameras.

Combining this PTP code with the image capture software develloped for Big-Eye (which includes featuers such as threaded image capture, Bayer conversion and JPEG encoding) we now have a full Linux-based software solution for consumer grade cameras.

The RoHS EU directive that came into affect in July 2006 banned 6 substances from being used in electrical and eletronic equipment. However, since then, others have come on board with their own version of the directive. Look at China for instance.  Although China bans the same materials, they do it in a different way and in some areas they are more strict on what is required for compliance. See http://www.rohscompliancedefinition.com/china-rohs.html California also has laws that prohibit 4 of these substances since January 2007. These being:

• Cadmium
• Hexavalent Chromium
• Lead
• Mercury

These directives to nee to be regularly checked to insure that any changes to these are adhered to. This is particularly important if your product currently falls under an exemption as the requirements may change. It is also important for each company selling into these markets to make a statement on what is considered due diligence. That way, its employees know what is expected of them and what the ramifications are for not following the required process. A good description can be found here: http://www.rohscompliancedefinition.com/due-diligence-rohs.html

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!

Bluetooth and Wifi (802.11b/g in particular) have two things in common: they're both increasingly ubiquitous in embedded devices, and they both use the 2.4 GHz frequency band. Although resident in the same part of the frequency spectrum, Bluetooth and Wifi use markedly different approaches to transmission management and collision avoidance. As a result, devices (or event localised areas) with both Bluetooth and Wifi active are prone to conflict and service degradation - in extreme cases, leading to wireless networking being completely unusable. The basic issue is that Wifi breaks down the frequency range into 14 channels, and transmits on a fixed channel. Bluetooth, on the other hand, hops between 79 channels at a rate of up to 1600 hops per second. When a Bluetooth transmission happens to coincide (in time and frequency) with a Wifi packet transmission, both transmissions may be lost. Due to the longer packet sizes, this has a far greater impact on Wifi transmissions, at worst leading to a cycle of packet loss, Wifi transmission rate dropping (thus increasing the risk of collision), and further packet loss - terminating in complete loss of Wifi connectivity. To address this problem there are a few basic approaches: 1. Limit inter-device interference via distance or shielding. By providing 25dB or greater isolation between antennas, the issue may be avoided entirely, but this is often not practical for small devices. 2. Activity signaling and time sharing. Many Wifi and Bluetooth modules provide signals indicating that transmission is currently in progress, or to defer non-critical transmissions. This avoids interference, since only one device is transmitting at any given point in time, but can adversely impact performance. 3. Channel signaling. Interference only occurs when both Bluetooth and Wifi attempt to transmit on the same frequency range, so notifying the Bluetooth module of what frequency slots to avoid during its hopping sequence can avoid interference with no loss of Wifi bandwidth, and minimal impact on Bluetooth. 4. Adaptive Frequency Hopping. The Bluetooth v1.2 standard outlines a mechanism for Bluetooth devices to automatically mark and avoid frequency slots that exhibit interference from other devices, this preventing interference for both Bluetooth and Wifi. Unlike the other solutions listed, this does not require special board-level support, but is only available where all devices in a network support it. These schemes typically rely on module extensions and require board-level support, and vary in terms of the types of interference they can address effectively. In particular, these solutions may be limited where there is broad-base interference or where communication between interference sources is impossible. A simple general solution is therefore not achievable, so care must be taken when doing board design and module selection to take these issues into consideration, and to address the specific coexistence needs of the product.

Here are some quick FPGA pointers

• Be very clear on what sort of reset, asynchronous/synchronous you want. An asynchronous reset in clocked logic can result in your whole design becoming one big metastable input
• Often a reset is not required. Most FPGAs upon start up can have their initial contents specified for signals (i.e. signal bla : std_logic:='1';). Doing this removes one signal form almost every LUT in your design, removes the net with the biggest fanout and removes other reset timing problems. Don't feel as though you NEED to have a system reset pin. This can be done through the FPGA programming interface if really required (A well designed system and FPGA should not really need a reset).
• Understand metastability (That is where a changing asynchronous input is sampled and its result can stay in an undetermined state). The undetermined state is an obvious problem, however the instance where due to logic structure the 'same' signal actually resolves differently in two different places in the design on the same clock edge can cause all manner of problems. This is easy to accidentally do as in:

• Specify timing constraints: Especially on clocks and any timing critical IO. If you don't your system may not meet timing and you'll not realise and spend a long time tracking down odd behaviour.
• If you don't care what a signal is, then say so. The implementation tools can take advantage of this and specify what would result in the fastest or the smallest implementation. i.e. if b='1' then a <= X"01"; elseif c='1' then a <= X"10"; else a <= "XXXXXXXX"; end if; end if;

• Count to a predefined number, initialize to a arbitrary one. Often this means counting down to zero. This results in a smaller fan in on the comparison and thus lower propagation delay, and higher speed.
• Clock as slow as you can. This makes your life easier and reduces power consumption.
• Pipeline. Pipelining improves thruput. Its harder to think about, and does have complications, but can make higher clock speeds easier.
• Plan your pinout BEFORE committing to a layout. Too often the FPGA firmware developer is badgered into picking a pinout so the hardware can be built. RESIST! There is nothing more annoying than trying to make a design work with pins, clocks in the wrong place on the package so the propagation delay is increased. Pay particular care with VREF, VRN and VRP pins. Realizing you've missed these can ruin your day. Ideally generate a design with a proposed pinout to check for any problems.
• Where you can allow the PCB layout guys to swap pins. It is equally annoying for the PCB layout engineer to fan out a mess of an FPGA pinout which when all is said and done is arbitrary. You'll have better tracking, better decoupling, better signal integrity.
• Reduce the number of signals contributing to any other signal. This reduces fan in, fan out. Thus reducing propagation delay and power consumption.