Using CSL and DSP/BIOS on the 5515

I want to use the CSL and DSP BIOS. I have them compiling and running together succefully on a very simple tasking program. There is no indication of what I can and cant do with the CSL... I would assume that I can use all the register setting macros, functional set up code such as setting up peripherals.

 

Once the peripheral is set up, I believe that I could use the CSL to enable and disable specific interrupt flags etc, but NOT to set up an interrupt vector using the CSL but the DSP/BIOS configurator.

 

Suprisingly there are NO examples of this that I could find!!

 

 

 

 

  • Hi Michael,

    you are correct, there aren't very many examples for the C5515, plus its a very old device..

    Here's a link to the DDK (Driver Developer Kit) for DSP/BIOS. It has examples that use the C5515 including how to use HWI's to create drivers, but I don't know if its leveraging a CSL API calls.

    I don't know if the CSL you're using was intended to be used with DSP/BIOS, but if you are going to use BIOS, you want to use HWI module APIs. Generally, BIOS isn't familiar with its peripherals therefore you can use the CSL to control the peripherals which could include enabling, disabling, reading, and clearing the peripheral and its associated interrupts.

  • In reply to Tom Kopriva:

    Hell Tom , thank for the respone!! I did find that the connected audio framework does utilize both and is a complicated but good example. The one issue with it is that the author decided to abstract some of the hardware into drivers, some of the dsp bios api making it complex. confusiing...... this example also has the dsp libs in it, so it really is a full example.

     

    Th example does have a copy of the CSL source , so it is using its own "frozen version" which may be stale by now.. not sure what the revision is.

    It is amazing how each each ezdsp application set uses its own csl, mostly incomplete for examples.....

     

    Should I be using the 553X family, I believe that to be the newre family.. I am only interested in having USB for firmware upgrade, not streaming audio.... I will talk to avnet about that.

    I am architectin the system currently, my main goal is low power.... I basically need to grab 8 stereo samples, run them through a processing graph (calling dsp lib functions mostly) and put that into an 8 sample output buffer..... I do not know at this time the best DSP BIOS architecture, is it a pip or is it fire off a semaphore to process the audio in a task..

     

    I do have User Interface functions to perform including updating biquad coefficients based on user input handled in a user interface task(s).

    I am also not sure of the power tradeoff between using the DMA and queing in the interrupt, I would guess that if the buffer were bigger, the processor could "sleep" between buffer operations, but is that practicle?? (depends on how many cycles i use between buffer fulls....).

     

    Any insite would be greatly appreciated. I am working through avnet and TI in chicago so have contacts here.

     

     

     

     

     

     

  • In reply to Michael Garrett:

    Hi Michael,

    Some answers for you...

    Michael Garrett
    Th example does have a copy of the CSL source , so it is using its own "frozen version" which may be stale by now.. not sure what the revision is.

    I will find out which CSL version is included with the Connected Audio Framework.

    Michael Garrett
    Should I be using the 553X family, I believe that to be the newre family.. I am only interested in having USB for firmware upgrade, not streaming audio.... I will talk to avnet about that.

    The C553X family is the latest, lowest power, and cheapest member of the C55xx family, but it is functionally similar to the C5515 family and C5505 family (without EMIF). USB boot is available for the C5535/34/33 devices for firmware upgrade. But the C5535 devices search for boot code in a fixed order and USB is checked last in the boot order - may need to prevent the normal boot source from booting to boot into USB or include USB code in the normal boot program.

    C5535 eZdsp development board: http://www.ti.com/tool/tmdx5535ezdsp

    Michael Garrett
    I am architectin the system currently, my main goal is low power.... I basically need to grab 8 stereo samples, run them through a processing graph (calling dsp lib functions mostly) and put that into an 8 sample output buffer..... I do not know at this time the best DSP BIOS architecture, is it a pip or is it fire off a semaphore to process the audio in a task..

    Are you capturing 8 samples in parallel? Or a sequence of 8 samples in serial? The C553x has 4 stereo, full-duplex I2S ports.

    See these DSP/BIOS resources:

    http://www.ti.com/tool/dspbios

    http://processors.wiki.ti.com/index.php?title=Category:DSPBIOS

    Michael Garrett
    I am also not sure of the power tradeoff between using the DMA and queing in the interrupt, I would guess that if the buffer were bigger, the processor could "sleep" between buffer operations, but is that practicle?? (depends on how many cycles i use between buffer fulls....).

    DMA allows for the CPU to process other tasks during data transfer instead of performing the data transfer. You are correct that the bigger the buffer, the longer time between processing, the longer time spent in the idle state, usually lower power.

    Hope this helps,
    Mark

  • In reply to Mark Mckeown:

    Hi Michael,

    I found out that the CSL used in the C55_Connected_Audio_Framework_ALL-01.52.01.00 and older are based on TMS320C55XXCSL-LOWPWR-2.50.00.00, v2.50.00.00, 6 July 2011.

    But the USB files have been tailored for the Connected Audio Framework. Run a compare on the two CSL directories and you will see differences in the following files:

    src\csl_audioClass.c
    src\csl_usb.c
    inc\csl_audioClass.h
    inc\csl_audioClassAux.h
    inc\csl_csl_general.h
    inc\csl_usb.h
    inc\csl_usbAux.h
    inc\cslr_usb.h

    Best Regards,
    Mark

  • In reply to Mark Mckeown:

    Thanks for the feedback, I was able to get the BIOS, CSL and DSP Library all working. I have made headway on modifying the iir32 filter to take and pass 32 bit data, and am now looking for a float to Q31 number. I not found anything, other than modifying the fltoq15 in the dsp lib... did not really want to do that....sequence of 8 samples from the each of two channels. My starting point is a high dynamic range 4 band parameteric equalizer.. plus some added effects etc. I am trying to keep the latency low, which is the 8 sample buffers for a total delay of 16 samples per channel... could go to 32 samples per channel for a total dealy of 64 samples, at 48 k would be 1.3 msec, not noticable..this would be the lowest dealy, adding any other effects that utilizize history would add to that....

    Thanks,

    Do know where there is a float  to Q32 function for the 55X?

    Michael

     

     

  • In reply to Tom Kopriva:

    Hi Tom,

    If you state that c5515 is VERY OLD DEVICE - what is the replacement for it - we nead device with EMIF in c55xx series.

    Thank a lot for your advice,

    Rubby

  • In reply to RUBBI:

    Hi Rubby,

    I'm not sure what the exact replacement for the 5515 is or how old/outdated it is, but I do know that C55x devices are still actively supported in DSP/BIOS 5.x.

    Some quick hunting on www.ti.com led me to this page, which may be helpful to you:

    http://www.ti.com/dsp/docs/dspswandtools.tsp?sectionId=2&familyId=114&toolTypeId=1&tabId=2813

    Steve

  • In reply to Steven Connell:

    Hi Steve,

    My only problem in this thread was with statement that c5515 is VERY OLD DEVICE. We are looking for device with long time availability and such statement can mean that TI is looking for its discontinuing.

    Rubbi

  • In reply to RUBBI:

    Rubbi,

    I don't think you need to worry about this comment.  The C5000 has been and continues to be actively supported on DSP/BIOS.  We make DSP/BIOS releases approximately every few months in order to fix bugs and continue support.  This should continue for the foreseeable future.

    Steve

  • In reply to Steven Connell:

    Steve,

    Thanks for your clarifications,

    Rubby