Pre Defined Symbols to build ONLY cla.obj

A lot of the content in lib/ is fairly repititive stuff such as gpio read/write, epwm modifiers, that can be used from C28x and the CLA. Surely there is support for reusing the same source?

Hi Prakhar, 

It should be seamless to have the same code ve used across the CLA/C28. 

https://software-dl.ti.com/C2000/docs/cla_software_dev_guide/_static/pdf/C2000_CLA_Software_Development_Guide.pdf 

See this document for the case where the same code can be made to run on either core using predefined symbols

/cfs-file/__key/communityserver-discussions-components-files/171/CLAProjectStructureUG.pdf

Let me know if this answers your quesiton

Regards,

Ozino

Something that I am still not sure about is the compilation of shared files such as solution.c/h from the document you shared.

When the main.c file is being compiled by C28x compiler - I assume that the the dependencies (lib.c/h) get built into obj files. When the CLA compiler is invoked to compile tasks.cla into an object, does it recompile the dependencies (lib.c/h) with the __TMS320C28XX_CLA__ symbol? Or does it reuse the .objs from the C28 compiler?

Asking because I followed the recommendations from the document you shared - such that 

// shared.h header file

#ifndef __TMS320C28XX_CLA__
// Declare C28 functions

#include "c28_utils.h" //c28 ONLY helpers
void func1();
void func2();

# else 
// Declare CLA funcs

void func1();
void func2();

#endif

// shared.c defintion file


# include "shared.h"
#ifndef __TMS320C28XX_CLA__
// Declare C28 functions

void func1() {
 // do something
 }
void func2(){
 // do something
 }
# else 
// Declare CLA funcs
void func1() {
 // do something else
 }
void func2(){
 // do something else
 }

#endif

I have used some source analysis tools and ensured that shared.h is ONLY included in the .cla file and not in the C28 CPU main file. 

Hi Ozino.


Thanks for the reply. I went through the code for the linked project and it seems like there is a misunderstanding.

The project you shared appears to be using 1 definition of an ISR and uses preprocessor directives to toggle where it is being executed (CPU or CLA). 

In my case - I would like to alter the definition of the shared function based on whether it is being invoked by the CLA tasks, or the C28x core. Ideally, this would include differences in function signatures as well (therefore 2 different declarations in the header file on my previous comment).

If you can answer the following questions - I think we will have resolved the misunderstanding

1. Are dependencies (includes) scanned independently by the c28 and CLA compiler. AKA - can I expect two passes of the same source file if it is included in both the CLA and C28 code?
2. As such - can I manipulate the compilers to generate 2 distinct .obj files for the source (given that one is compiled with __TMS320C28XX_CLA__ defined by the CLA compiler, and the other without the symbol by C28 compiler). Do I need to rename symbols in the alternate definition (I vaguely recall the CLA compiler prepending "cla" to all used symbol names)
3. This would imply that it should be possible for me to invoke "the same" function from C28 and the CLA and achieve differing behavior. Is this possible?

Hi Prakhar,

Thanks for the detailed explanation. What you've proposed should be feasible as long as the function definitions are defined such that they are applicable for respective core that is being targeted.

Prakhar Gupta said:

Are dependencies (includes) scanned independently by the c28 and CLA compiler. AKA - can I expect two passes of the same source file if it is included in both the CLA and C28 code?

As long as you use the necessary guards, C28x vs CLA, you should be able to keep two different definitions of the same function. THough I would think that would be possible.

Prakhar Gupta said:

As such - can I manipulate the compilers to generate 2 distinct .obj files for the source (given that one is compiled with __TMS320C28XX_CLA__ defined by the CLA compiler, and the other without the symbol by C28 compiler). Do I need to rename symbols in the alternate definition (I vaguely recall the CLA compiler prepending "cla" to all used symbol names)

Are you trying to generate separate output files (e.g. main1.out, main2.out)? Or are you looking for separate main.obj files for each core? I'm not sure that would be possible without renaming the main.c file or saving the generated object files between builds.

Prakhar Gupta said:

This would imply that it should be possible for me to invoke "the same" function from C28 and the CLA and achieve differing behavior. Is this possible?

my understanding is that this NOT be for the same build correct? I assume 1 option is the function running on the C28x and the other on the CLA?

Regards,

Ozino

Thanks for the reply.

Ozino Odharo said:

Are you trying to generate separate output files (e.g. main1.out, main2.out)? Or are you looking for separate main.obj files for each core? I'm not sure that would be possible without renaming the main.c file or saving the generated object files between builds.

I am not running into issues between the 2 cores. If I understand correctly - each CPU subsystem has an .out file which is the relevant .objs linked together as per the linker script. If I wanted to use the same source file, in both the CPU and CLA on the same subsystem - and I had used the appropriate preprocessor directives to manipulate the definitions - is it possible for the same code - to be compiled by the different compilers (with different predefines) to generate distinct .objs - one for the C28 and the other for the CLA - which is then linked to the relevant calls made by CPUx_main.obj and cla_tasks.obj respectively?

Prakhar Gupta said:

But I still get the warning 

Invalid to call C28 function "func1" defined in "./shared.obj" from CLA file "./cpu2_cla.ob

I assume that the error message I receive (mentioned in a previous reply) is generated because the shared.h file is compiled by the C28 compiler, and then the same .obj is being reused by the CLA.

The only reason I am trying to achieve this behavior - is to manage my source code effectively. I am attempting to port some Motor Control code from the C28 to the CLA. I would like the code to be in the same file for future maintainability.