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

library port from DSP/BIOS to SYSBIOS: compile errors

Dirk Buijsman
Expert 1070 points
Other Parts Discussed in Thread: SYSBIOS

I'm in the process of switching a project for a C64P device from DSP/BIOS to SYSBIOS (using CCS6). The project consists of one main application which links against several TI and third-party libraries. Some of these libraries have references to for example the LCK module, which I exchanged for the GateMutex module. The E2E forum has been absolutely great and so far things went relatively smooth. 

However, I am now running into a problem with one of our own libraries where I include <xdc/std.h> and get the following compile-time error:

"C:/ti/xdctools_3_25_04_88/packages/xdc/runtime/package/package.defs.h", line 61: error #20:
identifier "xdc_Bits32" is undefined
typedef struct xdc_runtime_IGateProvider___Object { xdc_runtime_IGateProvider_Fxns__* __fxns; xdc_Bits32 __label; } *xdc_runtime_IGateProvider_Handle;

This type is defined in  "C:/ti/xdctools_3_25_04_88/packages/ti/targets/std.h", which is not included in "package.defs.h" (but perhaps on a different include level it the should have?). 

These are my includes:

  C:\ti\xdctools_3_25_04_88\packages
  C:\ti\bios_6_35_04_50\packages
  "${CG_TOOL_ROOT}/include"
  "${XDAIS_CG_ROOT}/packages/ti/xdais"
  "${C6000_CSL_CG_ROOT}/include"
  "${SRC_ROOT}/src"

predefined symbols:

  xdc_target_name__=C64P
  xdc_target_types__=ti/targets/std.h

I have 2 questions:

1) Is this the right approach? I just imported a "legacy CCS3.3 project" thinking I would convert any DSP/BIOS references manually. I tried the xs conversion tool as described in spraas7, but this gave so many issues that I decided to do a manual conversion (which for the main project was relatively painless).

2) What is the right method for referencing the SYSBIOS equivalent of what used to be <std.h> (on my system located in “c:\ti\bios_5_41_10_36\packages\ti\bios\include\std.h”)? I followed directions I found here  (to be honest, this was a bit of a shot in the dark...).

Thanks!

Dirk

  • 0
    TI__Mastermind 37985 points

    Dirk,
    I have trouble understanding the whole picture, so I'll just focus on a couple of points that seem important. First, you are saying that you are building a library that references SYS/BIOS code. Are you doing that in CCS, as a part of that same CCS project that builds the app or is it a separate project?
    Can you post the complete compiler command line that generates the error, and also the beginning of the source file so I can see at least all include directives?

  • 0 in reply to Sasha Slijepcevic
    Expert 1070 points

    Hi Sasha,

    Thanks for your reply. In the meanwhile we "fixed" the issue and got the program up and running. It turned out the "xdc/std.h" reference was not needed by that specific file....  

    I was not very clear in my question, mostly because I am still trying to get my head around the inner workings of XDC. There's a lot of terminology out there (RTSC, XDC, XDAIS, CodecEngine, DSP/BIOS vs SYSBIOS etc), some of it obsolete. Additionally, functionality has been pulled out of DSPBIOS and while most moved to SYSBIOS, some moved to XDC tools, some to the IPC-lib. The NDK modules also moved from NSP (in NDK 2.0) to PDK (emac driver) and MCSDK (nimu), which made the port somewhat challenging. Just today I got the basics going and we have the latest version of NDK running again on our C6474 and all in ELF format.

    The library I mentioned in my earlier post was built as a separate project as the main application. Currently this library uses "#include <ti/sysbios/gates/GateMutex.h>" and we simply add the include path to SYSBIOS and XDCtools (in my case "C:\ti\bios_6_35_04_50\packages" and "C:\ti\xdctools_3_25_04_88\packages").

    This works, but I want to make sure I am doing this the correct way. When using XDC tools in an application (so not a lib), the .cfg file allows you to configure the various modules in the package. While it seems logical you would only do this at the application level, is there a similar way to control XDC modules from a library as well?

    I think with the right docs (or even better: a comprehensive  example), we can get to the point where we are comfortable with the new environment. Is there an example of how to create a library which uses XDCtools and SYSBIOS? I found a really simple example for MSP430, but this did not link against any libraries.

    Cheers,

    Dirk

  • 0 in reply to Dirk Buijsman
    TI__Mastermind 37985 points
    Dirk,
    first I will point you to this page on RTSCpedia for an introduction - rtsc.eclipse.org/.../Overview_of_RTSC. You can check around for more content to get familiar with terminology.

    The use case that CCS supports well is the one where you are building an app that includes a) your sources, b) some libraries that don't reference RTSC packages in any way, and c) RTSC packages with their own libraries and any additional content. You then create a RTSC config script that configures the RTSC packages in such a way that the references from your sources to the symbols coming from RTSC packages are resolved.
    Anything outside of that framework, which includes libraries that reference RTSC packages, but are not a part of a RTSC package itself, is not formally supported. It can be done, just like in your case, but there is no a standard way to do it. The right way to create a library that references RTSC modules is to create a RTSC package with all the necessary content. That content declares which RTSC packages your library neeeds and how they should be configured. All that is explained at RTSCpedia much better than I can do here.
    An alternative is to keep your library as it is, and add to it a small RTSC config script that would be involved from the app's config script. I don't really have an example for it, but I am sure that it can be done with some hardcoding of paths in the app's project. If you expect to build more than one or two libraries that reference RTSC content, this ad-hoc approach would quickly become difficult to manage.
  • 0 in reply to Sasha Slijepcevic
    Expert 1070 points
    That's very good info, thanks. Once we get further into this project I' l take the leap and convert to a proper RTSC package, but for now the ad-hoc approach seems to work well.

    Cheers,
    Dirk