Go Back

LPC1xxx 1GHZ Wireless Board Preview

Thursday, March 14, 2013
It feels like I've been working on these boards forever -- and to be fair there's literally years of effort and >20K EUR in expenses here -- but I finally ordered a first batch of the USB stick and wireless node PCBs this week.  There's always something to improve, but overall I'm very happy with the HW and the related code base, and I think the boards are a significant improvements over any other project that I've posted here.

Admittedly there's nothing whatsoever exciting about yet ANOTHER wireless sensor node or platform, and it's probably more expensive than it needs to be if you went with an integrated MCU + radio, etc., but my goal was never to create a commercially viable board but something that was useful to me and met my own goals of having a rapid wireless prototyping platform based on an MCU family that I liked, and using fully open source stacks and toolchains.

RF1GHZUSB


RF1GHZUSB-REV-A PCB

  • LPC1347 (72MHz ARM Cortex M3, 64 KB Flash, 12KB SRAM, 4KB EEPROM, 12-Bit ADC)
  • Supports USB CDC, HID, and MSC out of the box
  • Easy to use CLI to send and receive data via USB CDC
  • Optionally supports USB HID command set
  • USB Bootloader for easy firmware updates (no extra HW required)
  • 4 layer PCB to keep reasonably clean routing and a clean RF section
  • Designed to fit in an inexpensive USB enclosure if desired (~$3 in single quantities)
  • RF section designed to work equally well at 868MHz (EU) or 915MHz (US), with excellent range and performance
  • SMA connector to attach various types of antennas (directional, small quarter-wave, half-wave, etc.)

I designed this small USB stick to be able to co-ordinate other sensor nodes from anything with a USB slot.  The main goal was to use a Raspberry Pi (Beagle Bone, etc.) as a cheap always-on network co-ordinator, but I also designed them with USB Host in mind.  My thinking was that with a single well-design USB stick I could plug different radios into mid-range MCUs with USB Host (LPC4357, etc.) and support various frequencies, modulation schemes, etc., without having to go through the FCC approval process more than once, and without locking myself into one choice on expensive HW.

RF1GHZNODE


RF1GHZNODE-REV-B PCB

  • LPC11U37 (50MHz ARM Cortex M0, 128KB Flash, 10KB SRAM, 4KB EEPROM, 10-bit ADC)
  • On board SD card with FAT32 file system support (USB MSC can enumerate as a mass storage device pointing to the SD card on the PC)
  • Built in LIPO charger (just plug in a USB cable and the board switches to USB power and charges the LIPO at the same time)
  • Supports USB CDC, HID and MSC, including HID Keyboard and Mouse emulation and auto config for multiple USB profiles (CDC + HID, etc.)
  • Easy to use and extended CLI
  • Out of the box support for many sensors available from Adafruit, including a unified sensor system to make adding new sensors as painless as possible
  • USB Bootloader for easy firmware updates
  • Easy to use radio framework (Chibi) that works out of the box
  • 4 layer PCB with dedicated GND and power planes, and an isolated RF section
  • Designed to fit inside an inexpensive IP65 (water resistant) enclosure (Adafruit Product 903)
  • RF section designed to work equally well at 868MHz (EU) or 915MHz (US), with excellent range and performance
  • SMA connector to attach various types of antennas (directional, small quarter-wave, half-wave, etc.)
  • Switch between 3.3V and 2.2V supplies on the fly (saves power), and board can be run as low as 1.8V

These were intended to be the workhorse, battery-powered sensor nodes. I spent a LOT of time and effort trying to get the lowest current level possible in sleep mode (currently ~20µA with SW wakeup, but this should in theory be able to go lower with more time and effort).

What's the point?

Both of these boards are really just a labour of love.  I love ARM, I love wireless, and I've spent so many years and so much time and money on these boards -- and earlier boards that made these ones possible -- that it just seems a shame to me that no one else was benefitting from all that work and effort.  I designed these boards purely for personal use and as a platform to make rapid prototypes myself ... and I definately have no illusions that there's big money to be made in yet another wireless sensor node platform.  But I'm convinced it's a pretty good bouncing board to test out some ideas, and while these boards and the library are far from perfect, they're a lot better than many of the closed source systems that currently exist.

What about the firmware?

I've signed off on a new combined LPC11U24/LPC11U37/LPC1347 code base that allows you to switch between any of the three MCUs with just a small change in the config file.  I'm just waiting for the (I hope) final PCBs to come in in two weeks time, get a small batch assembled, and then get them into the hands of testers for some feedback.  Once I can work out the major bugs from the first batch, I'll release the board files and code base into the wild ... but I'm extremely happy with the code base as is, and I really think it's an excellent starting point for anyone interested in doing anything serious with ARM and 802.15.4 wireless connectivity.

When will it be ready?

I can't make any promises here.  Again, this is really just a labour of love not a commercial endeavour ... but I hope to assemble a first batch of 100 or so boards in a few weeks, and to send them to some friends and colleagues, then make some quick changes based on that feedback.  I also need to spend some time working on some SW on the Raspberry Pi, etc., to manage the sensor network, and haven't had 5 minutes to do that yet.  Hopefully in 6-8 weeks, though, I can have something ready for a wider audience.

Full story  | Comments (6)

LPC1347/LPC11U37 Update

Sunday, January 20, 2013
LPC 1347/LPC11U37 Wireless Test Boards

I finally found a few minutes to test the latest PCBs for the LPC11U37/LPC1347 and I'm pretty happy with both the test HW and the code base itself.  I think it's a significant improvement over any of the previous code bases posted here, and I think it should be a good starting point for projects moving forward.

Overall, I'm extremely happy with the flexibility offered by the (essentially) pin and register compatible LPC11U24, LPC11U37 and LPC1347.  This trio leaves a lot of room to maneuver optimizing for flash size, performance, price or package size with almost no extra SW development effort.  Making a code base that makes that as painless as possible took a bit of effort, but at least it's a one time expenditure.

I don't want to post many details until the code base is ready to go live, but I think it's all come together pretty well so far, and I hope it will be a decent starting point for a lot of people.  It'll definitely make things easier here to get prototypes off the ground in days or weeks rather than weeks or months.

Full story  | Comments (7)

LPC1347/LPC11U37 Board and CodeBase Update

Thursday, September 13, 2012

I was surprised by the interest in the RF board I posted about earlier, so I figured I'd post a small update on the progress. I've been dividing my time between the 1347 and 11U37, trying to spend equal amounts of time with both to make sure that the codebase easily works with either chip out of the box.

Initial Opinions

While the migration from the 1114 and 1343 has been generally pretty smooth, I did have to pull out the UM to understand the new (and more flexible) GPIO blocks, the 12-bit ADC (1347 only), get the EEPROM working, etc., but nothing too dramatic so far. SSP, I2C, etc., are the same as always since they're basically just licensed IP blocks from ARM.

Overall, I'm exceptionally happy with both chips and the 1347 is everything I wish the 1343 would have been ... though I'd be happier if the distributor pricing was a bit lower.

There were some hiccups creating a common LPC11U37 + LPC1347 codebase because of a few regrettable naming differences in the CMSIS libraries from NXP. The UART IRQ handler is defined as "USART_IRQHandler" for the 1347, for example, but "UART_IRQHandler" for the 11U37, so to have a single codebase for either chip I end up with horribly ugly cludges like this:

#if defined CFG_MCU_LPC11U37FBD48_401
void UART_IRQHandler(void)
#elif defined CFG_MCU_LPC1347FBD48
void USART_IRQHandler(void)
#else
  #error "uart.c: No MCU defined"
#endif
{
  ...
}

Similar situation for "FLEX_INT0_IRQHandler" (11U37) versus "PIN_INT0_IRQHandler" (LPC1347), and in a number of other places, but these are relatively easy to locate and fix. The worst so far was with GPIO, though, where some of the register names in the core header file were different, as seen below (used to set up a GPIO interrupt):

        case CHANNEL1:
          if ( portNum )
          {
            #if defined CFG_MCU_LPC11U37FBD48_401
                LPC_SYSCON->PINTSEL[1] = bitPosi + 24;
            #elif defined CFG_MCU_LPC1347FBD48
                LPC_SYSCON->PINSEL[1] = bitPosi + 24;
            #endif
          }
          else
          {
            #if defined CFG_MCU_LPC11U37FBD48_401
                LPC_SYSCON->PINTSEL[1] = bitPosi;
            #elif defined CFG_MCU_LPC1347FBD48
                LPC_SYSCON->PINSEL[1] = bitPosi;
            #endif
          }
          #if defined CFG_MCU_LPC11U37FBD48_401
            NVIC_EnableIRQ(FLEX_INT1_IRQn);
          #elif defined CFG_MCU_LPC1347FBD48
            NVIC_EnableIRQ(PIN_INT1_IRQn);
          #endif
        break;

LPC_SYSCON->PINTSEL (LPC11U37) is probably the better name because it better represents what this register is doing (GPIO Pin Interrupt Select), but curiously the LPC1347 user manual also lists this value as PINTSEL (not PINSEL), so it's likely just an unfortunate typo that people are stuck with now since they can't really change it. It's also a rather misleading name if you've ever done any ARM7 development with the older LPC2000 series since 'PINSEL' performed a very different and common function. But hey ... such is life, and at least they give you something to start with these days, and mistakes happen. It just struck me as unfortunate that for chips that are almost identical on a peripheral level, and that can be dropped in with 99% SW and HW compatability that the major obstacle would be something as trivial as inconsistent naming across families.

Low Power

The power numbers were higher in the sleep modes than I expected, and I'm still working on this and certain it's my fault. I trust the numbers in the datasheet, and I'm pretty confident in my HW after two revisions for power, but I just need to find the secret sauce in the firmware. This also took quite a while with the 1114. I'm currently at 30µA in power down running at 2.2V which is identical to what I got on some similar LPC1114 wireless boards ... but I should be able to go much lower than that (ideally under 10µA total). There were a lot of gotchas trying to isolate those microamps, though, including on less than obvious one.

The 1347 and 11U37 families now include a (welcome) QFP64 package option with more IO pins (great for large LCDs, etc.). Inside, though, all of these chips almost certainly use the same die, and they just selectively bond out the required pins for the package -- QFN33, QFP48, QFP64, etc. The 'gotcha' was that on a QFN33 or QFN48 package, those extra GPIO pins still exist on the die, and if you go into a low power/sleep mode without taking them into consideration you'll be drawing several hundred µA more than you should be due to the pullups and default pin state. You need to explicitly setup the unbonded pins to output and GND as well, and put the pullups in an appropriate state AND be sure to disable the analog mode on unbonded pins with an ADC option. I didn't think of that at first, but it got me from 400µA to around 30µA, using code similar to the following (I explicitly set every pin on startup now):

I caught that thanks to Embedded Artist's excellent Oryx board (thanks for the inadvertent heads-up Anders!).

CodeBase Improvements

Since I'm starting a new code base I took the opportunity to try to improve on previous efforts, and I think the current version has a better organisation, and I've improved some things I really didn't like in the previous 1343 and 1114 libraries.

  1. I've improved the CLI a bit (better organisation, etc.)
  2. I added a very preliminary mechanism to localise/translate text so that you can support multiple languages in one application (though this really needs more attention and testing), which is a must outside the US but not something I see done a lot in open source embedded projects
  3. I've start working on a global error handling mechanism, though at the moment it's just shared error codes and better error handling and checking in I2C
  4. I also added a board-specific init sequence and file in addition to the shared systemInit() function so that board specific code can be better seperated, though this still needs some thought.

 

Overall, I'm happier with this that the 1343 code base, but it still needs some thought and effort and isn't ready for the real world yet. The biggest change is that I've decided not to swim against the current and just use CMSIS from the start. When I start with the 1343 and 1114 codebase CMSIS was brand new, and nothing existed for these chips anyway, so I just did what I always did and pulled out the UM and started making my own flat header file. I still prefer this approach, but I just don't have the time to dedicate to doing this well these days -- there are weeks and weeks of effort in that approach -- so I'm using the default NXP peripheral drivers and CMSIS 3 code, making changes where appropriate so that the code works with both the 11U37 and 1347 just changing a single define in projectconfig.h. This isn't an ideal solution for me, and I may go back and rewrite all those peripheral drivers myself ... but for now this lets me get started quickly and developping the HW, etc.

When Will it be Available?

Not sure, and no promises. I don't want to publish it before it's in reasonably good shape and I'm happy with the basic organisation, and since this is just an unpaid weekend project I can't work on it much during the week ... but hopefully in a month or so I'll publish an initial version along with the HW files for a first wireless board and maybe put together a simple MCU-only board for people no interested in RF but who want to use the codebase.

The ToDo list is still pretty big. I haven't touched USB yet, the antenna on the current boards desperately needs to be properly measured and either revised or tuned, and I have to add in ADC support and a few key peripherals I haven't gotten to yet like the timers. I think the worst is done, though, and things are coming together nicely ... just never enough hours in the week to really wrap it up.

I'll definitely be moving to the 1347 and 11U37 combination in the future, though, and they're great little chips that should be much more flexible than the earlier 1343 and 1114. I'll probably move away from the 1343 entirely, but will maintain the 1114 code since it's still ridiculously cheap, there's a DIP version of it, and the new 1115 with 64KB flash breathes some extra life into it.

Full story  | Comments (2)

LPC11U24/LPC11U37/LPC1347 RF Board

Wednesday, July 25, 2012

I've been looking for an excuse to do something with the LPC1347 for a while, and I ended up recycling a lot of previous work, combining a number of lessons learned into a single four-layer board that should let me test a number of power supply and project scenarios.  I kept the board fairly basic, just a microSD card for datalogging, USB, and SWD connector, and reset/ISP buttons.  There's on on-board user-selectable 3.3V/2.2V linear regulator (TPS780), but it can be bypassed and you can power the board from another source for flexible power input and current control.  It's designed to fit in these inexpensive weather-proof cases with a transparent top for a small solar cell, but should be easy to adapt to another enclosure.

I kept the RF section completely seperate as well so that I can change to another chip if required.  The current board uses an AT86RF212 (868/915MHz 802.15.4), and I can drop in an AT86RF230/231 (2.4GHz) with a simple adjustment to the transmission line width for impedance matching ... but I also whipped up a schematic for the nRF8001 for Bluetooth LE that I might test down the road.  The way the board is now I can make seperate 2-layer add-on PCBs for various power and sensor inputs, sticking to one common footprint and header to evaluate things more quickly.

One benefit of the ARM Cortex M3 based LPC1347 is that it's pin compatible with the Cortex M0 LPC11U24 and Cortex M0 LPC11U37.  This gives me a decent selection of options between price/performance/flash size on a single PCB, with minimal SW changes, all of which have excellent power numbers:

  1. the LPC11U24 is dirt-cheap - 50MHz M0, 32kB flash, 8kB SRAM
  2. the LPC11U37 has lots of flash for complex stacks - 50MHz M0, 128kB Flash, 8+2+2kB SRAM
  3. the LPC1347 is a high-performance chip with a decent amount of flash - 72MHz M3, 64kB Flash, 8+2+2kB SRAM and 12-bit ADC

It's just a personal, weekend project, but I'll blog some more about this board when I get the PCBs in later this week since it was a big (if expensive) learning experience.  Here's some photos of the PCB being manufactured, though, if you've never seen the different steps of the process (courtesy PCB Pool):











Full story  | Comments (17)

  1. 1
  2. 2
  3. Next page