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.

Compilation Error CLA C-code compilation using C++

Hello,

I'm implementering a Cla class in C++ which handles all Cla related tasks in my appliation
i want to initialise the CLA but encounter compilation problems when computing the task vectors.
I use the CLA C-code compiler *.cla files and C2000 - code generation tools - 6.1.0

 I defined the following globally outside of the CLA class and namespace. As defined in TI examples_cla/ folder and code.

//reference to tasks of the CLA defined in *.cla c-code file
interrupt void Cla1Task1();

//defined in linker *.cmd file base address of CLA program code
extern unsigned Cla1ProgStart;

In my Cla class i compute the MVECT1 register as follows
mrCla is a reference to the CLA register interface 

  mrCla.MVECT1 = ((unsigned)Cla1Task1 - (unsigned)&Cla1ProgStart);

This line results in the following error when compiling:

 error #173: invalid type conversion

Q1: How does the c2000 compiler (c++) handle function pointers and casting them to unsigned / Uint16? 
Q2: Can i get rid of this error without generating other errors or warnings? 

Thanks in advance,

Regards Rob

  • For now i solved it in the following way
    in the header i declared the references to the cla task and beginning of the cla prog

    #ifdef __cplusplus
    extern "C"
    {
    #endif

    //reference to tasks of the CLA defined in *.cla c-code file
    interrupt void Cla1Task1();
    interrupt void Cla1Task2();
    interrupt void Cla1Task3();
    interrupt void Cla1Task4();
    interrupt void Cla1Task5();
    interrupt void Cla1Task6();
    interrupt void Cla1Task7();
    interrupt void Cla1Task8();

    //defined in linker *.cmd file base address of CLA program code
    extern unsigned gCla1ProgStart;

    #ifdef __cplusplus
    }

    mrCla.MVECT1 = (unsigned)((unsigned*)Cla1Task1 - (unsigned*)&gCla1ProgStart);
    mrCla.MVECT2 = (unsigned)((unsigned*)Cla1Task2 - (unsigned*)&gCla1ProgStart);
    mrCla.MVECT3 = (unsigned)((unsigned*)Cla1Task3 - (unsigned*)&gCla1ProgStart);
    mrCla.MVECT4 = (unsigned)((unsigned*)Cla1Task4 - (unsigned*)&gCla1ProgStart);
    mrCla.MVECT5 = (unsigned)((unsigned*)Cla1Task5 - (unsigned*)&gCla1ProgStart);
    mrCla.MVECT6 = (unsigned)((unsigned*)Cla1Task6 - (unsigned*)&gCla1ProgStart);
    mrCla.MVECT7 = (unsigned)((unsigned*)Cla1Task7 - (unsigned*)&gCla1ProgStart);
    mrCla.MVECT8 = (unsigned)((unsigned*)Cla1Task8 - (unsigned*)&gCla1ProgStart);

    This works and runs the CLA code correctly however it still issues a warning
       #1311-D nonstandard conversion between pointer to function and pointer to data 

    Q3: What is the correct way in the C++ C2000 compiler to let this address computation compile without warnings?

  • Hi Rob,

    Since the result of the pointer arithmetic (address of Cla1Taskx - address Cla1ProgStart) will eventually be cast to a smaller 16-bit type (unsigned) I don't think you can avoid the warning that will result from shortening the data types, even when avoiding the error condition as you've done above.  Even though CLA function pointers are 16 bits we don't have a separate type when referencing from C28X code, where function pointers are larger than 16-bits.

    In C++, a cast of a pointer to a data type that is smaller in size results in an error. In C, or on targets  where an int type can hold a pointer value, a warning is still generated.  The CLA/C28x example code probably has a pragma that suppresses this warning (eg. #pragma diag_suppress 70,770)

    You can alternatively avoid the error by first casting the function pointer to an integer type that can fully hold the value ('uintptr_t', defined in stdint.h, is the standard typedef to use for this kind of cast) and then cast to the smaller type.  Again, this will generate a truncation warning:

    mrCla.MVECT1 = (unsigned)((uintptr_t)Cla1Task1 - (uintptr_t)&Cla1ProgStart));

    Regards,

    John

     

     

  • Thanks this answers my question
    I noticed the supress warning pragma in the example code, for now i will leave this warning as it is.

    Regards Rob van de Voort