Bread Boarding the LPC1114 DIP28

I’ve been getting some questions about how I work with the LPC1114 DIP28 chip which will be used in the RC controller.  My approach is a little different (and might even constitute a hack) and thought I would take the time to share the setup.  First of all I’ll mention I’ve decided to focus on using the LPC1114 over something more mainstream (such at the 8bit Atmega chips used by the Arduino family) for the raw performance of a 32 bit processor and ease of migrating to even more powerful processors in the future.

The LPC1114 DIP28 serves as a great hacker/maker chip for electronic projects.  It’s cheap and easy to work with on the breadboard.  What’s even better are the development boards which are available from Embedded Artists which include an SWD (JTAG-like with reduced pin count) debugger.  This debugger allows you to flash the part, single step through your code, and examine memory.  These boards start as low as $20.  I know they now offer a stand alone debugger (called something like LPCLINK2) – however if you buy one of the standard boards you get the debugger plus a target board for the same price.


In this tutorial we’ll run the PLL off the internal oscillator at 48Mhz.  It’s not as accurate as with the optional crystal, but for many applications this is good enough and save the crystal plus two additional caps.

In my case I’m starting with the LPC1769 board:


Figure 1 – LPCLINK and LPC1769 Target Card

The first thing to do is separate the LPC-LINK from the target card (saving the target card for a future project).  It is a little tricky to cut them as there is no scoring on the PCB between the two.  To cut them I used my Dremel tool with my favorite cut-off disk:


Figure 2 – Separating the LPCLINK from the target card

The actual cut preserves all of the holes on the LPCLINK side and cuts into the holds on the LPC1769 – it’s a sacrifice you have to make, but keeps the LPC1769 useable.  Save it for a later project.

For a cable to connect from the LPCLINK to a pin header which can be plugged into a breadboard I used a piece of leftover Ethernet cable.  The wiring of this goes as follows:

    • White/Green – 3.3V
    • Blue – SWDDATA
    • Green – SWDCLK
    • N/C
    • N/C
    • N/C
    • Black – GND

Figure 3 – Wiring up the LPCLINK

I found that it was easier to wire the the cable to the backside of the LPCLINK:


Figure 4 – Connecting the wires to the LPC-LINK

For the pin header connections are as follow:

    • Green – SWDCLK
    • N/C
    • N/C
    • N/C
    • Black – GND
    • White/Green – 3.3V
    • N/C
    • N/C
    • N/C
    • Blue – SWDDATA

Figure 5 – Connecting the wires to the pin header

Before you put the DIP into the breadboard it is good to press the rows of pins inwards just a little bit – as you’ll need to save one of the rows of pins to fit the breadboard:


Figure 6 – Close up of the DIP28

I got tired of constantly checking with the databook to see what the pin assignments were – so I made up these stickers to make it easier to remember:


Figure 7 – With the sticker I made up to easily identify the pins

Seat the chip so that you have three rows of pin above and below the chip:


Figure 8 – Mounting it on the breadboard

Here it is with the sticker attached:


Figure 9 – Mounted on the breadboard

The wiring begins with connecting VDD with the AREF and the analog and digital ground supplies:


Figure 10 – Connecting Power and Ground

Next add a decoupling cap and LED to pin 8:


Figure 11 – Adding a decoupling cap and LED

Finally seat the pin header and you’re ready to start programming.


Figure 12 – Connecting the SWD pin header – DONE!


I’ve spent quite a bit of time evaluating Code Red LPCExpresso IDE as well as the other toolchains for programming the LPC1114.  Regarding LPCExpresso – while it does offer an Eclipse based IDE with embedded debugger for programming with a debugging with the LPCLINK there were a few of reasons that it wasn’t my first choice.

  1. It doesn’t support C++ with the free version
  2. To used the optimized library you need to link in the closed source REDLIB (in place of newLib)
  3. I never really liked the overall Eclispse GUI – it was too complicated with too many features

Instead my toolchain / setup consists of  the gcc toolkit which is officially supported by ARM by Joey Ye and his team.  This can be downloaded here:

This toolchain contains “newlib-nano” which is nicely code optimized as we’ll see with our upcoming code example.  They also offer ticket based support and are quite responsive when if you run into trouble.

In addition there are some drivers withing  LPCEXPRESSO which are needed to supporting flashing the LPC1114 as well as the gdb debugger.  This can be downloaded here:

Install these two packages, but remember where you install the the two package as they will be referenced by the setup script:

#  Step 1:  Set path to GCC toolkit

#  Step 2:  Set path to Code Red Tools

#  Add path to GCC

#  Boot LPCLINK (Mac/Linux)
dfu-util -d 0x471:0xdf55 -c 0 -t 2048 -R -D $CRT/LPCXpressoWIN.enc

I got the file lpc1114.c from Wouter van Ooijen (  He has an excellent tutorial of what this is doing in terms of initializing local memory which can be found here  My blinky example is quite a bit different that his, but this initialization code (and explanation) in this tutorial is really excellent..

// LPC1114 startup
// Wouter van Ooijen -
// license: zlib

int main( void );
extern "C" { void __startup( void ); }
extern int __stack_end;    		

// nr 7 (offset 0x1C) is the vectors checksum
extern void (* const __vectors[ 40 ])(void) 
   __attribute__ ((section(".vectors"))) = {
      (void (*)(void)) & __stack_end,	
      0,          /* NMI Handler */
      0,          /* Hard Fault Handler */
      0,          /* Reserved */
      0,          /* Reserved */
      0,          /* Reserved */
      0,          /* Reserved */
      0,          /* Reserved */
      0,          /* Reserved */
      0,          /* Reserved */
      0,          /* SVCall Handler */
      0,          /* Reserved */
      0,          /* Reserved */
      0,          /* PendSV Handler */
      0,          /* SysTick Handler */
      0,          /* IRQ0 */
      0,          /* IRQ1 */
      0,          /* IRQ2 */
      0,          /* IRQ3 */
      0,          /* IRQ4 */
      0,          /* IRQ5 */
      0,          /* IRQ6 */
      0,          /* IRQ7 */
      0,          /* IRQ8 */
      0,          /* IRQ9 */
      0,          /* IRQ10 */
      0,          /* IRQ11 */
      0,          /* IRQ12 */
      0,          /* IRQ13 */
      0,          /* IRQ14 - SPI1    */
      0,          /* IRQ15 - I2C     */
      0,          /* IRQ16 - CT16B0  */
      0,          /* IRQ17 - CT16B1  */
      0,          /* IRQ18 - CT32B0  */
      0,          /* IRQ19 - CT32B1  */
      0,          /* IRQ20 - SPI0    */
      0           /* IRQ21 - UART    */


void __startup(void){
   extern int __data_init_start;
   extern int __data_start;
   extern int __data_end;
   extern int __bss_start;
   extern int __bss_end;
   extern int __init_array_start;
   extern int __init_array_end;
	 int *s, *d, *e;

	 // clear .bss section 
	 d = & __bss_start;
	 e = & __bss_end;
	 while( d != e ){
	    *d++ = 0;
	 // copy .data section from flash to ram
	 s = & __data_init_start;
	 d = & __data_start;
	 e = & __data_end;
	 while( d != e ){ 
	    *d++ = *s++;
	 // call the constructorts of global objects
	 s = & __init_array_start;
	 e = & __init_array_end;
	 while( s != e ){
   // call main   
   (void) main(); 
   // when main returns: loop till hell freezes down

// called when a pure virtual method is called
extern "C" void __cxa_pure_virtual( void ){

The actual C code which is written to blink the LED is simplified in a way which doesn’t use any of the CORETEX libraries.  In this can you can take the value from the data book and simply plug it into the code:

#define  MMIO(addr) (*(volatile int*)addr)

//  SYSCON Registers
#define SYSAHBCLKCTRL  MMIO(0x40048080)

//  GPIO Registers
#define GPIO0DIR       MMIO(0x50008000)
#define GPIO0DATA      MMIO(0x50003FFC)

#define IOCON_PIO0_8   MMIO(0x40044060)

int main()
  int i;

  //  Enable clocks on advanced high-performance bus
  //  SYSCLK on IRC - for simplicity

  //  Configure PIO0_8 as General Purpose IO
  IOCON_PIO0_8 = 0x00;

  //  Configure PIO0_8 as output
  GPIO0DIR= 0x100;

  while(1) {
    GPIO0DATA = GPIO0DATA | 0x100;      // Turn on
    for(i=0;i<1000000;i++) asm("NOP");  // Pause
    GPIO0DATA = GPIO0DATA & ~(0x100);   // Turn on
    for(i=0;i<1000000;i++) asm("NOP");  // Pause

Finally to pull this all together in a way that really made sense to me I needed to get Freddie Chopin’s Makefile (although I added the debug and debugtui steps to interface with the LPCLINK):

# ARM makefile
# author: Freddie Chopin,
# last change: 2010-10-13
# this makefile is based strongly on many examples found in the network

# toolchain configuration

TOOLCHAIN = arm-none-eabi-
CRTEMU =  crt_emu_lpc11_13_nxp

AS = $(TOOLCHAIN)gcc -x assembler-with-cpp
RM = rm -f

# project configuration

# project name
PROJECT = project

# core type
CORE = cortex-m0

# linker script
LD_SCRIPT = lpc1114.ld

# output folder (absolute or relative path, leave empty for in-tree compilation)
OUT_DIR = out

# C++ definitions (e.g. "-Dsymbol_with_value=0xDEAD -Dsymbol_without_value")

# C definitions

# ASM definitions

# include directories (absolute or relative paths to additional folders with
# headers, current folder is always included)

# library directories (absolute or relative paths to additional folders with
# libraries)

# libraries (additional libraries for linking, e.g. "-lm -lsome_name" to link
# math library libm.a and libsome_name.a)
LIBS = -lc -lc -lnosys

# additional directories with source files (absolute or relative paths to
# folders with source files, current folder is always included)

# extension of C++ files
CXX_EXT = cpp

# wildcard for C++ source files (all files with CXX_EXT extension found in
# current folder and SRCS_DIRS folders will be compiled and linked)
CXX_SRCS = $(wildcard $(patsubst %, %/*.$(CXX_EXT), . $(SRCS_DIRS)))

# extension of C files
C_EXT = c

# wildcard for C source files (all files with C_EXT extension found in current
# folder and SRCS_DIRS folders will be compiled and linked)
C_SRCS = $(wildcard $(patsubst %, %/*.$(C_EXT), . $(SRCS_DIRS)))

# extension of ASM files

# wildcard for ASM source files (all files with AS_EXT extension found in
# current folder and SRCS_DIRS folders will be compiled and linked)
AS_SRCS = $(wildcard $(patsubst %, %/*.$(AS_EXT), . $(SRCS_DIRS)))

# optimization flags ("-O0" - no optimization, "-O1" - optimize, "-O2" -
# optimize even more, "-Os" - optimize for size or "-O3" - optimize yet more) 

# warning options 
CXX_WARNINGS = # -Wall -Wextra
C_WARNINGS = # -Wall -Wstrict-prototypes -Wextra

# C++ language standard ("c++98", "gnu++98" - default, "c++0x", "gnu++0x")
CXX_STD = gnu++98

# C language standard ("c89" / "iso9899:1990", "iso9899:199409",
# "c99" / "iso9899:1999", "gnu89" - default, "gnu99")
C_STD = gnu89

# set the VPATH according to SRCS_DIRS


# when using output folder, append trailing slash to its name

ifeq ($(strip $(OUT_DIR)), )
    OUT_DIR_F =
	OUT_DIR_F = $(strip $(OUT_DIR))/

# various compilation flags

# core flags
CORE_FLAGS = -mcpu=$(CORE) -mthumb

# listing flags
LISTING_FLAGS = -Wa,-ahlms=$(OUT_DIR_F)$(notdir $(<:.c=.lst))

# flags for C++ compiler
CXX_FLAGS = --specs=nano.specs -std=$(CXX_STD) -g -ggdb3 -fno-rtti -fno-exceptions -fverbose-asm $(LISTING_FLAGS)

# flags for C compiler
C_FLAGS = --specs=nano.specs -std=$(C_STD) -g -ggdb3 -fverbose-asm -Wa,-ahlms=$(OUT_DIR_F)$(notdir $(<:.$(C_EXT)=.lst))

# flags for assembler
AS_FLAGS = -g -ggdb3 -Wa,-amhls=$(OUT_DIR_F)$(notdir $(<:.$(AS_EXT)=.lst))

# flags for linker
LD_FLAGS = -T$(LD_SCRIPT) -O -g -Wl,-Map=$(OUT_DIR_F)$(PROJECT).map,--cref,--no-warn-mismatch

# remove unused code and data
LD_FLAGS += -Wl,--gc-sections
OPTIMIZATION += -ffunction-sections -fdata-sections

# do not use the standard startup

# do some formatting

CXX_OBJS = $(addprefix $(OUT_DIR_F), $(notdir $(CXX_SRCS:.$(CXX_EXT)=.o)))
C_OBJS = $(addprefix $(OUT_DIR_F), $(notdir $(C_SRCS:.$(C_EXT)=.o)))
AS_OBJS = $(addprefix $(OUT_DIR_F), $(notdir $(AS_SRCS:.$(AS_EXT)=.o)))
DEPS = $(OBJS:.o=.d)
INC_DIRS_F = -I. $(patsubst %, -I%, $(INC_DIRS))
LIB_DIRS_F = $(patsubst %, -L%, $(LIB_DIRS))


# format final flags for tools, request dependancies for C++, C and asm

#contents of output directory
GENERATED = $(wildcard $(patsubst %, $(OUT_DIR_F)*.%, bin d dmp elf hex lss lst map o))

# make all

all : make_output_dir $(ELF) $(LSS) $(DMP) $(HEX) $(BIN) print_size 

# make object files dependent on Makefile
$(OBJS) : Makefile
# make .elf file dependent on linker script

# linking - objects -> elf

$(ELF) : $(OBJS)
	@echo 'Linking target: $(ELF)'
	$(CXX) $(LD_FLAGS_F) $(OBJS) $(LIBS) -o $@
	@echo ' '

# compiling - C++ source -> objects

$(OUT_DIR_F)%.o : %.$(CXX_EXT)
	@echo 'Compiling file: $<'
	$(CXX) -c $(CXX_FLAGS_F) $< -o $@
	@echo ' '

# compiling - C source -> objects

$(OUT_DIR_F)%.o : %.$(C_EXT)
	@echo 'Compiling file: $<'
	$(CXX) -c $(CXX_FLAGS_F) $< -o $@
	@echo ' '

# assembling - ASM source -> objects

$(OUT_DIR_F)%.o : %.$(AS_EXT)
	@echo 'Assembling file: $<'
	$(AS) -c $(AS_FLAGS_F) $< -o $@
	@echo ' '

# memory images - elf -> hex, elf -> bin

$(HEX) : $(ELF)
	@echo 'Creating IHEX image: $(HEX)'
	$(OBJCOPY) -O ihex $< $@
	@echo ' '

$(BIN) : $(ELF)
	@echo 'Creating binary image: $(BIN)'
	$(OBJCOPY) -O binary $< $@
	@echo ' '

# memory dump - elf -> dmp

$(DMP) : $(ELF)
	@echo 'Creating memory dump: $(DMP)'
	$(OBJDUMP) -x --syms $< > $@
	@echo ' '

# extended listing - elf -> lss

$(LSS) : $(ELF)
	@echo 'Creating extended listing: $(LSS)'
	$(OBJDUMP) -S $< > $@
	@echo ' '

# print the size of the objects 

print_size :
	@echo 'Size of modules:'
	$(SIZE) -B -t --common $(OBJS) $(USER_OBJS)
	@echo ' '

# run

run : all 
	$(CRTEMU) -2 -pLPC1114FN/102 -wire=winusb -flash-load-exec=$(ELF) -load-base=0x0000

debug: $(ELF)
	arm-none-eabi-gdb -x gdb_commands $(ELF)

debugtui: $(ELF)
	arm-none-eabi-gdbtui -x gdb_commands $(ELF)

# create the desired output directory

make_output_dir :
	$(shell mkdir $(OUT_DIR_F) 2>/dev/null)

# make clean

ifeq ($(strip $(OUT_DIR_F)), )
	@echo 'Removing all generated output files'
	@echo 'Removing all generated output files from output directory: $(OUT_DIR_F)'
ifneq ($(strip $(GENERATED)), )
	@echo 'Nothing to remove...'

# global exports

.PHONY: all clean dependents


# include dependancy files
-include $(DEPS)

Compiling and Running

Compiling the code is a breeze under Mac OSX, Linux, or mingw:


 The code compiles to just 346 bytes!


Running “make debug”


This gets you into an interactive gdb session with the code we just wrote.  I’m not going to go into the details of gdb here, but it is a powerful command line debugger.

Well there you have it 32bit ARM development with a SWD debugger for about $25..  I hope this tutorial helped.  You can find all the source code at (check the newstyle branch):

Comments please.


Posted in Uncategorized | 8 Comments

Radio Controlled Microcontroller System

With fall rapidly approaching it’s time to starting thinking about winter projects.  Over the past year I have been working offline with an ARM microcontroller with the intention that it would be used for my RC/FPV ambitions when I was ready.  There was a lot of learning to be done with this before I could share/teach was I was learning, but now I think I’m ready.

I’ve been hesitant to share this with my readers as previous posts which were overly technical didn’t seem to resonate with my audience as the more general posts on RC planes and FPV.  It worried me that if I simply shift gears too suddenly it might be the same as staring a new blog from scratch.

The reality here is I’m not flying as much as I was and am not creating the content as I did when I started.  There are a lot more RC websites out there now – covering many of the same topics.  I also don’t want this to be a site which is covering the same topics as many other RC websites – it needs to be a source of content which is interesting an unique.

At this point I’ve decided to go full force in this direction and while we may lose some readers I believe we’ll more than make up for this with a new audience.  So strap in and enjoy the ride.  ;-)

The first project I’ll be exploring is a Radio Controlled Microcontroller System.  This isn’t intended to be a clone of any of the very good controllers out there now – but a starting point for new projects and experiments.  It is also a way to explore modern hobby electronics in a way that might motivate people to try one of these experiments themselves.


There are many potential uses for this system as I will be exploring with my RC cars and RC/FPV planes (and will be interested in hearing about other ideas from my readers).

I’ve sent my first design out for PCB manufacturing:

Google ChromeScreenSnapz002

It includes:

  • NXP’s LPC1114 DIP28
  • A bluetooth interface to a PC or mobile device
  • An MPU6050 gyro/accelerometer
  • 4x Servo inputs from a RC receiver
  • 4x Servo outputs to ESCs or servos
  • A SWD in-circuit system programming interface for flashing and controlling the chip
  • An LED to monitor operation

With this setup I’m initially looking to:

  • Port my tricopter Arduino code over to the more powerful ARM processor
  • Monitor my RC car’s performance for weekly racing
  • Stabilize the Bixler’s flight

There is a lot to cover here and I’m excited to start this new thread.  Looking forward to your comments!



Posted in Microcontrollers | 4 Comments

Are you kidding me????

Obviously not my video  – what an idiot!

Posted in Uncategorized | Leave a comment

The Day I Lost the Bixler…

Hi Everybody!

Thought I’d post an update on my latest FPV adventures.  Well the spring started off with a bang – literally.  I had received my Remzibi OSD and had first put it on the Bixler.  The Remzibi is really great value for the money (~$66 on Aliexpress) and I’ll post a review of it later.

Unfortunately there was a lot of learning to be had with the FPV with OSD and the key problem I had was using the GoPro as the camera and was flying within an hour of sunset.  I got a view of the sun and lost orientation.  Switching from FPV to visual I tried to locate it in the sky, but couldn’t find it. I went back to FPV and tried to use the home indicator on the OSD, but this was spinning into the ground at that point.

Without a clue of where it`was the video signal was lost.  I moved all the sticks, but couldn’t hear any servo sounds… UGH!

I got in my car and drove around – finally I found a spot where there was a slight video signal.  So I walked around in the general direction that seemed to make the signal stronger…

Eventually I found it..  Smashed to bits !

I must of gone nose first straight into the asphalt.  Destroyed the plane and GoPro…  Oh boy…

Anyways – time to rebuild…


Posted in Uncategorized | 6 Comments

Tricopter FPV with Remzibi OSD and 600TVL Sony Super HAD CCD D-WDR

Tricopter FPV with Remzibi OSD and 600TVL Sony Super HAD CCD D-WDR

Comments please….

Posted in Uncategorized | Leave a comment

Bixler World Locator…

Check out this link Tyler made to illustrate where the Bixlers are in the world:

Thread at RCG is here –

Google Map Link is here –

Posted in Bixler, FPV, RC Flying | Leave a comment

Another favorite….

Another favorite of mine…

Posted in Uncategorized | 1 Comment

Spektrum DX6i Box Opening

Hey Everybody…  Got a new radio recently and wanted to share it with you…  After a lot of research and debating I settled on a Spektrum DX6i from Amazon for $139:

Ok – so why would an FPVer decide to choose this radio over one of the other more mainstream “FPV” radios.  Well here’s my list of must haves for the new radio:

  1. A radio that could easily support a buddy box system with my existing DX5E
  2. Multi-model support to run my Tricopter, Bixler, and the Zephyr build which I am working on
  3. Full capabilities of throttle curves, expos, dual rates, reversing and the like
  4. Compatibilities with my other 2.4Ghz receivers (Spektrum and OrangeRX)
  5. Upwards compatibility with LRS systems from Dragon Link and EZUHF

It really came down to a decision of the Turnigy 9 channel radios systems and the DX6i.  With the Turnigy I would have opted for the FrSky system (which doesn’t seem to be compatible with Spektrum/OrangeRX without another transmitter module).  Also, which there is a path to use the Turnigy TX with the DX5E later – it isn’t obvious and requires a new cable to be created.

Either system could be used with an eventual LRS system, and as I grow into that need I can use the DX6i as is and even with a 2.4G booster in the future should I want to extend the range.

Let’s continue with the box opening:

Comes nicely packaged with a high quality instruction manual plus the rechargeable batteries as seen above.

The fit and finish of the DX6i is really good and even better than what I had with the DX5E.  The LCD display menu system is adequate, but can be time consuming when you are entering the text for the name of a model.

Another view showing the manual and the batteries.

Close up showing all the knobs and switches.  The learning curve isn’t too bad from the DX5E.  The binding sequence is very similar and so are the rest of the “basics” like trims.

Here you can see more detail of the design.  The “Trottle Cut” seen here can also be used to start and stop a flight timing if you choose to.  You can also see the dual rate switches for the elevators and ailerons.

Here we’ve got the rechargeable batteries (which I am sure will make the radio pay for itself this seasons!

Flying with the DX6i is really great.  For the Bixler I’m having fun using the expos on it  to really dial in some smooth flying characteristics.  It can really alter the complete flight characteristics of the plane.

Using it on the Tricopter has been great too.  I especially like using the expos as well as having the model selected as a “helicopter type” which allows you to draw very nice throttle curves to allow very precise vertical control of the model.  On the DX5E it was one click for up and the one for down.  This is a dream to fly now!

Ok – that’s it for now.  I’ve got some projects in the works which I’ll be sharing in the next week or so..

Comments welcome!


Posted in RC Flying, Uncategorized | 12 Comments