• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 738 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DSP/BIOS 6 + CSL + DSPLIB?

Jerry46091
Intellectual 320 points
Other Parts Discussed in Thread: TMS320C6455, SYSBIOS

Hello everybody,

I'm using a TCI6482 / TMS320C6455.

I'd like to use DSP/BIOS 6 together with the functionality provided by CSL and the DSP Library (DSPLIB). I've read through the DSP/BIOS 6 User's Guide (SPRUEX3D). All I could find about CSL and DSP/BIOS 6 compatibility was this note:

"The most recent releases of CSL (3.0 or above) are designed for use in applications that do not use DSP/BIOS. Some of their services are not compatible with DSP/BIOS. Usage of CSL interrupt, cache, and timer functions and DSP/BIOS in the same application should be avoided since this combination is known to result in  complex interrupt-related debugging problems."

Does this mean I should not use CSL at all with DSP/BIOS 6? What if I want to use CSL's APIs for on-chip peripherals such as the Viterbi coprocessor (VCP) or the Turbo coprocessor (TCP)?

What about using DSPLIB? Can I call its APIs, such as the FFT APIs, within a DSP/BIOS 6 task/Swi/Hwi and be safe not to destruct the DSP/BIOS 6 environment?

Unfortunately, the current TI documentation body does not provide for information about how libraries such as CSL and DSPLIB interfere with each other and how they interfere with DSP/BIOS. For example, which on-chip peripherals/resources does DSP/BIOS 6 claim? I cannot tell if any additional libraries (CSL, DSPLIB) interfere destructively with the DSP/BIOS 6 environment.

 

Thanks for your suggestions!

Jerry

  • 0
    TI__Guru*** 125430 points

    Using CSL for Viterbi, etc should be fine.  Avoid doing anything with interrupts, cache, or timer using the CSL as mentioned by the note.

    DSPLIB is no problem.  Those functions do not interact with hardware and since they are all non-blocking calls they are safe to use from any thread context.

  • 0 in reply to Brad Griffis
    Intellectual 320 points

    Is there an authoritative list about which DSP/BIOS 6 modules allocate which hardware peripheral?

    For instance, I have configured DSP/BIOS 6 statically such that tasks, SWIs and clocks are enabled (using BIOS.taskEnabled = Bool true; BIOS.swiEnabled = Bool true; and BIOS.clockEnabled = Bool true;). I guess that this causes to allocate (at least) one of the timer peripherals for thread preemption. Yet I don't know which timer happens to be used for this. Also, I don't know if Timer0 or Timer1 is used, or if these timers are used in 32-bit mode or 64-bit mode.

    I had a look in the cdoc API reference. Neither the ti.sysbios.hal.Timer nor the ti.sysbios.timers.timer64.Timer API reference say something about which timer is used and how it is configured.

    Does anyone have an idea where to find such information?

    Thanks for your help,

    Jerry

  • 0 in reply to Jerry46091
    TI__Mastermind 32475 points

    Jerry,

    There is no authoritative list about which DSP/BIOS 6 modules allocate which hardware periphals right now.

    If you've done a 'BIOS.clockEnabled' you're correct in stating that this will cause one of the timer peripherals to be allocated.  By default, the Clock uses the first available Timer which is Timer0.  By default, the Timer is setup for 32-bit unchained mode and the Lower half is used.  The default Timer mode and half that is used is part of the ti/sysbios/timers/timer64/Timer cdoc documentation.

    Having said all that, you can actually choose which Timer you want the Clock module to use by doing a 'Clock.timerId = 1'.  This will use Timer 1 instead of Timer 0.  Furthermore, you can change the defaults for the Timer also.

    During runtime, you can also use ROV to determine which Timer is currently in use.

    Hope that helps!

    Judah