OK, first problem: the feet supplied with the LPC-P1343 have fingers (toes?) that are too big to fit into the holes on the board. I gave the feet a pedicure using the dikes from my electronics bench. The toes are now tapered to fit into the holes on the board.
The mechanism for programming this thing is extremely elegant. An on-board jumper selects between ‘run’ mode and ‘program’ mode. Set the jumper, press the reset switch (the tiny black one near the 8 LEDs), and the board enters the mode as selected by the jumper (jumper ON = program mode, jumper OFF = run mode). When in program mode, the board looks like a FAT disk to the host, holding a whopping 32KB! (which is the size of the flash memory on the ARM) You delete the firmware file on the ‘disk’, copy your firmware to that ‘disk’, change the jumper, and press reset. In ‘run’ mode, it executes the firmware that you copied over.
When I first plugged it in, the default firmware was running (cycling the LEDs), but it didn’t show up on the host. I RTFM and learned about the jumper and the reset switch. I put the jumper on and pressed the reset button, but it still didn’t show up on the host. This threw me a bit at first, but then I wiggled the USB cable where it plugged into the board, and voila! The host detected a new flash disk. Looking at the new flash disk with Explorer, I saw a single file: “Firmware.bin” Just to be on the safe side, I made a copy of the firmware file on my host.
On the Olimex web page for the LPC-P1343 is a link to a ZIP file containing some firmware examples. These examples are very unsophisticated (except for the last), but they provide a starting point.
- Blinking LED (polling): Blink LED0 with a frequency of 1Hz, which is settable in software
- Blinking LED (interrupt): Blink LED0 with a frequency of 4Hz, where the time interval is set via the CT32b0 capture/compare interrupt
- Running light: Turn on the LEDs in sequence
- Running light & buttons: Control the running
light speed. Button 1 decreases the frequency, while button 2 increases the
frequency. Button presses are detected via a port external interrupt.
- Running light & button scan: Same as above, but the button scanning is triggered by the CT16b0 interrupt
- Virtual COM port: Makes the board appear to be USB Communication Device Class (serial port)
The examples have been built with the IAR Embedded Workbench in mind. There is a 30-day evaluation edition, but I’ve found a port of GCC for ARM to Windows. More on that tomorrow.
I need a USB device I can use as a target in my Windows USB device driver course. The device needs to be reasonably powerful, and allow me to control how the device appears on the bus via firmware. I’ve used the Arduino in the past, but that thing is really horrible:
- Slow 8-bit microcontroller
- Daughter cards that plug into the Arduino, what they call “shields”, use a retarded header pin spacing, which makes it extremely difficult to create a daughter card using standard perf board. They have steadfastly refused to change the spacing in the name of backward compatibility, no matter how much it hurts everyone now.
- The older versions used the FTDI USB-Serial chip, which made the board look like a serial port. That may be fine for the most basic tinkerers, but making it look like a serial port throws away most of the usefulness of the USB. Last year, I created a shield that has a USB connector on it and implements the USB protocol in software on the Arduino’s AVR microcontroller. This worked, but only barely. The CPU just didn’t have the horsepower (16MHz clock) to run the bus at anything above 1.5MHz, which meant it showed up as a low-speed device. This worked fine, except that it was useless for isochronous transfers, which are only supported at full-speed (12MHz) and above. The latest Arduino, the Uno, has finally replaced the FTDI chip with a dedicated AVR CPU (AT90USB) to run the USB. It defaults to serial, but you can write your own firmware to make it look like something else.
Here are the requirements for the target board I need for the USB driver class:
- Support all USB transfer types (bulk, control, isochronous)
- Fast 32-bit CPU
- Expandable with plug-in boards
- Cheap/free tool chain
- Cheap/free Ada compiler
- Board price of less than $30 for quantity 10
I decided that something based upon an ARM processor would be much more likely to be useful than the Atmel AVR. The ARM Cortex M3 is very cheap (about $6, down to $2 in large quantities), fast (72MHz), has lots of memory (32KB flash, 8KB SRAM), supports USB, has a boatload of I/O pins, and plenty of free software tools for writing firmware.
My plan was to design my own board, but events (4 month contract in Southeast Asia, back surgery) last year conspired against me. I will still design my own development board, but for now I need something cheap and quick. After looking around the web for a day, I found hundreds of ARM development boards, but most are too expensive to give away to my students. Then I found Olimex and their LPC-P1343. Olimex is a European company, and shipping to Hawaii would have been very expensive. A little more searching, and I found a U.S. distributor, MicroController Pros.
The nice thing about the LPC-P1343 is that it is part of a family, and Olimex has various peripherals that plug into the boards in that family. So, I found a few peripherals that I thought might come in handy, such as the LCD module, I/O board module, and a 10Mbit Ethernet module, placed the order on Friday, and they showed up today – except for the I/O board, which is backordered, and won’t be here until Thursday.
In the LPC-P1343 box is the board, and four feet, to keep the board from shorting out when it might be placed upon a conductive surface. This board is really tiny! It measures 8cm x 5cm. It does not come with a USB mini cable, although I could have ordered one; I have plenty of these laying around.
As you can see from the picture, it has an NXP (formerly Phillips) ARM LPC1343 CPU, a mini USB connector, two buttons, 8 LEDs, the peripheral connector (the larger one on the left), and a debug connector (smaller one on the right), and a solderable prototyping area (which I don’t plan on using at the moment).
I have wanted to start blogging about my various projects for several years, but I just never got around to it. Today, my good friend Eric Hanson asked me to document the creation of one of my projects that he will be using, so I figured that today was as good as any other to start blogging.
In the beginning this blog was void and without form, and darkness was upon the tinkerers, and Eric spake unto me, “thou shouldst blog thy creations so other tinkerers may follow in thy footsteps.” And thus, this blog was born.