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.