Open Source DSP XOs - Page 12 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 25th January 2012, 03:23 AM   #111
diyAudio Member
 
Join Date: Jun 2009
What tools are available for the LPC4300 or ST M4 and how much are they ??

How much is a JTAG ICE for the LPC4300 ??

regards
Trev
  Reply With Quote
Old 25th January 2012, 05:10 AM   #112
diyAudio Member
 
Join Date: Jun 2009
For NXP, see links in the second paragraph of post 106.
  Reply With Quote
Old 25th January 2012, 05:28 AM   #113
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 98
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
For ICE, I think you could try using the USB-JTAG (or USB-SWD) half of this board:

New LPC1343 LPCXpresso board OM11048 NXP ARM Cortex FREE SHIPPING | eBay

Its cheaper than getting a stand-alone ICE and you get the 72MHz M3 thrown in for free
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 4th February 2012, 03:18 AM   #114
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 98
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Default Next up - Atmel

Atmel has announced sampling of its Cortex M4s - production due 2Q 2012. 120MHz, datasheet here : http://www.atmel.com/Images/11100.pdf

<edit> From a quick scan of the DS, not really interesting at all for audio - just one I2S, only full speed USB.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler

Last edited by abraxalito; 4th February 2012 at 03:22 AM.
  Reply With Quote
Old 4th February 2012, 02:58 PM   #115
diyAudio Member
 
Join Date: Jun 2009
I took a skim through the SAM4S datasheet a week or two ago and didn't see a good way of repurposing another peripheral---such as the PIO---to provide I2S either.

Quote:
Originally Posted by steph_tsf View Post
What about T.I. LM4F1xx and LM4F2xx Cortex-M4 ? How many I2S ?
Zero on the block diagrams. The datasheets do have a presence bit for a single I2S module so perhaps TI plans to add a dedicated peripheral. The four SSI units are close to what one needs in that you get BCLK and data. But on a quick look I'm not seeing a good story for LRCK as there doesn't seem to be a way to rig SSIFss to have the necessary semantics.

Last edited by twest820; 4th February 2012 at 03:12 PM.
  Reply With Quote
Old 4th February 2012, 05:11 PM   #116
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Microchip updated their SPI block, adding the "audio mode" configuration bit for converting the Slave-Select pin into a LRCK pin.
They did it for the newly introduced PIC32MX1xx family and PIC32MX2xx family, equipped with 2 SPI.
The PIC32MX220F032B has thus 28 pin, and is equipped with two SPI that can be turned into two I2S. It is available in PDIP package with the "I/SP" suffix, ideal for hobbyists and one-shot projects.

Don't know yet if the same evolution will occur for largers PIC32 chips like the PIC32MX5xx and PIC32MX6xx featuring up to 4 SPI.

With the PIC32MX220F032B, you can implement a crossover "trench" using the following resources allocation :
- SPI_1 used as I2S, taking the full spectrum signal as input and delivering a filtered signal as output
- SPI_2 used as SPI for accessing the DACs internal registers.
The annoyance of such "trench" architecture is that you need two PIC32 chips for making a 2-way crossover, and three PIC32 chips for making a 3-way crossover. How to easily reprogram two or three PIC32 chips on a board ? How to organize the inter-chip communication if reprograming must be done using USB ?

With a little more effort, with the PIC32MX220F032B, you can implement a complete 2-way crossover using the following resources allocation :
- SPI_1 used as I2S, taking the full spectrum signal as input and delivering the lowpass filtered signal as output
- SPI_2 used as I2S, taking no input signal and delivering the highpass filtered signal as output
- a bit-banging SPI implementation using GPIOs for accessing the DACs internal registers (I guess Microchip website has sample code for this).

The 2-way crossover looks tempting. Only one PIC32 chip needed. Easy to program, easy to maintain.

The Microstick II (DM330013-2) is a small development kit made by Microchip, hosting a PIC32MX220F032B chip. The Microstick II (DM330013-2) actually supports all PIC32 SPDIP packaged devices. You should get it for 29.04 eur from Mouser.
DM330013-2 Microchip Technology Development Boards & Kits - PIC / DSPIC

If you destroy the PIC32 SPDIP chip, you can buy a new one from Mouser for 2.92 eur, and plug it into the 28-pin socket.
PIC32MX220F032B-I/SP Microchip Technology Microcontrollers (MCU)

Need to verify if the resulting PIC32 I2S can remain in sync and work as slaves, using a Wolfson WM8580 CODEC as master. The WM8580 has SPDIF-in, stereo Analog-in, and six Analog-out.

Need to verify if the PIC32 I2S can work with a 16-bit audio word lenght at the input, and a 24-bit audio word lenght as output.

Need to verify if the PIC32 I2S get some buffering, for off-loading the CPU when dealing with 32-bit or 48-bit frame lenghts.

Everything considered, I think the new PIC32MX2xx family is a great new toy to experiment with.

For testing the I2S protocol, I'll attach the MikroE Audio Codec Board - Proto. Audio Codec Board - PROTO - WM8731 Development Tool - mikroElektronika

I think I'll start with the PIC32, then switch to the ARM Cortex-M4 when the Infineon XMC family becomes available.
Or maybe stay with the PIC32 if Microchip manages to provide an "audio mode" for their SPI in their larger PIC32 chips, currently up to 4 SPI in a chip.

Last edited by steph_tsf; 4th February 2012 at 05:21 PM.
  Reply With Quote
Old 5th February 2012, 12:49 AM   #117
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 98
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Quote:
Originally Posted by twest820 View Post
The four SSI units are close to what one needs in that you get BCLK and data. But on a quick look I'm not seeing a good story for LRCK as there doesn't seem to be a way to rig SSIFss to have the necessary semantics.
On the LPC parts I've successfully used a timer to generate the WS. Only tried that in master mode though and getting the correct phase is a little tricky I had to put in some software delay empirically. Haven't quite figured a way yet to do it without human feedback in the setting of the delay.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 5th February 2012, 03:49 AM   #118
diyAudio Member
 
Join Date: Jun 2009
does the PIC32 have a fast multiply or MAC capability ?
  Reply With Quote
Old 5th February 2012, 06:07 AM   #119
rsdio is offline rsdio  United States
diyAudio Member
 
Join Date: Feb 2008
Location: Seattle
Quote:
Originally Posted by Trevor White View Post
does the PIC32 have a fast multiply or MAC capability ?
Good question.

From the data sheet: Single-cycle (MAC) 32x16 and two-cycle 32x32 multiply

It does make me wonder how they distinguish the dsPIC from the PIC32 families.
  Reply With Quote
Old 5th February 2012, 07:21 AM   #120
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by abraxalito View Post
I've successfully used a timer to generate the WS
Tricky to handle an I2S input that way, though. Even with the LPC4300's rather generous hardware resources I'm coming up against the part's limits. Both the I2S and SGPIO peripherals are convenient in that the input BCLK can be passed through as the output BCLK, meaning one doesn't have to implement an ASRC. However, it does not appear possible to pass an input clock directly from one peripheral to the other. In theory one can get around this by routing an SGPIO slice operating as an output clock to the GP_CLK pin and then sending that through the CGU to the I2S peripheral. But the approach is not especially attractive as it seems there are more valuable uses for GP_CLK. There's also the small difficulty that all current packages assign GP_CLK and I2S peripheral clocks to the same pin.

A better way seems to be to do all I2S signalling with SGPIO. Nominally, that provides five three pin I2S lines, up to four of which can be inputs. That accomodates two I2S sources and a three way crossover. If you have three or more sources and a three way cross you either have to fan out BLCK and LRCK (not the end of the world, though it means more cost, complexity, and possibly additive jitter depending on how fanout is implemented and how the DACs are clocked), use a multichannel DAC so that BCLK and LRCK are shared across data lines (not the end of the world either, though it significantly restricts part choices compared to working with stereo DACs), or do external muxing of the inputs (not a big deal). It would be nice to have three I2S inputs and three outputs, but I've sufficiently little need for the third input I'd prefer to go with two inputs and three outputs and get a single chip solution for all I2S management.

The snag is I2S is really a four wire interface once you account for MCLK, meaning simple use of SGPIO is limited to four I2S lines with the output MCLKs having some amount of additive jitter from being buffered within the LPC. This isn't bad---I don't know of any other part which could handle MCLK generation this way---but four I2S is one less than I need to avoid multiple PCBs for scenarios that are only slightly different. One solution's to use an ESS DAC in asynchronous mode, obviating the need to pass MCLK around. Another is to use a dual input clock generator with a sufficient number of outputs. That requires some glue code to change the clock gen's input when changing between the I2S inputs and incurs the cost and complexity of the clock gen, though it does admit use of a jitter cleaner and gets the MCLK pins off the LPC. A nicer approach would be to use PLL0AUDIO on LPC. Unfortunately, the behavior of its bandwidth selection currently seems to be undocumented, though as it's a DPLL, one can probably get pretty low cutoffs and hence be able to pass a reasonably low jitter MCLK to SGPIO. No spec on how much jitter the internal routing and SGPIO output buffers would add but, given NXP bothered to implement a fractional PLL and CLKOUT, it seems safe to assume some design attention was paid here and that the jitter would probably be in 60ps period jitter, 200ps peak to peak range typical of low cost parts.

The limitation with this approach is the logical choice for an external MCLK input---such as that generated by a Wolfson WM8804 or WM8805 SPDIF receiver---is GP_CLK. This is fine, but there's only one GP_CLK pin. So switching between different external MCLKs means repurposing ENET_RX_CLK as an audio clock. ENET_RX_CLK is only available on the 180+ pin packages. ENET_TX_CLK could also be used, but it's assigned to the CLKOUT pin and one may want to use CLKOUT to deliver an MCLK. Since CLKOUT would probably also be the SGPIO clock in this case one can use that 16th SGPIO slice that isn't being used for a BCLK, LRCK, or SDATA to deliver a second MCLK. There's no spec on how much skew you'd get from this but a safer option would be to fan out the output LRCK (since it's the lowest bandwidth signal among the I2S outputs) and use the two slices that frees up to deliver MCLKs to DACs. It then seems most natural to use CLKOUT as a clock supply for the second I2S input.

If you add all that up I think this means it's probably just viable to implement a three way crossover with a SPDIF input and an auxillary I2S input which could be used for an ADC or such in a single LPC4300. If one needs a third input it's probably still workable in a single chip, but only if all you need is a two way crossover. Similarly, if it's a four way crossover then external muxing is required for multiple inputs. The only thing I can't fit in to SGPIO is a second LRCK pin---that's needed for the variable Fs we were discussing a few posts back since it requires LRCKs at different rates. Have to take a look and confirm there's a way to get a clock synchronous to SGPIO BCLK over to an SSP, SPIFI, USART, or similar peripheral but---worst case---it should be possible to bit bang an extra LRCK.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Volume / Source selector - open source project ? AuroraB Analog Line Level 22 22nd September 2012 02:21 PM
Violet DSP Evolution - an Open Baffle Project cuibono Multi-Way 211 18th May 2010 02:26 AM
Open call for suggestions on Open Source DIY Audio Design gfergy Everything Else 1 15th April 2007 07:33 AM
Open Source, Open Architecture! zenmasterbrian Digital Source 185 23rd February 2007 10:35 PM


New To Site? Need Help?

All times are GMT. The time now is 11:24 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2