LPC1347 to LPC1343 Comparison

Posted by:  |  Wednesday, March 28, 2012

Go Back

NXP recently unveiled its new LPC1345/6/7 processors. It’s a welcome addition to the 1300 family, since they’ve been keeping busy steadily adding new members to the LPC1100 family, but it’s M3 twin-brother felt somewhat neglected by comparison despite being a fairly popular chip for them. The new LPC1347 seems to do a good job of addressing this imbalance, though, and introduces almost everything I found myself wanting in the 1343, without having to move up to the LPC1700 family.

While the migration process from the 1343 to the 1347 will be a bit bumpier than I would have liked, the effort seems worthwhile. The main issues are that the 1347 uses an updated and reorganized GPIO block, as well as a newer USB block. The LPC1347 feels like it gives you a lot more room to breathe, though, adding space for feature creep, and pushing the ceiling a bit higher than the 1343. I sometimes found myself struggling with 32KB flash, and missing a second SSP block on the USB-enabled parts, both of which are addressed on the new chips.

Key Improvements





ARM Cortex-M3 2p1

ARM Cortex-M3 r2p0


12-bit, 500 kSamples/s

10-bit, 400 kSamples/s


64 kB


SRAM [1]

8+2+2 kB

8 kB

GPIO Blocks

2*32 pins

4*12 pins


4 kB


SSP Blocks



USB ROM-based drivers [2]



Wakeup from Deep-Sleep/Power-Down


GPIO, WDT Oscillator


QFP64, QFP48, QFN33

QFP48, QFN32


[1] The LPC137 has three separate blocks of SRAM, with 8kB general purpose SRAM similar to the LPC1343, but now also adds 2kB of SRAM for USB and another separate 2kB general-purpose block. The separate USB memory is a helpful addition since the 1343 had to share this memory, and if you were using the ROM-based USB drivers, you had to modify your linker script to avoid using the first bit of SRAM on the LPC1343.

[2] The ROM-based USB drivers on the LPC1347 can also be made to work with custom classes

Pin Configuration Comparison

The images below show a comparison of the QFN33 and QFP48 packages and pin configuration to give you an idea of what has changed between the two chipsets.  QFP64 isn't shown here since it only exists for the LPC1347.

QFN33 Comparison of LPC1343 and LPC1347

QFN48 Comparison of LPC1343 and LPC1347

A Note on Packages and GPIO Pins

The new GPIO block is the same one used in the similar ARM Cortex M0-based LPC11U24, which makes it easy to optimize for cost later and switch between the two devices, but it’s also unfortunately a breaking change compared to the 1343. All pins are now based on two GPIO block – PIO0[0..31] and PIO1[0..31] – rather than the previous four GPIO blocks on the LPC1343. This is potentially the biggest change from a SW migration point of view.

In terms of packages, I’ve always been happy with the QFN33 and QFP48 options – that seems to be the right physical size for chips like this – but there were one or two moments where I found myself wishing for just a couple more GPIO pins. This was particulary the case with larger TFT LCDs that used 16-bit only interfaces, or could have performed much better with a 16-bit interface on a single GPIO block rather than an 8-bit interface sending the data/commands in two separate chunks. Even if the LCD works with 8-bits, using 16-bit allows you to more than double the screen update rate, giving you the option to use larger LCDs with acceptable frame rates, or just freeing up resources for other tasks like improving the UI.

While the reorganized GPIO blocks pose a problem for SW migration, they are also clearly an improvement in the sense that you now at least have the option to use 16-pins on the same GPIO block for a large data bus, using bit-banding for fast single-cycle writes to that bus. With only 12-pins per GPIO block on the LPC1343 this was physically impossible to do.

If you are really short on GPIO pins you also have the option with the LPC1347 to move up to the larger QFP64 package without, having to do an entire rewrite and switch to the larger LPC1700 family. I was never able to find a pin arrangement for 16-bit LCDs that fit on the LPC1343, but this looks perfectly doable now with the LPC1347 in QFP64.

USB ROM Drivers and Bootloader

The ROM-based USB drivers were by far my favorite part of the LPC1343, along with the USB bootloader that relied upon them.  This brilliant little addition allowed you to save a couple KB of flash space by not having to include your own USB stack, and also made it more or less impossible to brick your device since you could update it with no external HW or SW requirements.  Just boot into USB bootloader mode, and drop the updated firmware onto the flash drive that appears, and reset.

That said ... the 1343 had a number of limitations.  It only worked with MSC and HID classes, and the HID, while useful, was limited to a single report size.  If you wanted or needed multiple reports, you still had to implement your own USB stack.  It also seemed unfortunate that USB CDC was't implement since many an engineer still loves their command-prompt.

The LPC1347 addresses almost all of these concerns, and more.  It now includes ROM-based support for CDC and DFU, as well as the functionality to implement custom classes, though I haven't had time to look into the latter yet.  The HID support is also improved, and the bootloader is of course still intact.

Apparently, these ROM-based drivers will also be the same ones used on newer LPC1000 members with USB-ROM support, so it should be relatively easy to switch to other devices, such as the LPC11U24, etc.  NXP's nxpUSBLib currently includes support for using both traditional SW-based and ROM-based drivers, which is likely the best path to choose if you want to ensure compatibility across a variety of LPC1100 and LPC1300 chips.

Overall Opinion

Overall, this is exactly the chip I found myself wishing the LPC1343 was these past couple years of working with it. It addresses most of the issues I had with the LPC1343, and bridges the gap between the LPC1343 and the low-end LPC1700 devices, giving some more headroom in the LPC1300 before you really have to throw in the towel and move up the food chain to the larger chips. The different IP blocks in the LPC1347 pose a problem for SW migration, and I think I’ll end up prematurely bald, gray and single if I try to make an LPC1347 version of the LPC1343 Code Base from scratch again, but I’m definitely interested in migrating new projects to the chip, and selectively updating certain drivers.

I can see myself using this chip a lot with project requiring a large TFT LCD or OLED display and a decent user interface, since the extra 32KB flash allows you to include more fonts, and improved UI elements. I’ve recently been working on adding simple 2 and 4-bit anti-aliased fonts to the LPC1343 library, for example, and while 2-bit fonts are only 2x the size of 1-bit fonts but are visually much more appealing (especially in Italics), it’s hard to fit more than one font in 32kB with all the other drawing code and plumbing that you need in the firmware. Having an extra 32kB will allow me to add an entire family of fonts to projects (regular, bold and italic) using much higher-quality anti-aliased versions, and maybe offer some improved UI elements like more complex dialogue boxes, etc.

That said … don’t expect to see a completely updated library in a few weeks time. It’ll definitely take some time to start putting together anything nearly as complete as the current LPC1343 Code Base, which I’ll definitely continue working with simply because there’s so many thousands of man hours put into it already.

Updated 30 March 2012 to include more information on USB ROM-based drivers, and added DFU to the supported class list.

  • Facebook
  • DZone It!
  • Digg It!
  • StumbleUpon
  • Technorati
  • Del.icio.us
  • NewsVine
  • Reddit
  • Blinklist
  • Furl it!