LPC4337 DSP application design

[lpcware]

Content originally posted in LPCWare by avr458 on Wed Aug 14 13:33:22 MST 2013
I've been off the radar from the forums for a while. I did get my LPC4337 board working and programming fine, the reset button was wired incorrectly. After taking a break from that design I'm back at it with the next iteration. My original device was a module for a distributive computing platform for complex control systems, it was a senior design project for my engineering degree, although the design was for school I used my influence to design the project such that my original device was a prototype/alpha version of the device I truly wanted to make.

Moving forward, I am looking to create a cost effective platform for audio processing. I want a device that works like a DSP and a microcontroller simultaneously or either of the two options independently. I chose the LPC43xx family of processors because I knew early on they should be capable of this. What I want to know is how well does the CMSIS DSP library performs in the context of real time audio processing. Does anyone here know about it? My next question pertains to the use of external memory, in order to sample and hole 24 bit 48kz audio for realtime processing a fair amount of space would be required, what would be the best way to interface memory SPIFI or EBI ?

[lpcware]

Content originally posted in LPCWare by usb10185 on Mon Aug 26 13:19:03 MST 2013
Hi,

Code execution and data storage are possible with the SPIFI interface. SPIFI is used for interfacing to Q-SPI Flash devices.
SPIFI is probably not what you want to use for the audio samples.
You probably need a volatile memory for that - internal SRAM or external SRAM/SDRAM connected to the EMC.

Ken

[lpcware]

Content originally posted in LPCWare by mark03 on Mon Aug 26 13:08:23 MST 2013
Also, wikipedia is your friend...

[lpcware]

Content originally posted in LPCWare by mark03 on Mon Aug 26 13:06:09 MST 2013
Re: memory, whether you need the external RAM really depends what you want to do.  Lots of signal processing, e.g. digital filters, can probably be done no problem with the internal RAM.  The bit width and number of channels are really second-order factors here.  What you should be thinking about is the timespan in the signal over which you will be doing signal-processing math---the length of the "processing kernel" so to speak.  E.g. will you be using FFTs?  What size?  Filters?  How many taps?  and so on.

Sorry, but I don't have the spare cycles to look at the WM8778.  I2S at its core is a very simple protocol, so if you read/compare the datasheets closely enough you should be able to figure out which signals correspond to which others.  If the NXP or WM docs are confusing, you can use other datasheets for reference, e.g. the TI TLV320AIC3xxx series codecs.  Keep in mind that the codecs have pretty flexible options for where they get their clocks, so not all the pins will necessarily be needed.  Start by identifying the data lines, one in and one out.  (Stereo is interleaved.)

[lpcware]

Content originally posted in LPCWare by avr458 on Thu Aug 22 22:50:40 MST 2013

---

Quote: mark03
The LPC43xx should have the power to handle a wide range of audio DSP.  Having said that, my understanding is that the CMSIS DSP is just a C library, without optimizations for any particular processor; the performance you can get will depend on your compiler, and you will generally take a hit of something like 2x versus the achievable speed of hand-crafted assembly.  NXP had/has a DSP library for its Cortex-M3 chips that was hand-optimized assembly, but they declined to port it forward to take advantage of the extra DSP instructions on the M4.  I've read on these forums that this library on the M3 performs about as fast as CMSIS DSP on the M4, i.e. on the M4 you gain more SIMD instructions but that advantage is offset by the fact that there are no freely available assembly libraries for FFTs, filters, etc.  (I think an NXP rep countered by saying the M3 library would run fine on the LPC43xx, which is obviously true, but rather misses the point.)

But none of this should really deter you.  Look at it as a learning opportunity.  When I was in school we did baseband I/Q processing for ham radio (basically some long FIR filters) using a Motorola 56002 dedicated DSP processor.  Today's Cortex-M4 controllers have significantly more power, so there is lots you can do.

Re: memory, I think the bottleneck in SPIFI would not be the interface but the flash device itself.  If you're OK with the speed and endurance limitations of flash memory, I would probably use the SD card interface instead.  That would give you an easy route to data interchange with a PC.  Of course, SRAM or DRAM on the EBI will be much, much faster.

---

Thanks for your thorough response! Thats unfortunate to hear about the CMSIS DSP library but not too surprising. Having been working at an audio company as a hardware design intern this summer I totally understand how assembly can be much faster than compiled C, all the devices made at this company are coded by hand on the assembly level using every single clock cycle possible. As far as memory goes I think I'm going to want to use SRAM on the EBI because I want to attempt processing stereo audio at 24 bits in real time, I doubt the internal memory on the LPC4337 is going to be enough to handle that kind of audio but I could be wrong, I'll have to run some tests.

For this design I will be recycling most of the schematic for my original LPC4337 board the marlin, what will be new to the hardware design is an SRAM bank, Wolfson WM8778 audio codec, line level preamplification, switching regulators for power, and an SD card slot. I have everything figured out hardware wise except the SRAM over EBI, and connecting the audio codec over I2S. I have designed using I2S before at work but the naming conventions on the two parts I was working with are very different from the NXP naming conventions. I setup a Wolfson SPDIF transceiver with an ADI DSP, the naming conventions of the I2S interface on the codec I want to use are similar to the transceiver but for the LPC4337 Its very confusing. Would you mind showing me how to wire up the WM8778 to the LPC4337?

[lpcware]

Content originally posted in LPCWare by mark03 on Fri Aug 16 10:19:44 MST 2013
The LPC43xx should have the power to handle a wide range of audio DSP.  Having said that, my understanding is that the CMSIS DSP is just a C library, without optimizations for any particular processor; the performance you can get will depend on your compiler, and you will generally take a hit of something like 2x versus the achievable speed of hand-crafted assembly.  NXP had/has a DSP library for its Cortex-M3 chips that was hand-optimized assembly, but they declined to port it forward to take advantage of the extra DSP instructions on the M4.  I've read on these forums that this library on the M3 performs about as fast as CMSIS DSP on the M4, i.e. on the M4 you gain more SIMD instructions but that advantage is offset by the fact that there are no freely available assembly libraries for FFTs, filters, etc.  (I think an NXP rep countered by saying the M3 library would run fine on the LPC43xx, which is obviously true, but rather misses the point.)

But none of this should really deter you.  Look at it as a learning opportunity.  When I was in school we did baseband I/Q processing for ham radio (basically some long FIR filters) using a Motorola 56002 dedicated DSP processor.  Today's Cortex-M4 controllers have significantly more power, so there is lots you can do.

Re: memory, I think the bottleneck in SPIFI would not be the interface but the flash device itself.  If you're OK with the speed and endurance limitations of flash memory, I would probably use the SD card interface instead.  That would give you an easy route to data interchange with a PC.  Of course, SRAM or DRAM on the EBI will be much, much faster.