We've recently come across a fantastic article in Keil's latest newsletter that we'd like to share.  This article discusses the benefits of Cortex-M3 for real-time applications, the modifications done to RTX to support Cortex-M3 and how this results in twice the performance over RTX running on ARM7TDMI. Have a read and let us know what you think! RTX Article

Bluewater Systems has developed the Big-Eye security camera system. Big-Eye uses a 3 Megapixel CMOS sensor and includes features like power-over-Ethernet, WiFi, IR motion sensing, day and night operation, solid state internal and external storage and even audio in/out. Our latest development with Big-Eye includes a tilt and pan enclosure which is rated for internal and external operation. Installation is as simple as connecting power-over-Ethernet to the camera and providing 24VAC to drive the tilt and pan motors. The tilt and pan operation is driven directly by the camera and can be operated via the GUI software, which can potentially be operated via the web. Below is a picture of Big-Eye in this tilt and pan enclosure.

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?

When using the Realview ICE, there are normally portions of the development that are often repeated. Loading and executing a specific image for example, or configuring the SDRAM controller to allow normal development to proceed. These are typically done either in a simple compiled program, or using the inbuilt scripting available in the Realview Debugger. When using the graphical environment however, even when using a single executable, the time taken to click on all the buttons to execute the task can seem laborious. However there is another method available - using the RDDI network protocol to communicate directly with the ICE unit. This protocol allows for all of the standard JTAG operations to be performed automatically from code. At Bluewater we have developed a minimal scripting interface which communicates over this API to automate the tasks which we often perform. This means that with a single click we can bring up a completely un-programmed board into a running state, upload the latest version of our code, and begin executing it with no further interaction. When dealing with a large variety of different development boards, this can be vital in ensuring that information on how to deal with each one is not lost - the script provides all the information necessary. As the details of the actual JTAG operations are still left with the ICE, all the performance advantages of the ICE are still in effect. Operations available from the RDDI network protocol include:

• Resetting the target
• Setting & retrieving register values
• Uploading images to memory
• Downloading images from memory

A sample library is provided by ARM for these purposes, available from http://www.arm.com/products/DevTools/RDDIRVI.html.

While working on DDR memory routing on our Snapper-DV board, which is now using a Texas Instruments (TI) OMAP3530 applications processor, all DDR memory bus lines, including control signals, are terminated with series resistors in between the processor going to the two balance-T DDR ICs. As with all routing that involves DDR, extensive length matching is normally applied to these memory traces (which are further classified into classes per their function). Normally, Cadence Allegro Performance tool via Constraint Manager can handle length matching of traces point-to-point (net) very well.  But with series termination resistors in between, it adds complication because these resistors have to be inerpreted as part of the net connecting the processor to the DDR ICs (see figure below) and thus have to be included in the length matching. When the path of a net traverses a discrete device (resistor, inductor or capacitor), each net segment is represented by an individual net entity (net1, net2) and this whole length is called "Extended Nets" or Xnets. CPU ------------ series term resistors ------------ DDR ICs net1                                          net2 |-------- Extended Nets (Xnets) ---------| Cadence handles Xnets very well and it's very well documented using their high-end schematic/PCB layout and simulation tools, which are very costly. Xnets have to be created so that Constraint Manager can interpret this as a whole trace/track length for matching.  These can only be created by attaching a "signal model" on the discrete device (resistor in our case) and this is a very easy step with Cadence high-end tools front-to-back flow as it is well documented. But with a basic ConceptHDL and Allegro Performance tools, it took some fiddling around to achieve the task. Though the Allegro Performance datasheet shows that Xnets are supported, getting the Constraint Manager to recognize the Xnets was not easy. Assigning a "signal_model" property using the "Edit>Properties" menu was easy, but it didn't create the Xnet that was expected. There are no explicit instructions on how to do this on this medium-flavored tool. The trick was to go through "Setup Advisor" until "SI Model Assignments" and assign the "signal_model" property to the resistors. This procedure worked, Xnets were created, Constraint Manager did recognize these and length matching can now be handled optimally and with ease. In summary, and from experience with using schematic/PCB software tools not just from Cadence, it just doesn't end going thorugh the documentation of using the tool.  There's a lot more to it when using and applying the tools in real life work.