Is there any low cost Blackfin ICE/ISP tool?

[technix]

I came across a few sample ADSP-BF532 chips and grabbed them. Now what...? The USB debug adapter, even clones, starts at US$100 even in China. I know that there are open source software tools for that chip. So:

1. How good is OpenOCD support for Blackfin? It is likely my entire chance of using Blackfin will hinge on OpenOCD.
2. Is it possible to hijack another debug probe for Blackfin, like J-Link, ULink2 CMSIS-DAP, or Intel USB Blaster, using OpenOCD?
3. If all above is impossible or difficult, how to find and bootstrap a DIY Blackfin ICE?

[legacy]

Opensource ... well, you can use a FTDI-2232 chip, forcing it to be a "(jtag) programmer" through OpenJtag, but it will be slow and not comfortable: forget to do any debugging seriously and forget to do any profiling. It's too bad for that. It's usually used for uploading the firmware into ram/flash.

Code: [Select]

FT2232H.AD5 --- BFjtag.pin02  EMU
FT2232H.AD3 --- BFjtag.pin06  TMS
FT2232H.AD0 --- BFjtag.pin08  TCK
FT2232H.AC1 --- BFjtag.pin10  TRST
FT2232H.AD1 --- BFjtag.pin12  TDI
FT2232H.AD2 --- BFjtag.pin14  TDO
FT2232H.gnd --- BFjtag.pin04  gnd
dangerous project FT2232 breakout board. Wiring the jtag.

Code: [Select]

       BFjtag
         __
     1 -|..|- 2  emu
     3 -|..|- 4  gnd
     5 -|..|- 6  tms
gnd  7 -|..|- 8  tck
gnd  9 -|..|- 10 /trst
gnd 11 -|..|- 12 tdi
gnd 13 -|..|- 14 tdo
        +--+
Elite-board, jtag connector's pinout

You need to reprogram the EEPROM, making the chip looking like it was a fake-gnICE

Code: [Select]

VID:0x0456 gnICE <------ you need this
PID:0xf000 gnICE <------ you need this


GnICE cable. Original cable. To be "emulated" by dangerous project FT2232 breakout board.

It's cheap, but not so good, and limited to OpenSource: GnICE can't be used with VisualDSP++.

The best *EVER* is VisualDSP++ v5 and its debugger "B1000" cable!

I have a copy of it for Windows XP/32bit, it requires a license, node-locked to the machine. It's the best experience for every professional purpose, it worth the money, and I am 100% satisfied!

A complete kit, based on BF537, i.e. the "Elite-board" + a B1000 cable is still listed at 240 euro (got mine at Farnell). However, since it's going EOL, you may find a discount shot that can be bought for 140 euro.

That is a true bargain if you consider that just the price of the cable is 120 Euro at least.

[technix]

Opensource ... well, you can use a FTDI-2232 chip, forcing it to be a "(jtag) programmer" through OpenJtag, but it will be slow and not comfortable: forget to do any debugging seriously and forget to do any profiling. It's too bad for that. It's usually used for uploading the firmware into ram/flash.

Code: [Select]

FT2232H.AD5 --- BFjtag.pin02  EMU
FT2232H.AD3 --- BFjtag.pin06  TMS
FT2232H.AD0 --- BFjtag.pin08  TCK
FT2232H.AC1 --- BFjtag.pin10  TRST
FT2232H.AD1 --- BFjtag.pin12  TDI
FT2232H.AD2 --- BFjtag.pin14  TDO
FT2232H.gnd --- BFjtag.pin04  gnd
dangerous project FT2232 breakout board. Wiring the jtag.

Code: [Select]

       BFjtag
         __
     1 -|..|- 2  emu
     3 -|..|- 4  gnd
     5 -|..|- 6  tms
gnd  7 -|..|- 8  tck
gnd  9 -|..|- 10 /trst
gnd 11 -|..|- 12 tdi
gnd 13 -|..|- 14 tdo
        +--+
Elite-board, jtag connector's pinout

You need to reprogram the EEPROM, making the chip looking like it was a fake-gnICE

Code: [Select]

VID:0x0456 gnICE <------ you need this
PID:0xf000 gnICE <------ you need this


GnICE cable. Original cable. To be "emulated" by dangerous project FT2232 breakout board.

It's cheap, but not so good, and limited to OpenSource: GnICE can't be used with VisualDSP++.

The best *EVER* is VisualDSP++ v5 and its debugger "B1000" cable!

I have a copy of it for Windows XP/32bit, it requires a license, node-locked to the machine. It's the best experience for every professional purpose, it worth the money, and I am 100% satisfied!

A complete kit, based on BF537, i.e. the "Elite-board" + a B1000 cable is still listed at 240 euro (got mine at Farnell). However, since it's going EOL, you may find a discount shot that can be bought for 140 euro.

That is a true bargain if you consider that just the price of the cable is 120 Euro at least.

This is going back to my "hijacking an existing JTAG probe" idea. What is the software running on top of OpenJTAG? Can it be redirected to use libjaylink and talk to my J-Link clone? Or use a CMSIS-DAP compatible probe like a U-Link 2 clone or the Atmel ICE? Or some other FT2232/FT245 based solution like Intel USB Blaster clone?

[bson]

OpenOCD has no support for Blackfin; it wouldn't even know how to halt the processor, much less flash it or make any use of the debug facilities.

OpenJTAG with gnice supposedly works.  Maybe just get one of those.  https://blackfin.uclinux.org/doku.php?id=hw:jtag:gnice

[legacy]

OpenJTAG with gnice supposedly works

it can only be used to program an external flash/put a binary into ram, through the jtag.
But it's slow, and, as I wrote: forget debugging and profiling.

[bson]

Ah, that's a bummer... I guess AD never released info on its debug support.  That makes it a dead end IMO since you're stuck with their ICE kits and their compiler, apart from uclinux.

[legacy]

I guess AD never released info on its debug support

They sell VisualDSP++, and B1000 cables, that comes with a full support under VisualDSP++ 
Why should they support opensource?

In the CD you find inside the Elite-kit, you find CoNix, that is a sort of VirtualPC made for WindowsXP.
There is also a copy of gcc and binutils, plus patches to make them for Blackfin. But there is no jtag-debugger. The only support is gdb, to be used with ucLinux through a serial cable.

That means nothing professional, it's an educational low cost solution, for those can't buy VisualDSP++ and a B1000 cable.

[technix]

So before I can pony up that $100 those BF532 chips are dead then?

[cstratton]

In the CD you find inside the Elite-kit, you find CoNix, that is a sort of VirtualPC made for WindowsXP.
There is also a copy of gcc and binutils, plus patches to make them for Blackfin. But there is no jtag-debugger. The only support is gdb, to be used with ucLinux through a serial cable.

That means nothing professional, it's an educational low cost solution, for those can't buy VisualDSP++ and a B1000 cable.

That seems to be a substantial mis-characterization of why those are there.  It's not to be a budget alternative, but rather to support running uClinux on the Blackfin, for applications which want to do a lot of "ordinary computer things" (especially with regards to networking or UI) with a little bit of DSP.  In that case, unless you are doing lots of low-level kernel development, you don't need a hardware debugger, just as 99.99% of the time you don't when working on a PC.   Even when writing a custom kernel driver, as I did for some BF537 systems a decade ago, it's not likely going to be of that much help.

In contrast, VisuallDSP is for more DSP-driven applications where traditional computer tasks take a back seat.  And because things like ftp'ing the development build of an application program into the system and running it from ramdisk don't apply there, nor does operating system assisted debugging in user context, you do need the hardware debug adapter for such work.

[legacy]

In contrast, VisuallDSP is for more DSP-driven applications

of course, uclinux on a DSP is more a market way to promote Blackfin.
In my career, I have developed a lot of traditional DSP-driven apps.

[diyaudio]

I came across a few sample ADSP-BF532 chips and grabbed them. Now what...? The USB debug adapter, even clones, starts at US$100 even in China. I know that there are open source software tools for that chip. So:

1. How good is OpenOCD support for Blackfin? It is likely my entire chance of using Blackfin will hinge on OpenOCD.
2. Is it possible to hijack another debug probe for Blackfin, like J-Link, ULink2 CMSIS-DAP, or Intel USB Blaster, using OpenOCD?
3. If all above is impossible or difficult, how to find and bootstrap a DIY Blackfin ICE?

COPY the design from Open DSP ICE kit, look at their HP ADSP ICE-530   

[technix]

I came across a few sample ADSP-BF532 chips and grabbed them. Now what...? The USB debug adapter, even clones, starts at US$100 even in China. I know that there are open source software tools for that chip. So:

1. How good is OpenOCD support for Blackfin? It is likely my entire chance of using Blackfin will hinge on OpenOCD.
2. Is it possible to hijack another debug probe for Blackfin, like J-Link, ULink2 CMSIS-DAP, or Intel USB Blaster, using OpenOCD?
3. If all above is impossible or difficult, how to find and bootstrap a DIY Blackfin ICE?

COPY the design from Open DSP ICE kit, look at their HP ADSP ICE-530   

I only found sales links and they costs US$500+. Not helping...

[technix]

OpenADSP has full line of ADI JTAG controller clones.

Those are even more expensive than the genuine ones here in China.

[technix]

I have a second ICE1000 lying around, PM me your offer if you want it. The Kaneko BF706 can be included for free. It was modified to tap power directly from USB port. I used this board to develop my BlackFin+ USB Audio Class 2.0 driver stack.



It was previous blown up (ESD circuitry and level shifters) and repaired. It works now.

Its 14P connector has been removed and its 10P connector has been removed and replaced with 0.05" ribbon cable with an IDC connector.
The pinout is for Kaneko System's mini 706 and mini 707 boards.

Its MiniUSB port has been modified with MicroUSB port.

Even though I definitely wish to make an offer, either I would still not be able to afford it, or the price would be so low-ball you wouldn't be able to accept it. I wouldn't want to leave a sour taste in your mouth after this. Please tell me you are ready to brace yourself for some shocking offers, or I would have to put this case to rest for now. The ICE-1000 does look like a nifty little unit though.

Also even if I bought your spare unit, I would still need to mod its target connectors back to stock. The microUSB connector is a nice mod though, and I am even hoping to perform this on my PICkit and ST-Link. I am interested in finding out why the output protection circuit got blown up. What happened?

[legacy]

Consider you also need VisualDSP++/v5.*, that requires Windows XP/32bit.

[technix]

Consider you also need VisualDSP++/v5.*, that requires Windows XP/32bit.

Just throw it into a virtual machine.

[technix]

I am interested in finding out why the output protection circuit got blown up. What happened?

Incorrect vbus connection blew up DSP, DSP blew up debugger.

Sorry to hear that... That must have been an expensive accident. For me the most chip I have blown up so far is a $7 STM32.

It is actually kind of a tight month for me financially since I just paid for my next year of Apple Developer Program subscription. Sorry for that ruining a potential deal, and I do understand that if I want to get into ADSP again I will likely have to pay at least US$200 for a new kit.

BTW, what is the development kit for the SigmaDSP line like ADAU1701 or ADAU1761? I have a Bluetooth Hi-Fi project that uses that ADAU1761 DSP in place of the I2S codec, with the intention of implementing some software-defined filtering and equalizing, nulling out the imperfect response of the analog front end and the headphone.

[ntfreak]

For info Blackfin support in OpenOCD support is not in mainline but is being worked on and available - http://openocd.zylin.com/4168/

[laugensalm]

Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.

[bson]

For info Blackfin support in OpenOCD support is not in mainline but is being worked on and available - http://openocd.zylin.com/4168/

Nice! 

When will it show up in git@github.com:ntfreak/openocd.git ?
That's what I sync my fork to (git@github.com:bson/openocd.git), just to add RTOS support for my own obscure bare-metal runtime (enetcore).

Ah, I see it's not in master yet, just in a tarball available from... AD!  Is this stuff in a branch yet?

[technix]

For info Blackfin support in OpenOCD support is not in mainline but is being worked on and available - http://openocd.zylin.com/4168/

Nice! 

When will it show up in git@github.com:ntfreak/openocd.git ?
That's what I sync my fork to (git@github.com:bson/openocd.git), just to add RTOS support for my own obscure bare-metal runtime (enetcore).

Ah, I see it's not in master yet, just in a tarball available from... AD!  Is this stuff in a branch yet?

I think it will likely take a while before it can be merged, since ADI is simply dropping a code blob passively, instead of assigning engineers into actively integrating that code blob into mainline.

[rsjsouza]

Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.

I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line. 

[technix]

Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.

I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.

For me I have some audio based projects in mind that might need dedicated digital signal processors.

[rsjsouza]

Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.

I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.

For me I have some audio based projects in mind that might need dedicated digital signal processors.

Yes, you are using the correct tool for the job. True DSPs are unbeatable for signal processing.

If you are still looking for options, I am very familiar with the C674x family of floating point DSPs, where you can start for somewhat less money: the C6748 LCDK is $195.00, but the advantage is that it can be programmed with a cheaper FTDI-based XDS100v2 (clones everywhere) or a bit faster XDS110 (there is the official version and a clone called XDS110Lite). The mainstream IDE (Code Composer Studio) still actively supports it and costs nothing. There is even a SDK still supported.

[technix]

Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.

I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.

For me I have some audio based projects in mind that might need dedicated digital signal processors.

Yes, you are using the correct tool for the job. True DSPs are unbeatable for signal processing.

If you are still looking for options, I am very familiar with the C674x family of floating point DSPs, where you can start for somewhat less money: the C6748 LCDK is $195.00, but the advantage is that it can be programmed with a cheaper FTDI-based XDS100v2 (clones everywhere) or a bit faster XDS110 (there is the official version and a clone called XDS110Lite). The mainstream IDE (Code Composer Studio) still actively supports it and costs nothing. There is even a SDK still supported.

I do have a few sample chips of TMS320VC5509A. Older series than C674x but should work reasonably well.

I still would like to keep my options open though. For the current audio processing workload I am evaluating five options:
* Blackfin (ADSP-BF531)
* SigmaDSP (ADAU1761)
* TMS320C55xx series (TMS320VC5509A)
* Cortex-M4F (STM32F405RGT6)
* Cortex-M7F (STM32F722RET6)

[rsjsouza]

Funny, that this topic still comes up every few years. Unfortunately, Analog Devices has run puzzling strategies with their tools, eventually, it seems they left the OpenSource stuff orphaned. The irony is, that the old VDSP very much bases on an old GCC port (yes indeed, ADI never much cared about GPL).
You might find some old distributions of the ICEbear (classic) JTAG software (bfemu/gdbproxy) that work with any FT2232 adapter (if you try hard enough).
On a side note: the ICEbearPlus JTAG is still available, but not 'low cost' in the sense of 'below 100 USD', and support for HW debugging is stripped (flash programming only).
Other than that, fully functional gcc distributions are still maintained and perform (IMHO) better than the mutilated ELF VDSP++ variants.

I think that pure Digital Signal Processors started their sunset at the same time the opensource was being adopted by big semi manufacturers in the mid 2000s. Nowadays there is a variety of offers, with AD more or less stuck in the past, NXP and TI having moved forward in certain spots of their product line.

For me I have some audio based projects in mind that might need dedicated digital signal processors.

Yes, you are using the correct tool for the job. True DSPs are unbeatable for signal processing.

If you are still looking for options, I am very familiar with the C674x family of floating point DSPs, where you can start for somewhat less money: the C6748 LCDK is $195.00, but the advantage is that it can be programmed with a cheaper FTDI-based XDS100v2 (clones everywhere) or a bit faster XDS110 (there is the official version and a clone called XDS110Lite). The mainstream IDE (Code Composer Studio) still actively supports it and costs nothing. There is even a SDK still supported.

I do have a few sample chips of TMS320VC5509A. Older series than C674x but should work reasonably well.

I still would like to keep my options open though. For the current audio processing workload I am evaluating five options:
* Blackfin (ADSP-BF531)
* SigmaDSP (ADAU1761)
* TMS320C55xx series (TMS320VC5509A)
* Cortex-M4F (STM32F405RGT6)
* Cortex-M7F (STM32F722RET6)

Ah, the VC5509 is an old friend... I used it several years ago and, despite it has half of the BF531 clock speed, it has some interesting peripherals such as SD card and USB slave - all suited to the MP3 players of yore. Perhaps the old audio libraries are still available on ti.com.

The nice thing is that it is still supported by the same tools I mentioned before - although with the newer versions of the IDE it requires a bit more effort to build the ancient example projects.

The Cortex Ms are very tempting due to the modern support and low cost tools, but if you need serious filtering the DSPs will be a better option. Actually, depending on what you need, the options above may not be even enough to get the job done. However, we have to make the best with what we have.

One additional detail I forgot to mention is that there is a version of the C6748 DSP I mentioned before with an ARM9 core in it - useful to run full Linux (not uCLinux). The benefit is they are pin to pin compatible.

[technix]

Ah, the VC5509 is an old friend... I used it several years ago and, despite it has half of the BF531 clock speed, it has some interesting peripherals such as SD card and USB slave - all suited to the MP3 players of yore. Perhaps the old audio libraries are still available on ti.com.

This actually makes it an interesting option for a standalone DSP project, instead of being part of a MCU-controlled system.

The nice thing is that it is still supported by the same tools I mentioned before - although with the newer versions of the IDE it requires a bit more effort to build the ancient example projects.

As long as it works with the free CCS 6.2, I am okay with a bit of digging in the setup. I dug my own ARM toolchain anyway.

The Cortex Ms are very tempting due to the modern support and low cost tools, but if you need serious filtering the DSPs will be a better option. Actually, depending on what you need, the options above may not be even enough to get the job done. However, we have to make the best with what we have.

So what kind of DSP do I need if I want to do serious filtering? At what sample rate and word size you are talking about?

One additional detail I forgot to mention is that there is a version of the C6748 DSP I mentioned before with an ARM9 core in it - useful to run full Linux (not uCLinux). The benefit is they are pin to pin compatible.

I have found that - part of OMAP line. I am not yet ready to design my own boards with big BGA packages like that now though.

[bson]

The Cortex Ms are very tempting due to the modern support and low cost tools, but if you need serious filtering the DSPs will be a better option.

For audio I'm sure the CM4/CM7 will do perfectly fine with their fixed-point SIMD instructions - and he gets a competent application processor with many excellent sources and varieties to boot.  Unless it's going to be doing something unusually complex.

[rsjsouza]

The Cortex Ms are very tempting due to the modern support and low cost tools, but if you need serious filtering the DSPs will be a better option. Actually, depending on what you need, the options above may not be even enough to get the job done. However, we have to make the best with what we have.

So what kind of DSP do I need if I want to do serious filtering? At what sample rate and word size you are talking about?

For regular stereo 14 or 16-bit audio from 22 to 44.1kHz, the fixed point options you are considering where quite enough for a number of filters and effects. I can't precisely recall all the nitty gritty details, but IIRC I was able to add five-six band equalizer with room for echo, chorus and reverb, but there was a tradeoff between the equalizer bands, the effects depth and the auxiliary functions (USB, SD card, etc.). The BIOS RTOS helped a lot balancing these tradeoffs - adding or removing functions (threads) was easy.

BTW, I found some of the libraries for this device - here

One additional detail I forgot to mention is that there is a version of the C6748 DSP I mentioned before with an ARM9 core in it - useful to run full Linux (not uCLinux). The benefit is they are pin to pin compatible.

I have found that - part of OMAP line. I am not yet ready to design my own boards with big BGA packages like that now though.

Yeah, I forgot that. The BGA is the Achilles' heal of these more advanced processors.

For audio I'm sure the CM4/CM7 will do perfectly fine with their fixed-point SIMD instructions - and he gets a competent application processor with many excellent sources and varieties to boot.  Unless it's going to be doing something unusually complex.

bson, talking "For Audio" is too generic of a statement - the level of complexity can increase quickly depending on what you want to achieve, from a simple lowpass filter to an adaptive echo cancellation, plethora of effects, multichannel, high sample rate...

I've considered this path for DSP effect, interpolation and sigma delta modulation for my from-scratch sigma delta DAC project, and the result is DSP is better.
CM7 is great, but not as good as BlackFin+, even when processing 32-bit values. CM7 is better than classic BlackFin DSPs when dealing with 32-bit MACs since the old chips don't have single cycle 32*32+72 support.

Most CM7 don't run at 400MHz frequency like those BlackFin chips (spare iMXRT and 416MHz STM32), and they don't have modulus addressing mode, which is a big set back for FIT filters. Also, they don't have bit reversal addressing mode, which is offered in BlackFin DAG.

My experience with Cortex cores is very similar. Although Cortex cores can scale much better (a Cortex A can go much higher in speed), much of the raw performance gained in MAC speed is reduced when trying to resolve the more complex addressing modes.

I've also evaluated TI parts, but TI single chip DSP parts (not those needing an external RAM) don't have high speed USB, which is crucial to me.

Did you evaluate C2000 DSPs? They would be quite slower in performance.

[bson]

bson, talking "For Audio" is too generic of a statement - the level of complexity can increase quickly depending on what you want to achieve, from a simple lowpass filter to an adaptive echo cancellation, plethora of effects, multichannel, high sample rate...

Yeah, and when I wrote that post it was initially much longer, but I removed all the qualifiers and excess information.  Clearly a 400MHz DSP is going to be a more capable signal processor than, perhaps effectively, an 80MHz CM7.  But an FPGA is going to be more capable than a DSP... so... it's really more about weighing computational complexity vs gun caliber.  Which of course only states the obvious so isn't particularly meaningful.

[technix]

bson, talking "For Audio" is too generic of a statement - the level of complexity can increase quickly depending on what you want to achieve, from a simple lowpass filter to an adaptive echo cancellation, plethora of effects, multichannel, high sample rate...

Yeah, and when I wrote that post it was initially much longer, but I removed all the qualifiers and excess information.  Clearly a 400MHz DSP is going to be a more capable signal processor than, perhaps effectively, an 80MHz CM7.  But an FPGA is going to be more capable than a DSP... so... it's really more about weighing computational complexity vs gun caliber.  Which of course only states the obvious so isn't particularly meaningful.

The CM7 I was looking at (STM32F722RET6) runs at 216MHz and the CM4 (STM32F405RGT6) runs at 168MHz. I don't know if this makes any difference when comparing to the DSP's.

Among the DSP's, how good are those SigmaDSP parts like ADAU1761 and ADAU1701?

[bson]

The CM7 I was looking at (STM32F722RET6) runs at 216MHz and the CM4 (STM32F405RGT6) runs at 168MHz.

Perhaps he left a zero.

No, I didn't; these devices don't have an L1 cache (though it's optional on the CM7, not sure if ST offers one?) so unless you execute out of SRAM the simple read-ahead single row flash accelerators used are not going to keep up and there will be wait states.

[bson]

No chip will perform well if the data set and coeff set are not stored in L1/L2/TCM.

Well, hence my downrating. 

[bson]

Looks like the STM32F7x2 does have the L1 cache though.  That should make a difference.

[technix]

The CM7 I was looking at (STM32F722RET6) runs at 216MHz and the CM4 (STM32F405RGT6) runs at 168MHz.

Perhaps he left a zero.

No, I didn't; these devices don't have an L1 cache (though it's optional on the CM7, not sure if ST offers one?) so unless you execute out of SRAM the simple read-ahead single row flash accelerators used are not going to keep up and there will be wait states.

The STM32F722RE chip has L1 code and data cache, as well as 1-cycle SRAM access.

[rsjsouza]

Similar story with the TMS320VC5509A: it does not have cache, but it has both single and dual access single-cycle internal SRAM. These memory banks can be banded together with the DMA channels to transfer data in and out of the device (external SDRAM, serial ports) without wait states from the CPU perspective.

A curiosity about the Flash-based CM cores mentioned: do they run single cycle? If Wikipedia is correct, only the M7 has a possibility of having cache and none has TCM. In this case, the partitioning of the system would require critical code to be in SRAM instead of Flash.

For the VC5509A is a bit of a similar thing: since the device has no Flash, the code and constant data must be copied to the single access SRAM at boot time but, once it is there, everything is single cycle. You would use the dual access SRAM for data.

[technix]

A curiosity about the Flash-based CM cores mentioned: do they run single cycle? If Wikipedia is correct, only the M7 has a possibility of having cache and none has TCM. In this case, the partitioning of the system would require critical code to be in SRAM instead of Flash.

AFAIK:

STM32F405RG:
* 64kB of data-only TCM that is not accessible by either DMA or instruction fetch
* 128kB of standard SRAM
* both TCM and SRAM can run single cycle.

STM32F722RE:
* 64kB of data TCM that cannot fetch instructions but can be accessed by DMA
* 16kB of instruction TCM that is not accessible by DMA
* 192kB of standard SRAM
* Memory-mapped QSPI interface
* 8kB instruction cache, 8kB data cache, both applies when instruction and data access from Flash through its AXIM address space, from standard SRAM or memory-mapped QSPI.
* TCM, SRAM and cache all run single cycle.