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.

Relationships between DSP/BIOS, CSLs, and device drivers

We are using the C6455 DSP in our design with DSP/BIOS 5.31 and CCS 3.3.  This development environment is new to me and I am a little perplexed about the relationship between DSP/BIOS, Chip Support Libraries, and Device Drivers.

In our system design, we will have external DDR2 memory, interconnects that will use the UTOPIA2 and HPI interfaces, and we will need to use the DMA controller.  What is the best way to initialize and use these peripherals (DDR2 Memory Controller, UTOPIA, HPI, and DMA controller) - CSL or developing drivers?

In the CSL download for the C6455, I see lib files (csl_c6455.lib and csl_c6455e.lib) and code examples for the peripherals in question.  However, in the DSP/BIOS documentation, I see references to developing device drivers to connect to peripherals.  What is preferred method to access the on chip peripherals - the CSL functions, or device drivers?  Are device drivers for these peripherals availble from TI?

Are the CSL functions compatible with DSP/BIOS?  Do I simply link in the library file with the application?

I downloaded the Driver's Developer Kit from TI (SPRC118) but it appears targeted for CCS 2.x and will not install.  Is there an update for the DDK for CCS3.x?

Another question - what is the meaning of the "e" suffix of the csl_6455e.lib?

Sorry for all the questions - I appreciate any advice or help!

  •  

    For C6455, you can use the CSL - Chip Support Library. Some of our DSPs have a PSP - Platform Support Package that uses DSP/BIOS drivers.

    You can download CSL for C6455:

    http://focus.ti.com/docs/toolsw/folders/print/sprc234.html

    After downloading CSL, you can go to the folder:

    ....\6455_default_package\default_package\csl_c6455\example

    And find examples of projects using CSL there. You need to add the lib file to your project and include header files (.h) when needed - the examples do that.

    You can use CSL with DSP/BIOS. If are going to use an example as a stating point, just make sure to adapt from INTC to BIOS (in case the examples is Intc based). Please look at the article:

    http://tiexpressdsp.com/wiki/index.php?title=Converting_from_INTC_to_BIOS

    The suffix "e" at the end means big endian - without the "e" is little endian.

     

     

  • In regards to the DDK:

    You care correct, the last DDK release was targeted for CCS 2.x and was made several years ago (circa 2003 or 2004). There have been no updates and is not actively supported.

    Harry

  • It looks like Mariana and Harry have answered most of your questions. I thought I'd just elaborate a bit more on Harry's answer to your DDK question.

    As Harry stated, the DDK (Driver Developer Kit) was oriented towards the devices that came before the C6455. Much of the code used to build the example drivers in the DDK utilized CSL version 2.x.

    Today, most of TI's new devices are provided with drivers. These are usually packaged in something called the PSP (Platform Support Package), as opposed to the DDK. Again, some of these drivers utilize the lower-level code found in our version 3.x Chip Support Library (CSL).

    Unfortunately, the C6455 devices were released during the transition period between these two software packages. And, resources being what they are, the drivers made for later devices (C6437, DM648, etc.) were never back-ported to the C6455. Many of our customers have written their own drivers based on the CSL 3.x (register layer) code. The 4-day C6455 Integration Workshop provides a good introduction towards this (see http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=4DW102645).

    One interesting item to note, though, is that even though our driver implementation strategy (i.e. packaging) changed, as noted above, the driver interface remained consistent. BIOS 5.x provided a consistent user interface to both the application and driver authors. I won't dwell on the details here, as they're well documented elsewhere, but wanted to point that it wasn't the API's that changed. Rather, it was more of a change in who (within TI) and how the drivers were packaged.

    In summary, BIOS, Drivers, and CSL work well together.
    • CSL provides a library of low-level symbolic defines (i.e. #defines) and functions that can be used to access the chip's hardware/peripheral registers.
    • BIOS provides a set of real-time O/S services. These services range from memory allocation/management, to scheduling, to instrumentation, and so on. BIOS also defines a set of driver interfaces; for example, the application programmer might choose to use the BIOS Streaming I/O (SIO) interface which provides a common peripheral independent means of talking to a device. On the other side of this, BIOS defines the I/O Minidriver (IOM) interface for driver authors. Using IOM, you can author a driver that can bolt into any application that supports BIOS drivers - that is, if your driver conforms to IOM, anyone who uses SIO can use your driver.
    • So, BIOS defines the driver interfaces. And, CSL provides a set of low-level hardware access routines and macros. The driver author can leverage both of these to provide the higher-level set of services we often associate with "drivers". For most peripherals, on most devices, TI provides a set of example drivers that you can use - or start with; though, there are a few devices that aren't as fully supported with example drivers.
  • Thank you for your responses!  I've looked at the CSL and the examples in the CSL for the 6455, and it looks like they will very helpful in bringing me up to speed.  The exercise in converting from the INTC model to the DSP/BIOS HWI model will be very helpful - I will tackle that this morning.

    I am planning to use both DSP/BIOS and the CSL for our system.  Along the way I hope to learn more about the Minidriver interface and see if that may be something I can work towards for the future.