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.

Is there a link between the rts library and a XDC system module?

Other Parts Discussed in Thread: SYSBIOS

Wouldn't it be easier to integrate proprietary and 3rd party code if there was a link between the underlying rts library and a XDC System module?

What about if assert() actually called System_abort instead of abort() and stderr actually was an XDC logger module?

Where do error messages to stderr (e.g. asserts) end up when running an application based on sysbios on a c674 or m3 target in an omap4 platform?

 

  • We figured that toolchain and board vendors know best how to do low-level services for their system. If we came in "under" the standard C APIs, we'd be duplicating that work and probably not as well. So long story short, stderr, assert and friends will end up wherever they would if XDCtools were not in the mix.

    Incidentally, we do provide a link, but it's in the opposite direction. SysStd, HeapStd and TimestampStd sit "above" the standard C APIs and call down to them. Their main value is in giving a portable implementation. Writing custom implementations of these APIs is useful to scale down to really small memory footprints, hopefully much smaller than if you were to implement the full standard C API.

    Jon

  • Hi Jon,

    I'm late in this thread, I know, but what you write sounds for me as if you might give the answer to this my question, too:

    Which mechanism resp. configuration entry brings XDCtools to link this or that kind of rts library? In my case the generated build files for the codec server (running at C674 of a DM8148) let link the rts6740_elf.lib, but what actually I needed was the rts6740_elf_eh.lib.

    Hopefully,
    with kind regards,
    Joern.