High bandwidth I/O on LPC2xxx

Started by Brendan Murphy November 18, 2006
There's been a few posts recently asking about high-bandwidth I/O on
the LPC2xxx parts (and I realise high is a relative term here).

For what it's worth, here are some hard figures (from memory, so
might not be 100% acurate!), based on a system we did a while back.

I can't say too much about the application as it's covered by NDA
(it was a type of sensor), but the characteristics of the core of
the implementation were as follows:

- LPC213x MCU
- One external 16-bit DAC, driven at 500k samples/sec
- Two external 16-bit ADCs, each driven at 100k samples/sec

The connection to the DAC and ADCs was through a bus structure,
built on the MCU's GPIO pins. The total bandwidth was 11.2 Mbits/sec
(i.e. an order of magnitude less than the recent requirements for
100s of Mbps).

Because of I/O port clashes (we required both UARTs too), we had
to "split" both the i/p and o/p. The software had to generate the
o/p signal (sine wave) and implement a lockin amplifier to detect
the phase difference between the two i/p signals. This involved a
reasonable amount of DSP, including a band-pass filter (implemented
as a 5-tap IIR) and a CORDIC algorithm for calculating arctans.

What we found:

- it worked really well: we could detect phase differences in the
10s of micro-degrees range (it varied, depending on the frequency
required for the o/p calculation)

- I/O was definitely a bottleneck (about half the time was spent
just doing I/O), but mostly because of the "slow" I/O

I can't say how using a newer part in the range (with fast I/O)
would have helped: it would probably have meant we could avoid using
assembler for the low-level driver (though that was maybe 100
instructions or less in total). As it was, the part even with its
slow I/O met our requirements: the fast processing capability more
than made up for the I/O throughput limits.

We were pushing the part quite hard though: hence my real doubt that
you could do anything useful if the bandwidth through the I/O had to
be an order of magnitude greater.

Hopefully, this will help others to get some idea of the likely
performance achievable using these parts in a real-world application.


An Engineer's Guide to the LPC2100 Series