Digital design for embedded DSP

Interfacing with a DAC and an ADC is not too exciting, but to make a complete device some other “small” features are necessary. The analyzer will need some serious DSP power to run reliably at 192 kHz and to calculate the long FFT needed for the spectrum analysis, and at the same time it would be nice to have sufficient connectivity for remote control of the system. It would be especially nice to be able to download the recorded and/or processed data, and to use the analyzer device as a high-quality but mono audio interface.

I’ve had good experience with the LPC series of microcontrollers, and the NXP LPC43xx was the obvious candidate for this purpose. It’s a dual-core design, with one ARM Cortex-M4F core with hardware 32-bit floating point support, and the other core is a Cortex-M0 that still runs at the same maximum clock frequency of 204 MHz. That’s a lot of MIPS/FLOPS to burn! The M4F could do the signal processing and interfacing with codecs, and the M0 core would take care of everything else.

I really like Ethernet and TCP/IP as an ubiquitous way to connect computers, and the LPC4333 has a built-in Ethernet MAC. It requires an external PHY (Ethernet line transceiver IC), and the PHYs seem to be only available in tiny QFN packages that take some skill to solder. Gotta learn that sometime, so why not now. The Microchip LAN8720A is again an obvious choice.

This application is going to need a lot of memory, much more than is available on the LPC MCU. The LPC4333 has a memory controller, and it should be easy to connect some SDRAM to it. The memory will be accessible by both cores, so the DSP core can write to it and the controller core can read the contents and send to the remote controller over Ethernet. Is the memory bus fast enough for that, and does the sharing between the two cores cause problems? We’ll have to see… The memory bus on this particular CPU is 16 bits wide, and a 192 kHz 32-bit audio stream will require about 1.5 MB/s of bandwidth to transfer to memory and back. Probably I will want to store more than that at the same time, but in any case the bandwidth of even just a 100 MHz (half the CPU clock frequency) 16-bit memory bus should be way more than sufficient. SDRAM requires some overhead for setting up the transfers and for refreshing the memory, but there should be so much extra headroom on the bus, that this should not be a problem at all.

The device should be capable of standalone operation (and I like having dedicated physical controls) so a frontpanel is a must. The 16 character, two row LCD display is a little bit small, but it’s easy to read and easy to program. After making some sketches of the data to be shown on the display it was clear that it could still work for this purpose. The most economical approach (in terms of saving design time) would be to use a dedicated MCU for the front panel controls, and drive the LCD directly from the main CPU.

USB and MIDI ports could be added too, the LPC is very flexible. But this application doesn’t really need those.

But look at the picture above! Even though the THD analyzer device is relying heavily on its DSP and analog performance, these parts appear as a very small part of the overall system. This seems to be a common theme in devices intended for hands-on use. Interfacing with external systems, and especially with humans, is quite expensive.