• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 324 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.

How to write a board support library using SysBios 6 which will coexist with customer application

Geraldine Maclear
Expert 2145 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

We will develop a library with support functions to run on Core0 of each of two C6670 parts on a new board which is being developed. A customer buying this board will write their own application to run on the board, using our library. We have questions about how our library (called DSP_lib) will coexist with the customer’s application (called customer_app).

DSP_lib will use sysBios (bios_6_33_04_39).

If we create a new CCS (5.3.0) project which is a static lib and a “sysBios Typical” configuration, we get a library with a RTSC component and its own .cfg file which has a BIOS.heapSize setting and a Program.stack setting.  Similarly our DSP_lib has its own .cfg file.

DSP_lib links in a platform library which is based on the example in C:\TI_MCSDK\pdk_C6670_1_1_0_3\packages\ti\platform and is customized for our board.

A section of 16MB at the start of the DDR3 memory on our board will be reserved for the use of DSP_lib.

We have several questions regarding the development of DSP_lib and the restrictions which must apply to customer_app if it uses DSP_lib:

1)  Can DSP_lib and customer_app both link to the platform library? They will both need access to peripherals on the board.

2) If DSP_lib and customer_app both link to the platform library, which project is responsible for putting the platform library into memory such as L2SRAM?

3) Will DSP_lib and customer_app both have .cfg files which are used? Or will the customer_app .cfg file be the only one which has an effect? If both .cfg files are used, could they interfere with each other?

4) Can DSP_lib be configured so that all SysBios functionality which it uses will use memory from the 16MB of DDR3 memory which is reserved for DSP_lib?

5) Can customer_app be configured so that all SysBios functionality which it uses will use memory from outside of the 16MB of DDR3 memory which is reserved for DSP_lib?

6) Should DSP_lib configure and use its own separate heap?

7) Is it correct that DSP_lib should not have its own main() function?

8) Will customer_app have to use the same version of sysBios (bios_6_33_04_39) as DSP_lib?

Thanks for your help,
Geraldine

Edit: For completeness I'm adding a link to a related post for another issue we need to resolve for this project:

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/253381/898598.aspx#898598

  • 0
    Expert 2145 points

    Additional question:

    9) If Task 2 is created from inside Task 1, where will Task 2's stack be placed in memory?

  • 0 in reply to Geraldine Maclear
    TI__Mastermind 20805 points

    Hi Geraldine --

    Your library build does not actually use a .cfg file.   The .cfg file is used for the final applications.   Final application uses a single .cfg file and can link many libraries, including your DSP library.

    Looking at the CCS project options, I can see how this is confusing.  The "Static Library" option for a SYS/BIOS project isn't well developed and looks like it has some gaps.

    The .cfg file should not be necessary when building the static library.   I tried to remove the .cfg from the RTSC static library project but couldn't.  You can leave it in there to keep the build happy, but the .cfg file is not really used by the library.

    I filed a bug report asking that the CCS project manager allow a  RTSC static library project without requiring the .cfg file -- SDSCM00046952.

    1)  Can DSP_lib and customer_app both link to the platform library? They will both need access to peripherals on the board.

    Yes if you make your DSP library a separate library.  The .cfg file isn't archived in the library itself.   The .cfg file is only used when building the final application. 

    2) If DSP_lib and customer_app both link to the platform library, which project is responsible for putting the platform library into memory such as L2SRAM?

    The memory placement is handled by the executable project.  Library projects do not typically do any memory placement.

    3) Will DSP_lib and customer_app both have .cfg files which are used? Or will the customer_app .cfg file be the only one which has an effect? If both .cfg files are used, could they interfere with each other?

    Only the customer_app.cfg is used for the final link.  The .cfg file for the static library is not used.

    4) Can DSP_lib be configured so that all SysBios functionality which it uses will use memory from the 16MB of DDR3 memory which is reserved for DSP_lib?

    This is controlled in the final link.  See the Memory section of the SYS/BIOS User's Guide for some more info on placement of sections.

    5) Can customer_app be configured so that all SysBios functionality which it uses will use memory from outside of the 16MB of DDR3 memory which is reserved for DSP_lib?

    Same as answer to #4.

    6) Should DSP_lib configure and use its own separate heap?

    No.  The configuration file used to build the DSP lib really has no affect.  Only the final app's .cfg file is used.  If you want to have a separate heap for the DSP library, you can, but it is up to you.

    7) Is it correct that DSP_lib should not have its own main() function?

    No.  You should only have one main() function.

    8) Will customer_app have to use the same version of sysBios (bios_6_33_04_39) as DSP_lib?

    We try to keep SYS/BIOS binary compatible within releases.  In general, code built with 6.33.04.39 can be linked with customers that are using 6.33.0x.yz, where x is >=4.   So, if you build with 6.33.04, your customers can use 6.33.04, 6.33.05 or later.   The latest version is 6.35.01.  You might want to update to that to allow your customers to use 6.35.01, 02, etc.

    9) If Task 2 is created from inside Task 1, where will Task 2's stack be placed in memory?

    The stack is allocated from the default system heap.  It doesn't matter which task created Task 2.

  • 0 in reply to Karl Wechsler
    Expert 2145 points

    Karl, thank you for your detailed answers, they are very helpful.