A benchmark for development and evaluation kits

The other day a colleague asked me if I was interested in reviewing the TMS570 MCU Development Kit. This is a kit for playing with the TMS570LS20216 ARM Cortex-R4F microcontroller and when I looked at the picture of the kit available on the product page on TI web site I immediately became interested. It is a big main board with a TFT display and many connectors on which a smaller board sits. The TMS570 microcontroller is designed for use in safety critical systems and as such it includes [quote TI website] dual CPUs in lockstep, CPU and Memory Built-In Self Test (BIST) logic, ECC on both the Flash and the data SRAM, parity on peripheral memories, and loop back capability on peripheral I/O. The Floating Point CPU offers 1.6 DMIPS/MHz, and it has configurations which can run up to 160 MHz providing more than 250 DMIPS. [quote end] The TMS570LS20216 has 2 MB Flash memory and 160 KB SRAM. One might be tempted to say that this is a pretty powerful MCU.

When the kit to review arrived it turned out to be not exactly what I expected, as it was just a large USB stick. The stick is so large because otherwise the MCU in its 144LQFP package wouldn�t fit on it. It came in one of those CD/DVD boxes that we know from TI and that included besides the stick a little flash light, a DVD, a USB extension cable and a flyer with installation instructions. The installation instructions are simple: insert the DVD and do a full install. So I did.

I wrote down the amount of free disk space before launching the install and the time: 9h20. More than 30 minutes and 95 (really!) mouse clicks later the installation was complete. Looking at the free disk space left over I noticed that this demo had used a whopping 7 GB! As a comparison, my Windows XP Pro folder contains 9 GB. To be totally honest, I did this installation twice, the first time I just ran it while trying to do other things. But when the number of mouse clicks and the amazing amount of pop-up windows started bugging me I decided to redo the installation and count and measure the above mentioned parameters.

Naturally I now was pressed to see the demo's, curious to discover what a USB stick with only a few LEDs and a 5 square cm MCU on it supported by 7 GB of software had to offer. Connecting the stick to my PC worked fine, it was recognized immediately, and I started the Safety Demo Software as indicated in step 3 of the installation notes. A window with six large buttons came up and I clicked on the left upper one labelled �Safety Features�. The tool now first programmed the MCU before showing a block diagram of the chip and a list of small buttons on the left that let you generate an error event in the MCU. The error is graphically illustrated in the block diagram and a little red LED is lighted on the board.

You will have little trouble to understand that I was deeply impressed by this convincing demo so I quickly went on to try the others. I clicked the Ambient Light button and a little window with a vertical bar graph showing ambient light intensity came up. A light sensor included on the stick makes this demo possible. If you keep your hand over the stick the bar drops to a few percent and when you shine the flash light on the sensor you can get it up to 100%.

Again, Wow.

So quickly on to the next demo: the Temperature Sensor. Clicking the button opens a small window showing a graph of the temperature. According to the demo the temperature was over 30 degrees Celsius, at least 7 degrees higher than the ambient temperature, but maybe it measured closely to the MCU or the PC? Anyway, this demo was as convincing as the others.

What about the LED Light Show? Again a little window pops up and this time you can start the preprogrammed light show or toggle the six blue LEDs manually. To not spoil the surprise in case you want to buy this development stick yourself I will not tell you what happened but I can assure you that I was again deeply impressed.

If I remember correctly TI was the first to introduce the concept of USB development and evaluation sticks, but where the first one featured an MSP430 MCU that you could break off after programming and then use in your own application, this USB stick seems to be a pure product of marketing. Only 22 of the 144 pins (called �test points�) are brought out to two pin headers although a CAN bus is available too. You get a compiler too, so you can write some code for the MCU but do you really need 7 GB and 95+ mouse clicks for that?

Let us now define a benchmark for MCU development / evaluation kits so we can quickly compare the ease of use and system impact of those kits: the helloWorld (hW). The helloWorld is calculated as mds/(ds*(mc+i)) where �mds� is the highest capacity hard disk available in the year of release of the dev kit (see Wikipedia, in 2011 msb = 4 TB), �ds� stands for disk space needed by the dev kit and mc means mouse clicks needed to get an LED flashing on the dev kit and finally �i� is the number of icons & short-cuts created on the desktop (8 for this kit). With such a benchmark the flash light included in the kit would get a score of infinity because it does not occupy any disk space. The mds parameter is included to introduce an element of time in the benchmark so that it would be possible to compare helloWorld benchmarks over time. You might argue that including Eclipse in a dev kit should be a separate parameter pulling the score down, but Eclipse in itself consumes enough disk space to ensure a low benchmark anyway.

The TMS570 Microcontroller Development Stick presented here scores a value of 4 TB / 7 GB x (95 mouse clicks + 8 icons) = 5.68 helloWorld [hW].

If you have any suggestions of benchmark scores for other dev and or eval (evil?) kits, please do not hesitate to send them to me so I can publish them here.

Wireless audio over 2.4 GHz

Just before the summer my contact at Texas Instruments had the excellent idea to sent me a CC85XXDK-HEADSET development kit. This is a PurePath Wireless Headset Development Kit to evaluate the new wireless audio products from TI based on the CC85xx family of RF micro-controllers. Due to a lack of time I didn't have the opportunity to write about it earlier, but I did give it a try and was impressed.

The kit contains two identical cards, one of which is configured as a master, the other as a slave. Both contain a 2.4 GHz radio and once paired (a simple operation) you can stream high quality stereo audio from the master to the slave. This works exceptionally well according to my non audiophile ears. The cards are each powered from one 1.72 Wh rechargeable li-ion battery, so it is a totally portable system. Charging the batteries is done by hooking the boards up to a USB port. TI claims a continues operation of 22 hours for this system.

I gave it a try in my garden and managed a Line of sight (LOS) distance of some 45+ meters (then I ran out of garden). It will probably go a bit further when the master is higher up from the ground. Occasionally the receiver has drop-outs, then it suddenly goes from full quality audio to complete silence, but this happens only at greater distances or when the data path becomes obstructed. Never did I hear any garbage out of the headphones.

Included in the kit is a little CC Debugger pod (with a funny rubbery feel) that you can use to reprogram the boards. This pod lets you reprogram and configure the boards using a tool called PurePath Wireless Configurator. The purpose of this tool is a bit unclear to me as there doesn't seem to be a whole lot that you can configure, but it is probably useful when you develop your own systems.

If you need a high quality wireless audio link in your system, the CC85xx is definitely worth a look!

Control a robot with a watch

Some six months ago Texas Instruments announced the Evalbot, a development platform for their Stellaris ARM Cortex-M3 microcontrollers in the shape of a little robot. It took me a while to get hold of one, but now I have one driving happily around in my living room. It is actually a pretty neat and cleverly engineered kit that you have to assemble yourself. Most parts are made out of PCB material � the two wheels for instance are each made of three disks and a rubber ring � the rest are mainly nuts & bolts. Two little motors with gears drive the wheels and everything is powered from three AA batteries.

The Evalbot is not a gadget; it is a powerful development board with wheels. In the center off the disk-shaped board sits an LM3S9B92 ARM Cortex-M3 controller (256 KB flash, 96 KB RAM and more peripherals than you will probably ever need) assisted by a tiny 96 x 16 blue OLED display, 6 push-buttons (including the on/reset and the off buttons), an Ethernet connector, a USB host port, a USB device port, a USB debugger/programmer port (ICDI), a micro-SD card connector, a speaker, power supply, JTAG, two LEDs and probably more that I am overlooking now; and two motor drivers. Thanks to the battery holders (with batteries) on the bottom of the board the whole thing is pretty heavy and the rubber �tires� prevent sliding it off your desk when you hook the board up to a computer with a USB cable that wants to unwind the wrong way around.

A special wireless expansion port is available too on which you can plug a CC1101EM sub-1 GHz transceiver, which will get you an 868 or 915 MHz radio link. The James Bond part of this setup is a third kit from TI, the eZ430-Chronos based on the CC430F6137 sub-1 GHz RF SoC. This is a combination of a biggish but stylish black watch with a large character display and a USB access point for your PC. Once connected you can control your PC with the watch, although it takes some exercise to do it properly. But... you can also use the watch to control the Evalbot! An integrated accelerometer lets you influence the driving direction of the robot by tilting and rotating the watch. Cool huh? The watch in itself is actually a dev kit and you can reprogram it with your own application.



Programming the dev kits is done with Code Composer Studio 4, the Eclipse-based dev environment from TI. A license file is included with the Evalbot kit, but what exactly this enables is not clear to me. I did read something somewhere about code sizes & limits, but I forgot where. Anyway, all the source code for the Chronos controlled Evalbot is available, it compiles without warnings and errors and programs fine. This really is a fine (but strange) development kit.

FRAM - true unified memory

Somewhere in the beginning of 2007 I won in a lottery held by EPN magazine an evaluation board from Ramtron sporting their most powerful 8051 clone, the VRS51L3074, which could be programmed and debugged with a small USB piggyback board. The very special thing of the Ramtron controller was the 8 KB of non-volatile ferroelectric memory (F-RAM) it included.
Instead of putting the board in a box, I actually used it in a project. I used the F-RAM to store some parameters in. The evaluation board also had several other F-RAM chips on it, but I did not use those. Once the project finished (it was published in the January 2009 issue of Circuit Cellar) I (almost) forgot about F-RAM and never heard from Ramtron again.

This year at the Embedded World show in Nuremberg I again came across F-RAM, now spelled FRAM, at the Fujitsu stand. It turned out that they started licensing the technology from Ramtron and that they had put some of it in their MB95R family of 8-bit MCUs. Fujitsu also offers stand-alone FRAM devices up to 4 Mbit.

This week Texas Instruments announced their brand-new MSP430FR57xx family that includes up to 16 KB of FRAM, licensed at the same source. The people at TI are very excited about it and have high expectations for the future.

So what exactly is FRAM and why would you be excited about it?

The F in FRAM stands for ferroelectric (and not ferromagnetic nor Fujitsu) because it �uses ferroelectric film as a capacitor for storing data. Possessing characteristics of both ROM and RAM devices, FRAM features high speed access, high endurance in write mode, low power consumption, non-volatility, and excellent tamper resistance.� (Source: Fujitsu)
How it all works at the atomic level is not so important here, let�s jump to the bits interesting for people wanting to use FRAM in a design.

First there is speed. Compared to flash memory FRAM is way faster, TI claims a 100 times faster. According to Fujitsu, FRAM is 30,000 times faster than EEPROM.
Secondly, there is power consumption. FRAM uses very little power, 250 (TI) to 400 (Fujitsu) times less than flash or EEPROM. This is active power. Interestingly enough FRAM has a slightly higher leakage current than flash memory, so power consumption in sleep mode is slightly worse.
Less energy and higher speed means cost savings, not only on the power budget, but also on the production budget for the high-volume people that measure the time it takes to program a device on the production line.

Then there is endurance. Flash & EEPROM memory cells are specified for some 10,000 write cycles, whereas a FRAM memory cell can be rewritten more than a trillion times! (Fujitsu is a bit conservative here, TI rather optimistic.) This kind of endurance combined with the higher speed means that FRAM can be used in place of SRAM.

FRAM works with low programming voltages down to 1.5 V. Replacing a block of flash memory by a block of FRAM of the same density then saves die space because FRAM doesn�t need a charge pump. Smaller means cheaper. Also, because of the low programming voltage new applications become possible where the higher flash programming voltages are currently considered dangerous.

Finally, FRAM is less sensitive to external fields and alpha particles than flash memory because the memory cell capacitor�s dielectric is much thinner than the one of a flash memory cell. The thinner the dielectric the less distance there is to develop a dV over and the smaller are the chances to (accidentally) modify a bit.

All these advantages were known from the start, so why did it take so long before FRAM made its way into non-Ramtron MCUs? Well, I don�t know about Fujitsu, but according to TI the main reason was the incompatibility of the technology. Five years ago FRAM was done in 350 nm technology, which was too big to use it in TI�s chips. Now they brought it down to 130 nm, which is a perfect fit.


This is a picture of a demo board showing off the low-power capabilities of the new MSP430 family, targeted at energy harvesting applications. Battery backed SRAM, flahs or EEPROM can all be replaced by FRAM, the speed and low power requirements of FRAM make external super caps unnecessary. Higher speed equates to shorter up times so ultra-super-low-power applications seem to be ideal.

Since anyone can license this technology from Ramtron, we can expect other parts from other manufacturers to appear in the next months or years.

Jeez, why didn�t I buy Ramtron stock at the time when nobody cared?