To follow along up to this point, you had to have either a properly pre-programmed LPC810, or you must have programmed the µC yourself – perhaps using the setup described in a recent Getting Started article.

The reason for this is that we needed some specific I/O pins and this would interfere with the FTDI connections needed for uploading.

One solution is to swap chips around whenever you have to re-program them. It’s no big deal, but even with two chips it does get a bit tedious during rapid debugging cycles.

Fortunately, we have the venerable diode to help us out, three times in fact:

A diode only conducts current in one direction. This turns out to be very useful here. By connecting three of the four FTDI signals via a diode, we can implement a “logical AND” function on those pins: when the FTDI pin is high, the pin is freely available, and when it is low, it takes over and forces the pin low as well.

There are still some limitations in this setup, but the main benefit we get is that we can now leave the FTDI interface connected and re-use the pins for our own project after uploading.

This is a big deal. No more messing with chips. Just edit, save, compile, upload, run. Boom.

The mechanism is called “ISP”, i.e. In-System Programming. It’s common practice for chips with lots of pins and a few to spare for such a task. But it’s rare – and we’re really lucky – that we can do it with the 8-pin LPC810 (or more likely: good engineering by NXP).

Simple and small

We’ve come to the end of the “Garage Parking Aid” project. At least for now – there’s always a way to refine things, and you’re welcome to take this project way further of course. Be sure to check GitHub for the latest code changes and new additions – and feel free to fork and submit pull requests. This is what open source is all about.

As you can see, that 8-DIP LPC810 µC chip is quite an interesting little chap. We’ve only scratched the surface of the hardware functionality, but simple tasks really only take a few lines of code. The 32-bit ARM architecture is extremely effective, and it’s all C and C++.

It is also amazing to see what can be done with just 4 KB flash and 1 KB RAM.

Here is a snapshot of some projects from the jcw/embello code repository:

$ arm-none-eabi-size */*/firmware.elf
   text    data     bss     dec     hex filename
    416       0       0     416     1a0 1446-lpc810/fader/firmware.elf
    396       0       0     396     18c 1446-lpc810/minimal/firmware.elf
    400       0       0     400     190 1446-lpc810/relax/firmware.elf
    936       0       8     944     3b0 1446-lpc810/sine/firmware.elf
    456       0       0     456     1c8 1446-lpc810/toggle/firmware.elf
   1896       0       4    1900     76c 1450-dips/clock/firmware.elf
    628       0       0     628     274 1450-dips/leds/firmware.elf
    652       0       0     652     28c 1450-dips/motion/firmware.elf
   1700       0     804    2504     9c8 1450-dips/primes/firmware.elf
   1464       0       4    1468     5bc 1450-dips/serial/firmware.elf

Here are some build sizes for the GPA project:

   1436       0       4    1440     5a0 gpa/1-blink/firmware.elf
   1592       0       4    1596     63c gpa/2-analog/firmware.elf
    544       0       0     544     220 gpa/3-distance/firmware.elf
   1748       0       4    1752     6d8 gpa/4-power/firmware.elf
   1868       0       4    1872     750 gpa/5-idle/firmware.elf
   1984       0       4    1988     7c4 gpa/6-sleep/firmware.elf
   2072       0       4    2076     81c gpa/7-complete/firmware.elf

A first thing to point out is that all strings reside in flash, not in flash and RAM, as on the ATmega’s & ATtiny’s. These simple examples only use a few bytes of RAM (plus a stack).

The next interesting tidbit is that a very simple blinking-LED type example requires less than 0.5 KB of flash, and that serial output with printf support only adds an extra 1 KB.

In other words: there’s ≈ 2.5 KB of space to implement your own ideas – and you’re likely to be surprised by how much will fit in there. That’s a mighty 32-bit engine under the hood!

Of course there are limits. But with a low-cost chip such as the LPC810 it would be feasible to delegate different tasks across multiple chips. With each one performing a – separate – simple task. Each LPC810 has two serial interfaces, an I2C interface, and an SPI interface.

You could connect a bunch of LPC810’s via a 2-wire I2C bus and create a “cluster”. Add two more wires for +3.3V and ground, and you’d have a network of “bus-powered” nodes. Each node will have 4 I/O pins freely available. Two dozen nodes for the price of a Raspberry Pi.

The barriers to some pretty sophisticated computing domains have just been shattered.

And we’re only scratching the surface: technology is not the limiting factor… we are.

[Back to article index]