Microcontroller Showdown, Conclusion

The last chip in the comparison is the Z16F2810. When I started the tests I got a Loop overhead time of only 0.64, which made me think the chip might be very fast. When I moved on to the multiplication and division tests, though, some of them completed in only 0.89 seconds. After looking at the assembly generated during compilation I noticed that the arguments of division were only being copied to the register that holds the answer. It seems that even though all the variables were declared as volatile, the compiler decided to optimize the division out anyway. This made me think the compiler was simply ignoring the volatile keyword but the assembly generated when accessing volatiles is slightly different. Loops involving them take about 25% longer to run, so it does have an effect. The only way I could prevent it from optimizing out multiplies and divides while keeping optimizations was to declare the involved variables globally. The User Manual for the chip helped a lot when looking at this problem and I think it is really well done.

For arithmetic operations, the chip did very well. It was always faster than the MSP430 and almost as fast as the LPC1114 for most things. One place it did very well was division where it outperformed all the other chips by a large margin because it has a hardware divider. General GPIO is also pretty fast, although it does not have any special mechanism for speeding it up like the masks on the LPC1114 or the constant generator on the MSP430. BCD Add was about the same as the MSP430. BCD Multiply was faster than on the MSP430 but still much slower than on the LPC1114.

After running all the chips, here are my conclusions:

• MSP430 Easy to use and reasonably fast. Good choice for small jobs and low-power projects. Held back by low clock speed (16MHz), small memory, and lack of hardware multiplier.
• LPC1114 The fastest chip by far for everything but division and 8 bit math. Lots of RAM and Flash. Straightforward to use, although there is no real community. Very fast GPIO with masks. Top choice for calculations.
• DS89C450 Fast for 8 bit math, although slow at shifting. Very fast GPIO since each GPIO pin is mapped to its own byte in memory. Extremely slow at BCD calculations. The only real advantage is the external memory bus.
• AT89LP6440 Similar to the DS89C450 but lower clock speed and performance. 
• Z16F2810 Good performance but inferior to the LPC1114 in everything but dividing. Debugger is very useful but the IDE itself is sometimes clunky. Enough RAM and very big Flash (128KB). PLCC package is inconvenient.

In the future I plan to do a few more projects that will need the extra horsepower for the LPC1114. For other smaller jobs I will stick with the MSP430.

Results are after the break.

Z16F2810 Programmer

The last chip in the comparison of microcontrollers is the Z16F2810. It comes in PLCC and is the only part in the ZNEO line that isn't QFP only. In order to program the chip I soldered a PLCC socket to perfboard with headers for one of the GPIO ports and for an FTDI cable.

In the beginning I was excited about the PLCC socket but it turned out to be somewhat inconvenient to solder due to all the jumper wires needed to reach the inside row of pins. Next I connected the chip to the FTDI cable and tried to access it over UART as described in this Application Note about the bootloader. I had overlooked that the UART bootloader is not part of the ROM and has to be loaded over the one-wire interface normally used to program the chip. Until I realized this I removed the chip several times looking for faults in the circuit and managed to crack the socket with a screwdriver on the third removal. Zilog sells a specialized cable for programming their chips through the debug pin and I hoped to make something similar that would work over an FTDI cable. One forum post I found was really helpful. It showed what the cable looks like inside:

It seemed pretty unlikely that I could recreate this on my own. Later in the post someone mentioned that some of the Zilog documents show how to program the chip with a serial cable and only one diode. All I had to do was solder the diode and a 10k pull-up to the debug pin to make it work with the FTDI cable.

The next hurdle was the software. The picture above shows a USB SmartCable which will work with the ZNEO version of the ZDSII software Zilog offers for programming and debugging. The ZNEO version of ZDSII does not, however, work with the Serial SmartCable which the FTDI cable would replace. The Z8 Encore! version of ZDSII does support the cable. The same forum post explains that you can simply copy the file SerialSmartCable.xdt from the debugtools directory of the Z8 version to the debugtools directory of the ZNEO version. You will also need a copy of the file NxZNeoSerial.dll. Another website, also in German, explains that a copy of this file comes with Smart Flash Programmer 2.2.0.

The ZDSII IDE works well enough for writing code, although I still prefer to use Code::Blocks. The debugger is really handy. You can set break points and look at the disassembly compared to the C source as the program is running, as well as examine memory and registers. It is a little unwieldy, however, to go through the whole process of disconnecting, compiling, reconnecting, transferring, and restarting every time code is recompiled. In my opinion there should be a single button to recompile and run code. Another small gripe is that when code starts to run, the debugger automatically halts on the first instruction and jumps to that place in the source. Unfortunately, that is always start-up code, so every time you press Go it opens the start-up assembly file supplied with the compiler and waits for you to continue. This is just annoying since it has to be closed every time.

The IDE uses make with its own compiler. Running this compiler from the command line shows that there are many compiler options but the only one available in the IDE is "Limit Optimizations for Easier Debugging." There is no way from the IDE to specify arguments to optimize for speed or size specifically. You can, however, export a makefile from the IDE and run make on its own. Doing this I was able to edit the makefile to add the flags for speed and size optimizations but neither of them produced any difference. I copy the file generated by make to the output directory of an empty project that I keep open in the IDE. Because compiling is done outside of the IDE, I can upload the file to the chip without having to disconnect and reconnect.

Microcontroller Showdown, Part 1

Recently I bought some LPC1114 microcontrollers from NXP. They come in DIP packages and feature an ARM Core M0. Although comparing the clock speeds of different architectures is not the best indicator of speed, I would still expect this chip running at 50MHz to be faster than the MSP430s running at 16MHz that I have been using until now. Later I found out that the flash of the LPC1114 only runs at 20MHz, which will bottleneck any programs running from there. Running from RAM would be much faster but the chip only has 4KB of SRAM. On the other hand, it does have a three-stage pipeline. Value-line MSP430s only have instruction-prefetch. All of this makes it a bit difficult to know how much faster one chip would be than another, so I have decided to run a few benchmarks.

Another architecture I have been interested in lately is the 8051. This is much older than the other two architectures I want to check but it remains popular with some people. Instructions take 12, 24, or 48 cycles to execute, which is less efficient compared to an MSP430 which needs only 3-6. Some modern 8051s feature a full-pipeline and clock speeds over 30MHz. These are interesting to me because I think they may be able to outperform the MSP430 in some ways. I was able to sample some AT89LP6440s from Atmel and a DS89C450 from Maxim Integrated which both come in DIP packages. The AT89LP6440 can fetch one byte per clock cycle from memory, meaning that it should in practice run slower than 1 MIPS per MHz but still much faster than other 8051s. It does have a hardware multiplier which surprised me to find out. The datasheet for the DS89C450 lists it as one clock-per-machine cycle, so it should run faster MHz per MHz than the AT89LP6440. It can also run at 33MHz compared to the AT89LP6440 at 20MHz.

The last microcontroller I will test is the Z16F from Zilog. This is a 16-bit CISC design descended from the 8-bit Z80. According to the Zilog website, it outperforms many RISC designs in the same class. It can do 32-bit ALU operations, has a hardware multiplier, and does some pipelining. I know the least about this chip but the design is interesting and I may use it in a future project if it performs well.

Here are some specifications of the microcontrollers that will be involved:

Microcontroller	Clock Speed	RAM	Flash	Core
MSP430G2553	16MHz	0.5KB	16KB	MSP430
LPC1114FN28	50MHz	4KB	32KB	ARM Core M0
AT89LP6440	20MHz	4KB	64KB	8051
DS89C450	33MHz	1KB	64KB	8051
Z16F2810	20MHz	4KB	128KB	ZNEO

There are many factors that need to be taken into account when choosing a microcontroller. For this test I have decided to test only calculation speed and to ignore other factors such as the peripherals. Consequently, the results will not be relevant to some people. This also will not tell me which microcontroller is the best overall. These particular chips are dissimilar in many ways and this is not a comparison of microcontrollers from the same class. They are only being compared because I am curious about them.

One good reason to do this test is so that I have an excuse to set up the tool chains and programmers for all of these chips. This will take some time so I will release the results in a few parts. It will give me a break from the RPN Scientific Calculator I am making.