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 ?

__________________“A new scientific truth does not triumph by convincing its opponents ... but rather because its opponents eventually die, and a new generation grows up that is familiar with it.” - Max Planck

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

__________________“A new scientific truth does not triumph by convincing its opponents ... but rather because its opponents eventually die, and a new generation grows up that is familiar with it.” - Max Planck

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 !!

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

__________________“A new scientific truth does not triumph by convincing its opponents ... but rather because its opponents eventually die, and a new generation grows up that is familiar with it.” - Max Planck

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.

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