ADSP-BF706
Production
This device is a member of the ADSP-BF70x Blackfin Digital Signal Processor (DSP) product family. The new Blackfin+ processor core combines dual-MAC 16...
Datasheet
ADSP-BF706 on Analog.com
I have an audio in-out program in C for the ADSP-BF706 EZ-KIT mini, about 80 lines in length. It's simple and very easy to understand. It's also completely self-contained - it doesn't use any of the header files that the "TalkThrough_BF706Mini.c" program uses (supplied with the kit). It includes a basic TWI driver, SPORT0 set up and configuration routine for the on board codec (ADAU1761). With some simple modifications it can be used for filtering, both FIR and IIR. The file is attached. All welcome to use free.
PatrickG
Hello Patrick,
your program for the BF706 EZ-Kit Lite is very useful, very clear and it works fine!
I have written a DMA and interrupt driven version to avoid polling.
This could be a first step to block in-out. The attached file is also free software.
UweS
Thanks Uwes! I am also writing some code for DMA block in-out. At the moment I am focusing on assembly, since that seems to give the best speed. However, I want to do a comparison between filtering in C and assembly - my C code at the moment gives about 1500 taps for an FIR, but I can get 13000 for an assembly version. Must be doing something wrong.
Hallo Patrick,
my BF706 audio filter program has a bug. The lines
if (*pREG_DMA1_STAT & ENUM_DMA_STAT_IRQDONE)
*pREG_DMA1_STAT = ENUM_DMA_STAT_IRQDONE;
are missing in the SPORT0_RX_interrupt_handler.
Maybe this is useful for the development of your own DMA interrupt software.
The attached version BF706_Audio_Filter_v2 should be correct.
Best regards
Uwe
Hi Patrick,
it seems your program (and my version of it) does not run in
release mode. I guess the delay loops in write_TWI are getting
too short or are removed completely by the compiler in release mode.
The attached version Audio_Filter_v3 has new delay loops.
Debug mode could also explain the poor results for the FIR filters in C.
Regards
Uwe
Hi UweS,
Yes, I forgot to mention that CCES in debug mode automatically sets the PLL clocks to maximum (not mentioned in the literature). The FIR code that I wrote (in assembly), which could handle over 8000 32-bit coefficients (around 13500 for 16-bit) would not work from boot up. Once I had set the clocks explicitly in the code, it worked fine. Here is the code to max the speed:
// Set the clocks to maximum
R1=0X2000;
[REG_CGU0_CTL]=R1;
R1=0X42042442;
[REG_CGU0_DIV]=R1;