Bluewater Systems

As an ARM authorised reseller, we tend to use the ARM Realview tools (RVDS) whenever appropriate. With ARMs recent acquisition of Keil there is now another option available, the Microcontrol Development Kit - MDK.

MDK is aimed at the lower-end market - ARM7, Cortex-M3, and some ARM9. It is also targeted towards either OS-less, or RTX-based designs. RTX is ARMs simple realtime OS. It includes all of the features normally supplied with a small embedded OS: Threads, Scheduler, Mutexing, Memory Pools, Mailboxes, Delays, Events etc… When using the RTX kernel and the MDK tools together, a large number of advanced debugging options become available.  The ability to trivially graph thread stack usage and thread execution time, which can make some aspects of profiling an application trivial. It also provides a full simulation system for a large number of CPUs (see the Keil Device List for more details). These simulated CPUs generally include the full peripheral suite as well, which makes prototype development easy, even in the absence of actual hardware. MDK also includes a full IDE, build system and large library of examples, making initial project creation a breeze.

RVDS is targeted at a different market. It aims to support the latest ARM CPUs, with recent additions for the Cortex-A9. Its simulation model is geared more towards ARM cores rather than specific SOC chips, and as such it is not suitable for full system simulation. It can be used very well for algorithm simulation however, and provides all the optimisation feedback necessary for this purpose.

Both of these platforms share the same compiler suite, RVCT. RVCT generally provides the best code generation and optimisation features of all the ARM compilers, certainly far better than the commonly used GCC compiler. It also supports a lot of the extensions provided by other tool chains, making it relatively easy to transition from one compiler to another.

Generally, the decision between the two is quite apparent - if a more traditional embedded design is being done, such as an embedded control application, then a lower CPU, such as the Cortex-M3, or ARM7 will be chosen. In this case, MDK is more appropriate. If a more advanced design is to be used, involving a complex modern operating system such as Linux or WinCE and an ARM9 or greater CPU, then RVDS will provide faster code download & flexibility.

Surely most engineers are familiar with the basics of the ARM7TDMI? To recap, it has a 32-bit register set with 16 registers, RISC load/store architecture, various processor modes with a role in exception processing, private registers in each mode (particular FIQ with a very useful r8-r14), a simple 32-bit instruction set with only 21 types and an additional 16-bit instruction set with zero-penalty decode logic.

Since it was originally released in 1994, several of ARM’s engineers wanted to improve on perfection. Perhaps the power consumption could be made even lower, perhaps the instruction set could be made even more dense, perhaps more microcontroller features should become part of the standard design?

The shrinking area of silicon required for a microcontroller, and the resulting reduction in cost, presented another opportunity. It should be possible to make an ARM chip as small as an 8-bit micro, and to consume less power.

Cortex-M3 is the result of these factors. It is not radically different from ARM7TDMI, and retains most of the architectural features. But it drops several, expands others, and adds a few more.

Key features of Cortex-M3 are:

• You program it entirely in C. There is no longer any need for assembler, although it is still available. This doesn’t mean that it is less efficient
• It won’t run Linux. It is aimed at small microcontrollers so does not include data aborts for virtual memory, etc.
• Built-in microcontroller functions, such as interrupt controller, timers, memory protection
• Drops exception modes and the ARM instruction set (only supports Thumb / Thumb 2)

Some lesser features are:

• Thumb-2 instruction, a clever extension which gives the code size benefits of Thumb with the performance benefits of 32-bit ARM code
• Single Wire Debug (SWD) option, which reduces the number of pins required for JTAG/debug functions from 5 to 2
• Integrated trace functionality, traditionally only available on higher end ARM9 devices. Cunningly, it also operates over the SWD port
• Half the interrupt latency (or better), by building the concept of state saving directly into the micro. In particular, consecutive interrupts can be processed without the traditional save/restore step in between
• Half the power consumption when running, plus an integrated sleep mode
• 30% faster operation at the same clock speed
• ARMv7-M Harvard architecture with a number of new instructions

ARM’s removal of the exception processing part of ARM7TDMI was not just a clever way of getting rid of stuff that low-end microcontroller engineers don’t need. It also provides a clear differentiation between the higher end micros and the new microcontroller range. This make it possible, at least in theory, for companies like Atmel to sell an ARM9 range at $6, and ARM7 range at $3-4 and a Cortex-M3 range at $1. In my view this is one of the cleverest features of Cortex-M3 - it doesn’t canabalise the existing market to the extent that you might think.

Bluewater Systems has completed a number of Cortex-M3 designs and we have built quite complex embedded software systems using it. When combined with the RealView tool chain, it is a formidable player in the embedded market. For the price, it is surely unbeatable.

Cortex-M3 micros were first shipped by Luminary Micro who have 134 models to choose from. ST Microelectronics have a respectable 38 so far. Atmel is on board now also although I can’t see any devices yet.

For more details on Cortex-M3, and if you have an hour spare, take a read of the original white paper on the topic from ARM’s web site. You might find this series of videos useful too.

PCB design at Bluewater is most of the time an exciting challenge, especially when it comes with system modules. Just like with any other modern digital gadgets nowadays, they have to be small in size and thus, space (or real estate as another term used by PCB designers) on a PCB is always a premium. Along with this direction, the chain must adapt to it, small fine-pitch and high density components are mostly used, PCB vendors have to update their capability, as well as PCB assembly houses.  And of course, cost will always be involved when going to miniature, complicated technology.  Otherwise, these modern tiny gadgets will never exist.

Speaking of fine-pitch high density components, things like 0.5 to 0.65mm pitch BGA packages should usually surface as a common option along with fine-pitch packages such as QFN, DFN, etc. The thing with fine-pitch BGAs, especially full-matrix ones, is that they are usually more difficult to fan-out (so that you can route to the rest of the circuitry on the PCB) compared to conventional0.8 to 1mm pitch BGAs. High-tech PCB technologies such as High Density Interconnect (HDI http://books.google.co.nz/books?hl=en&id=DZaI84cYEyAC&dq=High+Density+Interconnect&printsec=frontcover&source=web&ots=8ecJYG-2hH&sig=kTsw6CMICVrB-pozLsia_fXXeOo&sa=X&oi=book_result&resnum=1&ct=result#PPR5,M1), blind/buried microvias or via-in-pad are usually the way to go which still cost more than conventional PCB manufacturing methods nowadays.

Two year ago, we developed a module (37mm x 26mm) with Intel’s PXA272 microprocessor (0.65mm-pitch, 336 pins, full matrix BGA) on it for our customer (in military defence). With cost in mind and by coordinating with our PCB vendor, we were able to avoid the costly high-tech HDI or blind/buried microvias, or via-in-pad by using 5-mil via through-hole drill/15-mil via pad and 3-mil spacing between vias to any other entities but with limited aspect ratio. Although this approach may still not fall under (still slightly expensive) the conventional PCB technologies and is dependent of our PCB vendor, at least it’s not a full blown HDI or any other costly cutting edge PCB technology and it’s good to know that there are less costly options like this, especially when just producing prototype quantities. In our Snapper 270 SOM, we also have buffers having 0.65mm pitch but not full-matrix ones and we were able to use full conventional PCB technology by carefully assigning signals on the buffer side to eliminate vias in fanning out the BGA and optimised routing. Most recently, we are currently developing our Snapper-DV board, which is using Texas Instrument’s Da Vinci processor TMS320DM355, a full-matrix, 377 pin, 0.65mm pitch BGA and again, the same above mentioned strategy were used to check cost and this time around, with an improved aspect ratio, thanks to our PCB vendor.

In the near future, HDI and the like may be the only way to go but hopefully, the cost tagged along with using these cutting-edge technologies will trick down (fingers crossed).

While working on a project for the UK market, the issue of Printed Circuit Board material came up. As this product was required to be RoHS compliant (Restrictions of Hazardous Substances Directive), it must be able to withstand the higher re-flow temperatures associated with lead free soldering, which can peak at 260C.

A common misconception with this is that using just a higher TG (Glass Transition Temperature) will be acceptable. However, you will also need to ensure your base material is also of a higher TD (Decomposition Temperature).

The TG value is where the resin changes from rigid to soft material and TD is the value where the material weight changes by 5%. Exceeding the TD value will cause permanent damage to the circuit board, which can result in loss of adhesion and delamination.

See the link below for a more detailed and in depth read.

www.isola-group.com/images/media/ReengineeredFR4Materials.pdf

So when selecting PCB material for the lead free solder process, a good guide is to use material with TD above 340C and TG above 170C.

3G data modem support is a core feature for the Real Time Passenger Information (RTPI) system designed by Bluewater Systems. The RTPI system is designed to collect and display information about the arrival times of buses at a particular point on the route. This information is provided by a unit on the buses which uses a GPS receiver and GPRS or other wireless communications to pass on positional information to a central server.

The choice of the 3G modem was dictated by another requirement: to use a cheaper GSM data modem as an assembly option. Bluewater decided to use the 3G embedded module MC8775 from Sierra Wireless, a low talk and low standby current modem which comes in PCI Express Mini Card form factor.

A Sierra Wireless MC8775 PCI Express Mini Card supports third generation (3G) digital cellular standards and it is globally certified. An MC8775 supports tri-band UMTS (HSDPA): 850/1900/2100 MHz, with forward link up to 3.6Mbps, and quad-band EDGE/GPRS/GSM: 850/900/1800/1900 MHz, with forward link up to 216 Kbps.

Although the data modem has a PCI Express Mini Card form factor, it does not support a PCI Express electrical interface. The host and USIM interfaces, as well as power supply for the 3G/GSM modules, are provided via a PCI Express Mini Card connector. The communication between the 3G data modem and the host (Snapper CL15 module) is provided via a USB 2.0 interface.

The PCI Express Mini Card form factor allows a simple downgrade path if it is cheaper, however, the same form factor GSM data modem designed by Bluewater Systems is desired. Another benefit of having the same form factor for 3G and GSM data modems is a smaller main board and a simple upgrade/downgrade path.

Traditionally, Linux-based applications have been built using GNU tools. Even today, Bluewater uses mostly GNU tools for application development, and always for the Linux kernel.

For many years, Symbian used the GNU tools also. The rationale was that GNU tools are cheap and functional, and allow access to the widest possible developer base. However, this strategy broke with companies like Nokia and Ericsson. These companies were very happy with the idea of investing significant sums of money in better tools, and regarded the use of GNU as a missed opportunity.

Symbian has therefore moved to a dual approach, with serious developers using RealView and casual developers using GNU. The benefits of RealView include a better compiler (faster and smaller code, more features, better documentation) and better debugging support.

Microsoft has followed a different approach with Windows CE. Microsoft uses their own compiler with a number of vendor-specific extensions, and has little interest in encouraging other tools vendors. While this approach provides a highly functional, customised and integrated IDE, it forces customers to rely on the Microsoft ARM compiler, which is not exactly the best in the world.

It seems that Linux is moving to the dual-tools approach used by Symbian. This will offer the best of both worlds - low cost GNU tools and highly functional RealView tools.

To illustrate the potential benefits, recently we build a bayer filter algorithm with both GNU and RealView. This was for our Bigeye Camera project. The RealView-compiled code executed in about 400ms, versus 1.7 seconds for GNU, so RealView code was 4 times faster! This is an extreme
case (other results show around a 10-20% benefit) but it does illustrate the potential benefits of using RealView.

A few years ago ARM introduced a –gnu flag into their RealView compiler. Using this, Bluewater Systems has written an applications note for ARM on how to build application software and libraries for Linux using RealView.

Today, building Linux applications using RealView requires a fair bit of fiddling, and detailed tools knowledge. But ARM is working on this, as evidenced by the better support in each release for the last several years. The goal seems to be to replace GNU entirely in the tools chain.

Bluewater uses RealView tools for bringup, debugging Linux kernels and for debugging WinCE via EXDI2. Our engineers are itching to get a better development environment (particularly in debug) than that offered by GNU. We already have a foot in the water in this area. The next major step for us will be building our Snapper-targeted OpenEmbedded release using RealView. Time frames are unclear at the moment, but even with the current RealView tools we have been able to develop a script which
handles translation of most common command-line arguments.

The next 12 months should see a big leap forward in Linux tools support, and resulting software performance and engineer productivity. We will keep you posted on our progress.

Availability of RealView tools looks like it’s becoming a key benefit of using Linux.

When building embedded devices, one of the fundamental activities we do is coupling [suitable CPU A] with [selection of special-purpose peripherals B]. This gets you from having a feature-rich (but boring) SOM to a specialised device offered a wide range of sensory inputs and options.

Being an embedded platform however, complexity, pin counts and space is at a premium - so instead of the more powerful IDE, PCI, PCIe or similar interfaces, words like I2C, SPI and RS232 tend to crop up a lot. In this note, I’d like to focus on I2C.

I2C (Inter-Integraced Circuit,(http://en.wikipedia.org/wiki/I%C2%B2C), a.k.a. TWSI (Two-Wire Serial Interface), is a mostly-standardised interface using two control lines — SDA (Serial Data) and SCL (Serial Clock) — and in-band clocking. In practice, different I2C devices use very similar protocols — with subtle differences: clocking behavior, addressing, transaction format, etc. Basically, they’re all compatible, except when they’re not of course.

Under Linux, a wide variety of I2C  devices are supported; in addition, Bluewater regularly writes drivers as we use new I2C devices in our designs. At the time of writing, custom-supported I2C devices include:

• Chrontel CH7004 Video DAC [http://www.chrontel.com/PRODUCTS/7004.htm]
• Dallas Semiconductor DS1339 real time clock [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3470]
• Maxim/Dallas ds2782 Stand-Alone Fuel Gauge IC [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4779]
• Micron MT9T001 Image Sensor [http://download.micron.com/pdf/datasheets/imaging/MT9T001_3100_DS.pdf]
• Omnivision OV3640 3.1 mega-pixel camera [http://www.ovt.com/products/part_detail.asp?id=129]
• Analog Devices AD7414 temperature sensor [http://www.analog.com/en/temperature-sensing-and-thermal-management/digital-temperature-sensors/ad7414/products/product.html]
• Dallas Semiconductor Maxim DS4520 I/O expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4340]
• ST LIS3LV02DQ MEMS Intertial Sensor [http://www.st.com/stonline/products/literature/ds/11115.pdf]

In addition to Linux, we also use I2C devices in lightweight embedded solutions:

• Analog Devices AD5242 Dual-Channel Digital Potentiometer [http://www.analog.com/en/digital-to-analog-converters/digital-potentiometers/ad5242/products/product.html]
• Analog Devices ADG791G 4-Channel SPDT Switch [http://www.analog.com/en/switchesmultiplexers/analog-switches/adg791g/products/product.html
• Maxim/Dallas MAX7311 16-Bit I/O Port Expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3727
• Maxim/Dallas MAX7313 16-Port I/O Expander [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/4101]

Of course, this list will keep expanding as additional devices are used in products.

The secret to maximising your productivity is ensuring you have the correct tools for the job. When it comes to bringing up a new kernel for a processor that you have not supported before, an embedded ICE is a must have.

Before now Windows CE has lacked a set of high quality tools for kernel bringup. Normally the first step in CE development is the creation of a the Kernel Independent Transport Layer (KITL) so that you can debug your kernel drivers over Ethernet. The problem with this is that you need a large portion of the kernel and Ethernet driver to be working before you can do any debugging. As soon as any problems occur in the kernel, the entire debugging session locks up.

We have been lucky as an ARM tools distributer to be able to trial a pre-beta version of the Windows CE 6.0 eXDI2 drivers for the Real View ICE. The driver plugs directly into Visual Studio and provides source level kernel debugging of an embedded platform as if it was a desktop application. It has allowed us to single step through the kernel of our AT91SAM9260 platform before the kernel was up and running. No longer do we need to toggle LED’s in a seemingly random sequence of pulses to indicate boot progress!

The Windows CE 5.0 eXDI2 plugin for Platform Builder is available for general release by registering on the ARM website.
http://www.arm.com/products/DevTools/eXDI2RVI.html

The Windows CE 6.0 eXDI2 plugin will be available for general beta testing in the very near future.

Two of us are attending an ARM meeting in Hong Kong this week. There is a quite a large turn-out of companies across Asia including Singapore, Taiwan, China, Korea, and of course New Zealand.

What struck me as I looked at the group about to go out for dinner last night, was that there were more people there among ARM’s tools distributors in just a single region, than worked for ARM in total when I joined just 14 years ago.

ARM shipments passed the 10 billion mark last year and the current run rate is over 3 billion per annum. Of interest particularly is the massive growth in low-end ARM micros. The Cortex-M3 is ‘only’ shipping
about a quarter of a billion units per annum, but volume is more than doubling each year.

When the $1 micro was announced I wrote a short paper about the possible impact (available here). It seems that ARM is well on the way to making good on some of the benefits identified, particularly in terms of quality of tools, and the productivity of engineers developing with low-end microcontroller technology.

For designs to become reality, they need to go through the prototype stage. Very few designs of high complexity will work the first time, hindsight is normally 20:20. Since most of the work performed by us utilises high-density miniature components on multi-layer boards, we have developed techniques to rework boards in such a fashion that we can test our changes before producing the next revision.

Prototype designs often include provision for modification and adjustment through resistor fitment options.

If this is not the case then PCB tracks need to be cut and wires placed to rewire the tracks. These are normally kept as short as possible and fitted in such a way that no components are covered, allowing further rework to be carried out if required.

Solder mask can be scratched off to allow connection to otherwise normally non-accessible areas of the board.

Chip legs can be lifted without removal of the pa to allow reconnection of both pin and pad if required.

In extreme cases (very rare) we have replaced components with different footprints and pin outs and got these working before using them in the next revision.

As these required modifications are not known before going to manufacture, some demanding but interesting modifications have been made without any fear of harming the prototypes.