TMS320F28388D: DriverLib and c++ support

Marcel Kummer said:

Since c is a subset of cpp ther linker should not run into problems finding the symbols.

The issue is C .vs. C++ linkage. C++ applies name-mangling to support function overloading which C doesn't. See Language linkage and What is the effect of extern “C” in C++? for some background information.

For include files for C libraries, such as those from the C2000ware example device/device.h, which have not been written to have extern "C" blocks to allow them to be included from C++, you can wrap the include statement in the the C++ source file. E.g. with the following in a empty_bitfield_driverlib_project/empty_bitfield_driverlib_main.cpp then using C2000Ware_3_03_00_00 and ti-cgt-c2000_20.2.2.LTS the program linked:

#include "f28x_project.h"
#include "driverlib.h"
extern "C" {
#include "device.h"
}

void main(void)
{
    Device_init(); //driverlib function
}

Edit: Clarify that it is the the example device/device.h which doesn't have extern "C", rather than the driverlib functions.

Marcel Kummer said:

3) Is there any way to get rid of all the warnings generated by the driverlib.cpp? (driverlib.c renamed to .cpp)

The issue is the following in C2000Ware_3_03_00_00_Software/driverlib/f2838x/driverlib/debug.h:

//*****************************************************************************
//
// Prototype for the function that is called when an invalid argument is passed
// to an API.  This is only used when doing a DEBUG build. It is the
// application's responsibility to define the __error__ function.
//
//*****************************************************************************
extern void __error__(char *filename, uint32_t line);

//*****************************************************************************
//
// The ASSERT macro, which does the actual assertion checking.  Typically, this
// will be for procedure arguments.
//
//*****************************************************************************
#ifdef DEBUG
#define ASSERT(expr) do                                                       \
                     {                                                        \
                         if(!(expr))                                          \
                         {                                                    \
                             __error__(__FILE__, __LINE__);                   \
                         }                                                    \
                     }                                                        \
                     while(0)
#else
#define ASSERT(expr)
#endif

The issue is that the filename argument in the prototype for the __error__ function is not const-qualified. When the ASSERT macro is used the C++ compiler is reporting a "#2825-D conversion from a string literal to "char *" is deprecated" warning that the C compiler doesn't.

A string literal is const-qualified, so I think driverlib should be changed so that the __error__ function has a const-qualified filename parameter. I.e.:

extern void __error__(const char *filename, uint32_t line);

//*****************************************************************************
//
// Error handling function to be called when an ASSERT is violated
//
//*****************************************************************************
void __error__(const char *filename, uint32_t line)
{
    //
    // An ASSERT condition was evaluated as false. You can use the filename and
    // line parameters to determine what went wrong.
    //
    ESTOP0;
}

Hi Marcel,

You can try out the solutions provided by Chester.

Once you get it to compile, you can load it to the Control Card through CCS using a target configuration file.

Best Regards

Siddharth