Go Back

First Thoughts on NXP's New M0+ LPC800 MCUs

Monday, November 19, 2012
NXP asked me to have a look at their new ARM Cortex M0+ based LPC800 family, and being unable to refuse any offer to get my hands on early silicon before the masses I agreed in a heartbeat.  I've been interested in the M0+ since it was announced (and as a long-time M0 user), and while the LPC800 family is positioned differently than I expected I think NXP actually made a very intelligent choice to position the chips where they did.  I won't rehash everything here, but if you're interested in my first opinions of the LPC800 you can see the blog post I made for them over at lpcnow.com: First Thoughts on NXP's New M0+ LPC800 MCUs.  Now that I have some real HW sitting in front of me I've setup a toolchain that supports the M0+, I'm looking forward to trying these chips out in the real world.

Update (17 Dec 2012): I wrote a followup article on the LPC800's Switch Matrix as well.

Full story  | Comments (3)

Chibi Meets Mr. Dislocated Green Thumb

Sunday, June 13, 2010

I really wanted to call this entry: "Chibi Meets Mr. Dislocated Green Thumb: Or, How to Suck a Bit Less and Gardening", but it didn't quite fit in the title.  In any case, gardening isn't exactly a topic you find on most engineering-centric sites ... but since I'm determined to try not not to kill every green and leafy thing that I come into contact with this year, I thought I'd try to compensate for my decidely non-green thumbs with technology.  How am I going to do that?  With a bunch of RF transceivers, sensors galore, and a gratuitous graphical desktop-based data logger of course!

We recently published a couple brief tutorials on Chibi, a light-weight, open-source 802.15.4 stack from Freaklabs.  Chibi is wonderfully easy to use, and the AT86RF212 is a perfect match for this project since 868/915MHz provides excellent range and signal penetration (compared to 2.4GHz), and can safely make it through brick and concrete walls into the house or apartment. 

LPC1114 868MHz Radio TransceiverWe're just doing some final testing on an LPC1114-based wireless transceiver we made with this project in mind.  They're relatively small (~3x5cm), and are designed to run off small 1200mAh LIPO cells.  They have an on-board temperature sensor for accurate analog conversion of non-linear temperature-sensitive devices, and we've broken out the I2C pins, 4xADC inputs, and UART so that a variety of analog and digital sensors can be connected and logged.  The UART is convenient since it provides a means to communicate directly with the board, update the firmware via ISP, or figure out why something isn't working.

Garden Sensor Network LayoutThe idea goes something like this: We'll have one central PC-connected 'Garden Monitor' acting as a hub (based on the LPC1343 Reference Design with an AT86RF212 antenna attached), which will receive all incoming messages and data, logging and manipulating it as required.  Complimenting this will be numerous battery powered sensor nodes out in the garden (see the photo above) checking things like soil humidity, ambient temperature, and the amount of sunlight being received per day.  The communication will be largely one way -- from the sensor nodes to the hub -- since the nodes will spend most of their time in deep-sleep mode to conserve battery power.  They'll take sensor readings at appropriate intervals, and every 15 minutes or so send the collected data to the hub and check if there are any relevant messages waiting for that specific node.

In theory, we'll have one node for every type of plant (since they all have different requirements and are in seperate containers), and can monitor the key information on the PC or via alerts on a simple webpage or via twitter <sigh and roll eyes here /> or something similarly already-been-done-2.0.

Remote Sensor Node Communication Scheme

We're just finishing off the HW and the firmware for the devices, and have been writing drivers and lookup tables for things like the Vegetronix Soil Moisture Sensors and some analog and digital sensors for ambient light, etc.  Once the HW has been tested a bit more, and we have a chance to start working on the SW client we'll add a new project page with all the files.  We'd like to try to make something as generic as possible to allow people to log any kind of information later on.

In any case, we'd be glad to hear what other people might like to see in an open-source wireless data logging system like this. It has a lot of fun-factor potential, but can probably be quite useful as well. Feel free to drop us a line and let us know what you think!

Update: And yes ... tomatoes, plural, is spelled with an E. Oops. :-)  Wonderful vector images courtesy of DragonArtz Design.

Full story  | Comments (4)

Waking up from Deep-Sleep on the LPC1114 and LPC1343

Monday, May 03, 2010

There have been a number of questions on different forums about waking up from Deep-Sleep mode on the LPC1114 or LPC1343 lately, partially because the current user manual isn't very clear on this (for example, it's not terribly obvious whether a timer is able to run in deep-sleep mode or not).  After trying to wrap our head around this ourselves, we ended up contacting NXP directly, who were able to clear the matter up for us.  It is indeed possible to wakeup from deep-sleep in software using a timer, though it may not be exactly how you expected.

You enter deep-sleep mode by indicating which peripherals should be turned off, setting up the different registers controlling the sleep modes, and sending the WFI (Wait For Interrupt) command.  To exit deep-sleep mode, you simply need to change the state of a pre-configured wakeup pin (0.0..1.0 on the LPC1114 and 0.0..3.3 on the LPC1343), and your device will wakeup (entering the wakeup ISR).  That's relatively easy and the manual is clear on that ... what's a lot less clear is how you can wakeup from Deep-Sleep mode purely in SW (or if it's even possible).  It is indeed possible, but the only way to do so is with the following steps:

Configuring the LPC1114/LPC1343 to Wakeup from Deep-Sleep
  1. Before entering deep-sleep, switch the main clock source to WDTOSC (for the lowest possible power consumption)
  2. Next, find an available wakeup pin with a timer MAT (for example pin 0.1 on the LPC1114 and LPC1343 has CT32B0_MAT2)
  3. Set the matching timer delay to an appropriate length (for example, a 10s delay on CT32B0)
  4. Configure the timer's match control register to set the MAT pin (MAT2/0.1 in this case) high on match
  5. Enable the wakeup interrupt for the MAT pin, and enable the MAT pin as a wakeup source
  6. Start the timer
  7. Send the "WFI" command and enter Deep-Sleep mode

What this will do is allow the timer to continue running in deep-sleep using the WDTOSC as a clock source, and when a match occurs it will toggle the MAT pin from low to high, waking the device up.  At that point, you will enter the WAKEUP IRQ handler, and you can switch the main clock source back to the internal or external oscillator and adjust the clock accordingly.  (For reference sake, keeping a 32-bit timer running in deep-sleep with the WDTOSC at 10kHz consumes about 2uA more than if the device is put in deep-sleep mode with no SW wakeup enabled.)

If this isn't clear, we've added examples of entering and waking up from deep-sleep in both the LPC1114 and LPC1343 Code Base.  Both devices behave identically, aside from the smaller number of wakeup pins (13) on the LPC1114 and the difference peripherals that can be disabled in deep-sleep.  For an example, see pmuDeepSleep in pmu.c, or have a look at the latest source code on Google Code.

Using the above code, you can enter deep-sleep, and then wakeup after a fixed delay in seconds with the following commands (this assumes that you are using an LPC1343):

uint32_t pmuRegVal;

// Initialise power management

// Inidicate which peripherals should be disabled in deep-sleep
            SCB_PDSLEEPCFG_IRC_PD | 
            SCB_PDSLEEPCFG_ADC_PD | 

// Enter deep sleep mode and wakeup after 5 seconds
pmuDeepSleep(pmuRegVal, 5);

Full story  | Comments (3)

First LPC1114 Boards Assembled

Tuesday, December 08, 2009

LPC1114 Reference Design with Blinking LEDWe hand-assembled the first two prototypes of the LPC1114 board, and -- with an audible sigh of relief -- managed to get an LED blinking without too much trouble.  We were unable to get SWD working in Keil uVision 4.0.1 using a Segger J-Link, but the device at least recognises that an "M0" is connected so it may simply be an issue with either uVision or the Segger drivers since there still isn't official support for the LPC1114 in uVision 4.0.1 (though curiously the LPC1111, LPC1112 and LPC1113 are listed).  ISP works flawlessly, though, and the latest version of FlashMagic does support the entire LPC1100 family so we simply deployed the compiled .hex file to the board using ISP.

We were intially thrown off by a bad LED (rare, but at least it wasn't related to the board itself), but after switching it out with a new one and putting a few lines of code into uVision the LED was happily blinking away off a single AA battery (we're using an NCP1402 step-up converter with the current design).  We used the freely available, 32KB-limited version of uVision, for reference sake, since we tend to use Rowley's Crossworks for ARM internally and try to stick to GCC-based code for portability reasons.  Given the lack of current support for the M0 Core, though, Keil was the natural choice.  Thankfully, they seem to have improved the IDE a little bit since the last time we used it.

We'll need to more thoroughly test out all the peripherals and try to put some basic code together before we release any schematics or board files (we don't want to mislead anyone with a flawed design), but hopefully by early January we can have a working schematic, board layout and some basic code for the LPC1114.

UPDATE: It's not really fair to publish any exact figures before the final chips are released and widely available, but suffice it to say that after some quick tests we're more than impressed with the energy consumption versus a comparable ARM7-based chip like the LPC2103.  Many times impressed, you might say! ;-)
UPDATE 2: We broke down and published a beta schematic for the reference design (not that the LPC1114 is particularly hard to design a board for). You can see it at the new LPC1114 Reference Design project page.  We'll publish the actual Eagle files once we are more confident that we have a trustworthy design.

Full story  | Comments (0)

  1. 1
  2. 2
  3. Next page