Open Source DSP XOs - Page 15 - 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 17th February 2012, 09:11 AM   #141
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by abraxalito View Post
JTAG/SWD Segger J-Link Debug Probe at 300 dollars or JTAG/SWD Red Probe+ at 150 dollars : no need to spend so much - check out the link I've given above to an eBay option.
I guess you refer to post #113 : breaking a LPC1343 LPCXpresso board in two parts, only using the JTAG Debug Probe section. I have three objections.

1. The JTAG Debug Probe section of the LPC1343 LPCXpresso board contains a NXP LPC3154 chip. Download the datasheet. The NXP LPC3154 combine an 180 MHz ARM926EJ-S CPU core, High-speed USB 2.0 OTG, 192 kB SRAM, NAND flash controller, flexible external bus interface, two I2S (I2S0 and I2S1), a Stereo Audio Codec hooked on I2S1, Li-ion charger, Real-Time Clock (RTC), serial and parallel interfaces. The LPC3154 are implemented as a multi-chip module with two side-by-side dies, one for digital functions and one for analog functions, which include Power Supply Unit (PSU), audio codec, RTC, and Li-ion battery charger. Such chip having two I2S, it is a waste to use it as USB to JTAG bridge, for debugging a low cost ARM chip like the LPC1343 providing no I2S.

2. Do you hope using the LPC3154 side of the LPC1343 LPCXpresso board, as JTAG Debug Probe for any kind of ARM chip, say the Cortex-M4 Freescale K10 (one I2S providing two I2S lanes) or the T.I. Cortex-A8 AM3358 (two McASPs providing eight I2S lanes) ? Have you checked this ? Won't you expect that the NXP firmware burned into the LPC3154, is only tolerating a JTAG connexion on a NXP LPC1343 as target ? Using the LPC3154 side of the LPC1343 LPCXpresso board, and turning it into a "open" JTAG Debug Probe sounds like an urban legend.

3. Even if today NXP has not locked the NXP LPC3154 firmware for only connecting on a NXP LPC1343, as soon as they know somebody gets a successfull JTAG connexion on any another chip than the NXP LPC1343, they will take countermeasures. And, while designing a digital audio crossover, I won't spend time in developing counter-countermeasures.

Now consider the PIC32MX1 and PIC32MX2 and the Microchip ICD3 Debug Tool at 200 dollars. See how they put you out of trouble regarding the debug. And remember : the PIC32MX1 and PIC32MX2 provide two I2S, even in their 28-pin variants.

Cortex-M4 is not mature yet for multichannel digital audio. Currently we miss Cortex-M4 chips featuring four I2S or one McASP.
The NXP LPC4300 is too complicated (no built-in Flash, two asymetric cores, SGPIO hard to configure).

Given this, if I need more CPU power and more than two I2S lanes, I'm only interested into the T.I. AM3358 Cortex-A8. Can somebody advise a proper AM3358 toolchain, BeagleBone compatible, easy to setup, with a decent cost, preferably not bloated by a Linux kernel ? I'm ready to spend 150 dollars for the the Red Probe+ but I'm not sure I can get a toolchain working the way I want, supporting bare metal programming enabling me to write and debug all Audio DSP routines in Cortex-A8 assembly code. Can somebody advise me, by experience ?

Last edited by steph_tsf; 17th February 2012 at 09:35 AM.
  Reply With Quote
Old 2nd March 2012, 01:30 PM   #142
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: 101
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Have a look at this vid and see if any of your objections are addressed to your satisfaction:

Debugging Applications with NXP LPCXpresso - YouTube
__________________
No matter if we meanwhile surrender every value for which we stand, we must strive to cajole the majority into imagining itself on our side - Everett Dean Martin
  Reply With Quote
Old 8th March 2012, 01:14 PM   #143
diyAudio Member
 
steph_tsf's Avatar
 
Join Date: Mar 2008
Quote:
Originally Posted by abraxalito View Post
Have a look at this vid and see if any of your objections are addressed to your satisfaction
Looks indeed that an urban legend translated into some reality ...
LPC1227 LPCXpresso LPC-Link | Embedded Artists AB
What are the supported ARM microcontrollers ?

Last edited by steph_tsf; 8th March 2012 at 01:21 PM.
  Reply With Quote
Old 16th March 2012, 03:01 AM   #144
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: 101
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Cortex-M0+ Processor - ARM

This baby does about 0.9MIPs/MHz so in practice its going to be able to comfortably run 10MMACs - say a 256 tap filter @44k1 for a power budget around 2mW at 100MHz on a 90nm process at a price projected to be under $0.40
__________________
No matter if we meanwhile surrender every value for which we stand, we must strive to cajole the majority into imagining itself on our side - Everett Dean Martin
  Reply With Quote
Old 17th March 2012, 04:34 AM   #145
diyAudio Member
 
Join Date: Jun 2009
The biggest problem that I see with this idea is that there are currently no development boards with the necessary audio hardware so someone is going to have to build the hardware and/or write the software and no one is going to do that for nothing !!
  Reply With Quote
Old 17th March 2012, 06:26 AM   #146
diyAudio Member
 
Join Date: Jun 2009
You might be surprised. Just don't hold your breath.
  Reply With Quote
Old 17th March 2012, 09:38 AM   #147
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: 101
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Well I'm currently designing a DAC to sit as a kind of piggy back on top of an LPC development board. I echo twest820's comments not to hold your breath for it, but it is taking form conceptually - I'm not doing it for nothing, but rather for myself, for fun
__________________
No matter if we meanwhile surrender every value for which we stand, we must strive to cajole the majority into imagining itself on our side - Everett Dean Martin
  Reply With Quote
Old 18th March 2012, 01:01 AM   #148
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by twest820 View Post
You might be surprised. Just don't hold your breath.
OK lets see the goodies
  Reply With Quote
Old 22nd March 2012, 01:03 AM   #149
diyAudio Member
 
Join Date: Dec 2010
Default Why not XMOS

Hello, this is my first post here so I excuse myself in advance if I missed something that was said before. I am right now building a pair of Orions, and would like to see how they sound with a DSP crossover. I find the prospect of having an open source DSP really good. However, having played around with a few DSPs and ARM processors, I find that the main difference is that in DSP you have a short code (you usually execute it all for each sample) which is executed synchronously. There is not much that can go wrong.

On ARM however you can never guarantee at what cycle a particular instruction will be executed. Just an interrupt can take up to 40 cycles while the registers are dumped into memory, etc. However, for open source I understand that specialized DSPs such as ADI or TI are not really an option.

I have worked a bit with the XMOS chips, and they do offer a great number of advantages for this type of application:
- fast: up to 4 cores, 500 MHz, 8 threads per core each with its own set of registers, single cycle MACC (32*32->64)
- synchronous: the exact time of execution of each instruction is deterministic to the cycle.
- flexible, reconfigurable I/O, you can have loads of I2S I/O
- loads of open source audio related code already exists: https://github.com/xcore/sc_dsp_filters
- development boards are affordable and the main development environment is open source, whereas with ARM the "standard" ones are commercial.

The chip is rather flexible, and we have used it as a MOSFET "controller" for a digital class D amplifier, where you really need to make sure that both transistors do not open at the same time. We could adjust the delays between the individual pins to about 3ns dynamically. Really impressive.

For biquads, it has been tested to do 20/thread at 48kHz, potentially you could use three cores (for woofer, midrange and tweeter), and one for doing the I/O.
With a few hundred biquads should be sufficient for most things.

I don't have that much time, but I can definitely find a couple of hours to test things out in the case more information is useful.
  Reply With Quote
Old 22nd March 2012, 04:15 AM   #150
diyAudio Member
 
Join Date: Jun 2009
Quote:
Originally Posted by Brunos View Post
Hello, this is my first post here so I excuse myself in advance if I missed something that was said before. I am right now building a pair of Orions, and would like to see how they sound with a DSP crossover. I find the prospect of having an open source DSP really good. However, having played around with a few DSPs and ARM processors, I find that the main difference is that in DSP you have a short code (you usually execute it all for each sample) which is executed synchronously. There is not much that can go wrong.

On ARM however you can never guarantee at what cycle a particular instruction will be executed. Just an interrupt can take up to 40 cycles while the registers are dumped into memory, etc. However, for open source I understand that specialized DSPs such as ADI or TI are not really an option.
This should not be an issue. Even on ADI dsp's interrupt latencies can be as long as 200 dsp cycles depending on the type of context switching you use. The important aspect of this is that as long as the latency does not consume the whole audio cycle then there will always be plenty of time to process the audio word and write it out to the serial port FIFO. Some DSP's such as the ADI offer block mode processing which means that a block of N samples is processed sequentially and the interrupt interval is lengthened by N audio cycles so that the latency becomes a smaller portion of the audio processing. I assume the ARM would be similar.

I had a look at the Xmos but I don't think it offers floating point processing which is something I needed at the time otherwise it's a pretty impressive chip ideal for real time systems where you would otherwise use an RTOS. You can get floating point on the Cortex M4 which is handy to have

regards
Trev

Last edited by Trevor White; 22nd March 2012 at 04:21 AM.
  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 04:36 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