I doubt very much they're unable - more unwilling to. I guess they see peripherals as the way that customers differentiate their ARM offerings. Yet I think it would be a good thing if ARM was more proactive in peripheral design - at least for the more 'core' stuff like serial, because then we might see more innovation in other areas - like NXP's SPIFI and SGPIO for instance. NXP's SSP is ARM's design but few other vendors use that (TI does I think, STM doesn't). An ARM designed I2S would be a boon.
Minor update: the LPC4310, 4320, 4330, and 4350 parts' status has transitioned to production and the datasheet was revised 10/11. Nothing really of note unless one happens to be targeting the 180 BGA where some of pins moved but there's a bit more detail on power consumption that's interesting for regulator sizing and such (the SGPIO peripheral's draw is still <tbd> but it's probably a few hundred microamps). Looks like I can run my XO+EQ with about 20mA. Versus 17mA for the SPDIF receiver and 16mA for the DAC's digital side. And 120mA typ for DAC analog and the output buffers. Darn op amps. 
LPCXpresso 4.3.0 is out too. But I've been busy with layout verification and have to get code for Q31 filter bank synthesis together so haven't updated---there'll probably be another update by the time I get back to firmware.
LPCXpresso 4.3.0 is out too. But I've been busy with layout verification and have to get code for Q31 filter bank synthesis together so haven't updated---there'll probably be another update by the time I get back to firmware.
Minor update: the LPC4310, 4320, 4330, and 4350 parts' status has transitioned to production and the datasheet was revised 10/11. Nothing really of note unless one happens to be targeting the 180 BGA where some of pins moved but there's a bit more detail on power consumption that's interesting for regulator sizing and such (the SGPIO peripheral's draw is still <tbd> but it's probably a few hundred microamps). Looks like I can run my XO+EQ with about 20mA. Versus 17mA for the SPDIF receiver and 16mA for the DAC's digital side. And 120mA typ for DAC analog and the output buffers. Darn op amps.
LPCXpresso 4.3.0 is out too. But I've been busy with layout verification and have to get code for Q31 filter bank synthesis together so haven't updated---there'll probably be another update by the time I get back to firmware.
what are you making ?
An embedded replacement for my PC XO and EQ. At the moment it's a WM8805+LPC4300 in LQFP144 (the 4310, 4320, or 4330 are all available in this package and are pin compatible)+CS4565 SPDIF->DSP->DAC board. The BOM's been through several iterations and might change again but it looks fairly well converged at this point.
Thought I’d mention I’ve implemented equivalents of arm_biquad_cascade_df1_q31 (32 bit fixed point samples with 64 bit accumulate), arm_biquad_cas_df1_32x64_q31 (32 bit fixed point samples with 64 bit accumulate and feedback), and a higher precision version that would be probably be called arm_biquad_cas_df1_64x64_q31 (32 bit fixed point samples with 64 bit accumulate, coefficients, and feedback). I’ve been using the code on a PC to do some of the numerical characterization Abraxalito, Steph, and I were discussing over on the IIR Lab thread and have found that, chosen appropriately, the filters hit the quantization noise floor of 24 bit audio. This is comfortably below the noise floor of an ES9012 DAC in mono.
As a rule of thumb, for redbook audio Q31 is sufficient for filters centered at 1kHz and above, Q31_32x64 is sufficient to around 200Hz, and Q31_64x64 is a good choice below that. Back of the envelope I’m estimating my relatively complex 38 biquad three way XO+EQ would require a Cortex M4 core running at 60MHz. Scale accordingly for higher sample rates.
If you want to do your own investigations grab the latest Cross Time DSP commit and have look at the unit tests to get started.
As a rule of thumb, for redbook audio Q31 is sufficient for filters centered at 1kHz and above, Q31_32x64 is sufficient to around 200Hz, and Q31_64x64 is a good choice below that. Back of the envelope I’m estimating my relatively complex 38 biquad three way XO+EQ would require a Cortex M4 core running at 60MHz. Scale accordingly for higher sample rates.
If you want to do your own investigations grab the latest Cross Time DSP commit and have look at the unit tests to get started.
You mean CS4365 DAC? Do you have all of them (SPDIF,DSP and DAC) on the same board or separate ones? I think modular design would suite best for people who like to use different components (SPDIF receiver, ASRC, clock, DAC's etc). How are you clocking the DAC? Is it interface using SGIOP? I'd like to use the Crystal DAC as well but also with XMOS and it's I2S lib need you have an external clock (24.576 MHZ for an example) feeding XMOS which is the master and generates other clocks. With XMOS it's also easy to use ADAT interface as output.
Yes, 4365; 4565 is a typo. SPDIF, DSP, and DAC are all on the same board with one of the WM8805's clock outputs going to the CS4365 and the other to the LPC4300. I'm using a mix of the 4300's I2S and SGPIO peripherals and the preliminary schematic includes an expansion header with duplex clocking, I2S receive, and the seven SGPIO lines that aren't used for driving the 4365.
So it's not modular per se, but if one wants to patch in an ADC, different multichannel DAC, alternate clock, or pretty much any arbitrary I2S source or sink it's not particularly difficult.
So it's not modular per se, but if one wants to patch in an ADC, different multichannel DAC, alternate clock, or pretty much any arbitrary I2S source or sink it's not particularly difficult.
So you haven't been considering adding a sample rate converter? Anyway, the LPC4300 looks interesting because of the SGPIO, using multiple I2S ports feels complicated because separate clocks are needed for both interfaces.
Btw. is the 4300 pinout compatible with 2294 for an example, there are these modular (empty) boards I'd like to use:
Empty ARM MCU Cards for NXP LPC devices - mikroElektronika
E: To answer myself they aren't compatible.
Last edited:
Considered and rejected based on ABX results (and some maths). The time domain degradation from resampling is inversely proportional to the change in sample rate and proportional to the steepness of the antializasing filter. I found 4x resampling with a slow rolloff was OK, but preserving the original bit rate was subjectively preferable. It can also be computationally preferable; for biquads CPU scales rather like O(N log N) with sample rate due to the increased precision needed when the filters are operated at low normalzied frequency.
Lpc4300 starts looking interesting. Has anybody tried using the FPU yet? There is an experimentation documented (with source code) here:
LPC4350 I2S real time stereo audio filtering example | www.LPCware.com
LPC4350 I2S real time stereo audio filtering example | www.LPCware.com
You can find the Cortex M4 instruction set documentation here. See post 365 in this thread for links to CMSIS DSP and rules of thumb for the number of bits needed in a filter implementation.
For audio DSP on the Cortex M4 I don't see any particular advantage to single precision floating point over 32 bit fixed point; SMLAL is a 64 bit accumulate while VFMA is a 32 bit accumulate. You might be able to save a few clocks with arm_biquad_cascade_df1_f32 compared to Q31 and maintain comparable precision at higher normalized frequencies. But it's probably not worth the additional scaling complexity and the CPU cycles for converting incoming samples to floating point and then back to fixed point for output.
Best way to be precise about CPU requirements versus accuracy is to set up your desired filter bank in F32 and Q31, look at the assembly the compiler generates, run some test vectors through both, and compare the output streams to reference output data calculated using F64 or something in the vicinity of Q63.
For audio DSP on the Cortex M4 I don't see any particular advantage to single precision floating point over 32 bit fixed point; SMLAL is a 64 bit accumulate while VFMA is a 32 bit accumulate. You might be able to save a few clocks with arm_biquad_cascade_df1_f32 compared to Q31 and maintain comparable precision at higher normalized frequencies. But it's probably not worth the additional scaling complexity and the CPU cycles for converting incoming samples to floating point and then back to fixed point for output.
Best way to be precise about CPU requirements versus accuracy is to set up your desired filter bank in F32 and Q31, look at the assembly the compiler generates, run some test vectors through both, and compare the output streams to reference output data calculated using F64 or something in the vicinity of Q63.
Last edited:
I finally got my LPC4330 dev board this week This one, from Taobao, 388rmb (around $60) : LPC4300 LPC4330 Cortex-M4 ¿ª·¢°å NXP LPC M4-ÌÔ±¦Íø
The seller has good English so if you have the requisite chat software installed, you can contact him.
Incidentally another snippet of gossip for ARM-philes : TI looks to be making a move away from ARM. For example the older M3 Stellaris parts have an EOL announcement and the newer parts with ARM on-board look to be just marketing ploys to sell TI's proprietary CPU. Expect the Stellaris M4 range never to be fully released, its been absolutely ages...
This one, from Taobao, 388rmb (around $60) : LPC4300 LPC4330 Cortex-M4 ¿ª·¢°å NXP LPC M4-ÌÔ±¦ÍøThe seller has good English so if you have the requisite chat software installed, you can contact him.
Incidentally another snippet of gossip for ARM-philes : TI looks to be making a move away from ARM. For example the older M3 Stellaris parts have an EOL announcement and the newer parts with ARM on-board look to be just marketing ploys to sell TI's proprietary CPU. Expect the Stellaris M4 range never to be fully released, its been absolutely ages...
Last edited:
Sorry for T.I. They missed the train. They may be cooked. I'm getting the same impression about Infineon XMC4500. China-based or Taiwan-based companies produce their own ARM-licenced chips nowadays. I'm afraid the whole USA silicon industry is due to collapse soon. We'll have the priviledge to watch this. Microsoft Windows 8 RT (for ARM) remaining an unfinished product, hesitating between tablet and desktop, the x86 era end got delayed by a few months. This helps hiding the fact that Intel is cooked. Even if Intel starts producing ARM-licenced chips for Apple, it is way too late and anyway volume will remain insignificant compared to worldwide figures. Now guess what will follow, after the USA silicon industry collapse?
There will be a new era opening with silicon chips embedding ROM describing their internal architecture using spice netlists and an XML description of their registers. Human will become less and less needed, for setting up and programming silicon devices. Complexity and versatility (reconfigurable silicon) will rise to a level, so high that it will come beyond human undertstanding. All what we are doing, at the moment, is prehistoric electronic engineering. This helps me swallow the pill of an imminent USA silicon industry collapse. Come back in 20 years. A child, of course assisted by design tools, will be able to design, assemble and program a computer equivalent to our best current desktops. A child will be able to design a cross-compiler enabling a Sinclair Spectrum Pacman source code, to run on it. A specialized 3D printer will enable such computer to replicate at a very low cost.
The fact that it took about 18 months for getting some kind of Cortex-M4 board executing IIRs (and I'm not even speaking about the fact that such board doesn't have audio ADCs and DACs), is an indication that electronics management, marketing, and engineering are outdated. Time has come for a radical new vertical integration. Only a few companies are on the right track. Those may survive.
Last edited:
I agree Steph - both TI and Intel are toast. The future belongs to the MediaTeks and Allwinners whose volumes are being ramped by sales of smartphones and tablets. TI's pulled out of where the real volumes are and Intel's only play-acting in mobile. The only question left in my mind is whether National (maybe in conjunction with BB) can be spun out once again before TI dies...
You seems you are all going with some LPC4300 kits / builds. The Infineon XMC4500 Relax Lite kit (which also includes USB debugger) costs only 12.95 EUR on Mouser, but it seems quite a slow compared to LPC4330 (only 120 MHz system frequency). Might still be ok for couple of biquads though.
Btw. Is it possible to have an external clock (MCLK or oscillator) to be used to clock the SGIOP on the LPC parts? I would like to have as little jitter as possible and put oscillator on DAC board with the DAC itself running as slave.
Depends on the biquad precision and the number of instructions required to drive the USICs, but 120MHz is probably enough for around 75 biquads for redbook, assuming a typical mix of 32 bit and 32x64 bit and that you're coding with the ARM CMSIS DSP library.
Yes, though I suppose an update to post 120 is in order. To summarize the LPC datasheet and manual, half of the SGPIO slices can be used as clocks for other slices. Additionally, there are two to four pins that can be used as inputs to the CGU (clock generation unit) and routed to the SGPIO peripheral. The number of pins depends on the package.
After studying the data sheet of XMC4500 better I realized that the external clock input is not for MCLK but for SCLK, or as they call it "shift clock" (=bit clock in I2S). If you divide the MCLK by 256/64 (MCLK/LRCLK ratio / frame length) =4 you get the proper frequency, but I'm not sure if XMC4500 can generate the LRCLK in slave mode. The data sheet is little bit void in some areas. The LPC4300 with SGIOP seems to be the M4F family best suited for 6 or more output channels.
Now has anyone designed his/her own boards yet? There were some posts regarding multiple multichannel DAC's that would be interchangeable. If this idea is still alive it would be nice if the pinout (and the physical connector, propably just a usual two-row 0.1" pin header with ground lines between the signal lines) for the multichannel DAC's would be published early. Regarding DAC's there is already one good quality multichannel DAC available from ASUS - ASUS Xonar H6 - it's meant for Xonar soundcard's surround channels but is quite good quality one (http://www.asus.com/Sound_Cards_and_DigitaltoAnalog_Converters/Xonar_H6/). I have it's pinout somewhere, and if we sticked to that pinout then we don't need to build the DAC, only the processor board and power supplies + analog or digital input board (with or without SRC). H6 uses I2C (each of CODEC's has own address), and has one pin for mute relays. It's got also inputs for 3.3V, 5V and +/-12V (guess 12-18V is ok for the opamps) supplies.
Now has anyone designed his/her own boards yet? There were some posts regarding multiple multichannel DAC's that would be interchangeable. If this idea is still alive it would be nice if the pinout (and the physical connector, propably just a usual two-row 0.1" pin header with ground lines between the signal lines) for the multichannel DAC's would be published early. Regarding DAC's there is already one good quality multichannel DAC available from ASUS - ASUS Xonar H6 - it's meant for Xonar soundcard's surround channels but is quite good quality one (http://www.asus.com/Sound_Cards_and_DigitaltoAnalog_Converters/Xonar_H6/). I have it's pinout somewhere, and if we sticked to that pinout then we don't need to build the DAC, only the processor board and power supplies + analog or digital input board (with or without SRC). H6 uses I2C (each of CODEC's has own address), and has one pin for mute relays. It's got also inputs for 3.3V, 5V and +/-12V (guess 12-18V is ok for the opamps) supplies.
Is the ASUS Xonar H6 2x12pin header specification available ? PCIe 1x only used for DC supply ?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.