there are lots of reports on this thread. not much going on in the nuts and bolts department
I haven't found any problems integrating an LPC4300 with the CS42xxx family yet. I'm not particularly familiar with Wolfson's codecs but figure 25 in 8581 datasheet shows CS42xxx equivalent IO so I'm not seeing any problems integrating a 4300 with an 8581 either. One does have to pay attention to pin assignments and bus directions when assigning external IO to I2S peripherals and SGPIO slices but it's not hard. Tedious maybe, but keeping track of that kind of stuff is what spreadsheets and schematics are for.
I haven't placed my LPC4300+CS42526 board yet but from the floorplanning it looks like all IO lines between the two parts (including I2C, interrupt flags, and reset) can be done without any vias on a two layer board. I will say I find the pin assignments for the I2S peripherals on the LQFP144 package I'm currently targeting perhaps a little quirky. But it's no big deal.
Thanks for communicating about this. It looks positive and reassuring. Since the beginning of I2S we see different ways to practically implement it.
The first I2S applications were in CD players equipped with an I2S DAC, the CD decoding chip acting as master, and providing the MCLK.
Later on we've got the record/play digital audio like the DAT, Mini Disc and Digital Compact Cassette, featuring an ADC and a DAC connected using I2S, acting as I2S slaves and receiving the MCLK from the controller chip, just as usual.
A third generation came when S/PDIF needed to be used as audio input. This time the controller chip (or DSP chip) could not always act as clock generator as when the audio input was S/PDIF, the S/PDIF recovered clock needs to serve as master clock. On the other hand, when the audio input is analog, a local crystal oscillator is used as clock generator. Such evolution reinforced the idea that a proper I2S implementation needs to keep the DSP away from the MCLK generation. Therefore, the industry produced more and more advanced Audio Codecs featuring a S/PDIF input, acting as highly integrated modules, isolating the DSP from the MCLK generation in any circumstance.
Modern Audio Codecs featuring an S/PDIF input like Wolfson WM8580 (year 2009 maybe) and Cirrus CS42526 (year 2005 maybe) exactly do this, with excellence.
The WM8580 features a quartz oscillator (XTI, XTO) followed by a programmable PLL able to generate all basic MCLK frequencies, both the 44.1 series and the 48.0 series, using a single 27.0 MHz quartz.
The CS42526 is slightly inferior, or perhaps more audiophile oriented, having no internal PLL associated to the basic MCLK, which means that you need two quartz oscillators (and select the right one) if you want to cover both the 44.1 series and the 48.0 series. I say "more audiophile oriented" because Cirrus may have felt that by relying on a PLL even for the basic MCLK generation, they would get critics from Audio enthusiasts.
Both the WM8580 and CS42526 feature a S/PDIF clock recovery circuit basing on a dedicated, separated PLL, acting as alternate MCLK generator. The general feeling is that the Wolfson S/PDIF clock recovery scheme is better than the Cirrus one. Don't know how those two particular chips compare, actually.
You may then ask why the WM8580 features a MCLK pin configurable as input or output. I would say that WM8580 pin 24 should remain unconnected in a plain normal application. I consider WM8580 pin 24 to be helpful as output, when debugging, for analyzing MCLK as generated by the internal PLL. I also consider WM8580 pin 24 to to be helpful as input, again when debugging, for comparing the resulting audio signal/noise figure, between using the internal PLL for generating MCLK, and using an external clock. I would never use WM8580 pin 24 in the definitive application, never route it on the board, and never make it touching the DSP chip.
Now practically, what to do with the CS42526? It needs some external frequency management if wanting to cover the 44.1 and 48.0 series. We have RMCK (pin 55 as input), receiving the 11.2896 MHz (44.1 series) or the 12.288 MHz (48.0 series). From an audiophile perspective, you need to rely on two different oscillators, that the LPC4330 commutes using a GPIO line. This way people are not going to raise questions about the MCLK clock quality, especially when you show them that each oscillator is made of unobtainium, maintained at a precise xx temperature, same for the VCC supplies. Kind of joke. From a practical perspective, a possibility is to have MCLK coming from a LPC4330 PLL. Doing so you will cause some audio quality dilution as the CS42526 will be responsible for 80% of the audio quality, and the LPC4330 the remaining 20%. That's a simple way to see it. You better ensure that the MCLK copper track going from the LPC4330 to the CS42526 doesn't radiate, and doesn't capacitively couple to other tracks.
I just went looking to two potential LPC4330 contenders.
I got impressed by the STM32F37x announced as featuring three I2S, even in the 48-pin package. Warned by abraxalito, I checked the I2S implementation and discovered that STM multiplexed the four pins of a plain normal SPI (SDO, SDI, CLK, CS) with the (SD, CK, WS and MCK) of a so-called I2S. Which means that each I2S is unidirectional, and capable of delivering the MCLK. Such "thing" should not be called I2S. On top of this, on the STM32F37x 48-pin package, if you need USB, it clashes with I2S1 and I2S2. For avoiding this, you need the STM32F37x 64-pin package. This means that you need a 64-pin STM32F37x for doing a stereo 2-way crossover (one I2S as input, two I2S as output), something you should be able to do using a 28-pin Microchip PIC32MX2 featuring two bidirectional I2S (or supposed to be so).
Another LPC4330 contender is the Infineon XMC4000 - XMC4500. They announce it as having six flexible serial interfaces, each capable of I2S. Don't know if the I2S are bidirectional. Worst case scenario would be they are unidirectional, in which case you would consume four I2S for a stereo 3-way crossover (one as input, three as outputs), plus one as I2C (for the Codec control), and you still have a spare serial interface, perhaps a SPI for controlling some external, high quality volume control chips. Looks straightforward.
After all those years chasing for a Cortex-M4 featuring a decent amount of I2S, I mean plain normal bidirectional I2S, I have the impression that ARM doesn't want to market this. One reason may be ARM and Freescale slooowly teaming up for organizing the final and definitive DSP56K obsolescence (one of the first integrated DSP architecture) and the definitive ColdFire obsolescence (the very old 68K architecture after some instruction set simplification). New 65 nanometer Cortex-M4 chips, single core and dual core, clocked at 320 MHz, badged Freescale, could materialize a new generation replacing the entire DSP56K + ColdFire range. A 65 nanometer Cortex-M4 running at 400 MHz would nearly provide the MAC/s performance of a DSP56K clocked at 250 MHz. It can't provide 400 Mega MAC/s because if lacks the zero loop overhead (critical in FIRs), the bit reversal addressing mode (critical in FFT), and the fast short interrupt (possibly replaced by powerful DMA schemes). Later on, and still on a 65 nm design rule, speed-optimized Cortex-M4 cores could run at 800 MHz, delivering more MAC/s than any existing DSP56K or ColdFire. The only big issue with such concept, even clocked at 800 MHz, is the lack of bit reversal addressing in the Cortex-M4, critical for computing FFTs. How many years shall we wait ?
Since 2007, since the Microchip PIC32 basing on the MIPS M4K architecture, we get significant PIC32 silicon upgrades every two years. In 2009 the PIC32 gained buffered SPI. In 2011 the PIC32 gained SPI with "Audio Mode" aka I2S.
Keeping such pace, as soon as 2013 we could get PIC32 chips with the 65nm design rule (320 MHz?), some MIPS DSP extensions, and the TDM interfaces (multichannel audio).
A few month ago, Microchip signed the MIPS 14K licence. Microchip may also have signed the MIPS microAptiv licence. MIPS microAptiv core (unveiled May 10th 2012) is based on the prior-generation M14K/c cores, with the addition of microMIPS code compression support and the DSP ASE function block. It comes in both cache-less (microcontroller) and cache-inclusive (microprocessor) variants.
More info here: MIPS' Aptiv: DSP Capabilities Become Pervasive | www.bdti.com
Do we get the the bit reversed addressing on MIPS DSP ASE, for optimizing the FFT computation? Anyway, with MIPS teaming up with Microchip, there should be less slooow politics than in the ARM-Freescale play field, meaning that if Microchip wants to design a chip aiming at terminating both the DSP56K and the ColdFire, they can do it overnight - should I say if the MIPS DSP ASE feature the bit reverse addressing, and if they add TDM interfaces on top of SPI/I2S.
A Microchip microAptiv chip featuring on-chip Flash memory, only featuring 28 pins and a pin multiplex scheme like on the PIC32MX1/2, equipped with TDM for talking with a WM8580 or WM8581, can also feature USB 2.0 host/device/otg, a few extra SPI, and I2C. Take the 44-pin Microchip microAptiv chip and you also get Ethernet. Add an external, optional MHL/HDMI receiver and your application could grab audio from any source. There can be one hundred millions chips like this sold each year in audio docking stations, USB speakers, TV sound bars, and active speakers.
Now, grab the MIPS proAptiv range (MMU, external SDRAM, third-party graphics coprocessor), and you get a chip directly competing with the ARM Cortex-A9 MP and Cortex-A15 MP, able run Android phones, tablets and TV boxes. As Ingenic Semicoinductor already got support for compiling Android 4 on MIPS, one can infer that the MIPS Android compiler will get an upgrade for supporting the newest MIPS proAptiv chips. If on top of this, Google buys some MIPS assets, you'll see interesting things coming, like billions of chips like this, sold each year.
Quite strange is that Intel is nowhere into this. That's weird, especially now that Steven Sinofsky from Microsoft, announced WOA (Windows on ARM) on February 9th, 2012. Shall we really believe that Intel is busy, on an industrial scale, porting Android on x86?
Last edited:
Over here. Keep in mind baseband jitter is attenuated by about 50dB in SPDIF period jitter measurements so Wolfson's 50ps headline spec is essentially irrelevant.
This is exactly what we have waited for so long. Will you help us getting this running on NGX LPC4330 Xplorer? Using KEIL MDK ARM with ULINK2/ME or using LPC-Xpresso with NXP LPC-Link?
Last edited:
Very cool. +1 on Steph's questions about the toolchain you're using.
In case one's wondering what's in the .zips, they contain eight apps. Most don't play nicely on my Win7 SP1 x64 box with UAC enabled.
- DFT iDFT - install fails on permission to c:\DFT_iDFT_A.txt denied
- FIR LAB - install fails on permission to c:\FIR_Lab.txt denied
- iDFT XO - install fails on permission to c:\iDFT_XO.txt denied
- iDFT XO CG - install fails on permission to c:\iDFT_XO_CG.txt denied
- iDFT XO CSRn - install fails on permission to c:\iDFT_XO_CSRn.txt denied
- iDFT XO CSTBSi - install fails on permission to c:\iDFT_XO_CSTBSi.txt denied
- IIR Lab 1.03 - analyzes IIR biquads at various numerical precisions
- IIR Lab Mini 1.03 - simplified version of the above
I know version 1.00 of IIR Lab can be found in other threads. Steph, I'll dig our previous discussion of the tool up and reply on the appropriate thread when I get the time.
Thanks for reporting this. I just tried installing the apps on Windows 7 SP1 - 32 bits and if fails the same way. See the full error report, attached. Clearly such "exception" error is coming from Microsoft .Net Framework. After having read the entire error message, I'm asking myself if I should continue software development using Microsoft tools. Those .net apps look fragile.
This seems to be a Win7 runtime error.
"System.UnauthorizedAccessException: L'accès au chemin d'accès 'C:\DFT_iDFT_A.txt' est refusé."
Win7 doesn't allow the apps to create files on the C:\ hard disk.
Such file contains the IIR or FIR coefficients, in text format.
Need administrator rights on Win7?
How to do this?
Currently my Win7 PC only knows one user, and it's me. There is no administrator showing on the user list / session switch. So how can I get administrator rights?
However, if you have access to a WinXP computer, the apps should install an run nicely.
Last edited:
Nah, it's windows who denies to write to the root of C:\, security thing, by UAC et cetera.
Use program files or user's directory in mydocs. User's directory is the proper way, but i tend to ignore this
You can create these files yourself, and then the windows won't scream... i think. it worked for me, in the past...
Use program files or user's directory in mydocs. User's directory is the proper way, but i tend to ignore this
You can create these files yourself, and then the windows won't scream... i think. it worked for me, in the past...
Last edited:
You shouldn't (ever) be installing any files into the root of drive c:
They should all be going into the folder used by the application install, or a data folder which is specific to a user or 'all users'
It looks like you've missed off a leading %enviromentvariableofsomekind% as the path to your text files
They should all be going into the folder used by the application install, or a data folder which is specific to a user or 'all users'
It looks like you've missed off a leading %enviromentvariableofsomekind% as the path to your text files
Yup, what s3tup and ChrisPa said. I like OneClick tools as their installers typically don't request elevation to get administrative access, helping keep a security cordon around apps downloaded from the net. If Win7 imposes a tighter cordon than XP that is, so far as I'm concerned, an OS feature rather than a bug.
I've coded primarily in C# for my day job for the better part of the past decade. In my experience .NET is pretty well bombproof. Steph, if you look a little more carefully at that exception's stack it's doing its job of telling you exactly where the issue in your code is---if you drop the .pdb in the same folder as the .dll/.exe you'll even get the line number of the failing code.
I've coded primarily in C# for my day job for the better part of the past decade. In my experience .NET is pretty well bombproof. Steph, if you look a little more carefully at that exception's stack it's doing its job of telling you exactly where the issue in your code is---if you drop the .pdb in the same folder as the .dll/.exe you'll even get the line number of the failing code.
Thanks for your help. A quick fix is to write the IIR and FIR coefficients into the "C:\Documents and Settings\All Users\Documents" directory. Hardcoding this, without relying on an environment variable. I tested it successfully on Windows 7. In MS Visual Basic 2010, what is the environment variable corresponding to "C:\Documents and Settings\All Users\Documents", including the drive letter ? I would prefear using such environment variable, concatenating it with the filename, just in case the final user is running on a D:\ drive, or anything else. I'll update all the apps accordingly tomorrow. Thanks, again.
All apps now revamped and tested OK on Windows 7. See attached .zip files. Thanks for the feedback.
In order not to overload this thread, I created a dedicated thread. See it here http://www.diyaudio.com/forums/digital-line-level/218164-idft-based-xos-fir.html#post3131773
Cool. I've had some time to work on my 4300 based DSP+DAC project lately, an offshoot of which is the attached spreadsheet for tracking pin assignments. It does not attempt to be exhaustive but does capture a reasonable proportion of the interesting peripherals. NXP's cancelled packages and defined new pinouts since I started working on this but it should be correct barring typos or changes on NXP's part that I missed---it's based on the early June datasheet and manual. Anyone who happens to find errors, PM me the changes.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.