I believe that I should start out saying that I like both the MSP430 AND the PIC24 series.  I was doing some assembly coding on the MSP430 close to the time that I was doing some assembly work on the PIC24 and I noticed that things were taking significantly longer to code on the MSP430.  It just seems like the PIC24 and dsPIC series simply have more instructions available.

Inspired by this thought, I consulted The Oracle and found this paper from 2006 (revisited in 2009) comparing the MSP430 to several other competitive architectures.

Flash Memory Usage

In all tests, the PIC24 and dsPIC had nearly twice the flash memory used for program space.  This is not surprising as I know that the PIC24 has a 24-bit instruction width while (I think but could not confirm) the MSP430 has a 16-bit instruction width.

This instruction width is a double-edged sword.  By making their instructions wider, Microchip has made more instructions available to their users.  Even the lowliest PIC24 has a multiply and div instruction - not the case on the MSP430!

Execution Time

Unless I'm reading the paper wrong, it looks like the PIC24 wins on execution time while the MSP430 wins on code density.  There are some caveats to mention.  The first is that the dsPIC didn't handily trounce the PIC24 and the MSP430 in the FIR filter benchmark.  This tells me that the IAR compiler that they are using probably doesn't take into account the dsPIC's DSP engine.  If that is factored in, MAC operations become very fast and benchmarks such as FIR filters will often half the execution cycles.

An aside regarding raw speed for a moment.  The MSP430 tops out at 25MIPS while the PIC24 and dsPIC33 series both top out at 70MIPS (look at the 'E' series, as in PIC24E).  The ability to scale the clock up to that point can be seriously advantageous if speed is what the application requires.


The other distinguishing thing about the dsPIC and PIC24 series is the 'completeness' and selection of the peripherals.  The Microchip offerings tend to have more transistors dedicated to making coding easier.

A quick for-instance regarding a recent SPI project in which I was writing code for an MSP430FR SPI slave.  I was working with a high-end MSP430FR series microcontroller that cost me nearly \$10/part and I am dealing with SPI transfers that only have a 1-deep buffer.  This doesn't sound so bad, but the Microchip offerings tend to have 4-deep FIFOs on this sort of thing, which gives you more luxury than you might imagine.  If you only have a 1-deep FIFO and you are trying to code a slave device to be responsive at 1MHz, you have to tread very carefully.  If another interrupt is active at the time, forget about it.  The 4-deep FIFO greatly reduces the strain on the code.

Memory Capacity

That said, the MSP430FR series uses ferromagnetic technology that allows you to use the program memory just like you would use SRAM and at full speed.  I have never had so much potential RAM available and that aspect has definitely added some 'slack' in the form of buffers.  I can set back and let the buffers fill and then respond to them when I can process multiple buffers at once.  I don't see anything on Microchip's offerings that seem to be heading in this direction.


In the future, I am likely to use both TI and Microchip offerings for different applications.  When the application demands a lot of peripherals, I will probably lean towards Microchip.  When it needs to be single-tasked and cheap OR needs lots of RAM (ferromagnetic memory), I will lean towards TI.

© by Jason R. Jones 2016
My thanks to the Pelican and Python Communities.