CLA Hands On Workshop - Part 2 The CLA 'C' Compiler
The CLA is supported by a subset of the ANSI ‘C’ Compiler. You will learn the features, and more importantly, the limitations, of this compiler in this video. The video also covers the changes in the linker command file needed to support operations on the CLA.
Resources
In this module, we will talk a bit more about the C compiler for the CLA. The C compiler is supported in all versions of the co-gen tools 6.4.0 and above. If you want your code to be compiled for the CLA, it needs to reside in a file with the extension .cla.
If you look on the right hand side, you can see that, initially, the compilation starts off with the c2000 compiler. If it comes across a file with the .cla extension, it goes and branches off to this CLA set of tools-- the compiler, the optimizer, and the co-gen. And it all comes together for the assembler and linker to give you a unified, dot out file.
Now, alternatively, you can also mark a .c file for CLA compilation by setting the file level property cla_default. This way, you can have the same file be compiled either for the C21 or the CLA. So you don't have to maintain two separate sets of code that do the same thing.
I mentioned before that the standard C library is not supported. We do, however, offer the CLA math library, which does some of the functions that are in the standard math library. Data types are different between the C28x and the CLA. For example, pointers are 16 bits on the CLA, while they're 22 bits on the C28x.
Integers are 32 bits wide on the CLA, while they're 16 bits wide on the C28x. It's important to keep these differences in mind, especially when you're operating on data that is going to be shared between the C28x and the CLA. We'll talk a bit more about this during the tips and tricks module of this workshop.
I also mentioned that the CLA comes out of reset having absolutely no resources, so no memory and no runtime support library. There is no cinit function that normally would initialize global variables. Therefore, we do not support defining and initializing global data in the CLA.
There are no stacks for the CLA. So local and compiler variables are placed in the scratchpad area in the linker command file. This section is going to be called .scratchpad. Depending on which co-gen you're using, older co-gen's, closer to the 6.4, would only support a one level deep function call.
That has changed in the newer versions of compilers. You can now have deeper function calls supported, depending on how much scratchpad memory you've allocated. I would encourage you to check your compiler user guide for details on function calling.
Recursion and function pointers are not supported. Uninitialized global data is placed in the section .bss_cla. Note that you cannot have initialized global data on the CLA. It is not supported. Constants are placed in the section .const_cla.
Local and compiler variables are placed in the scratchpad. There is no stack on the CLA. The scratchpad is placed in the section .scratchpad in the linker command file.
The CLA compiler is going to put all the CLA code in the section Cla1Prog. This is the equivalent of the .text section on the C28x. This is a legacy name that has been adopted from our assembly usage.
Now, if you've noticed that all of these sections reside in RAM. The const_cla section has to actually be loaded to flash and then copied over to RAM during runtime in any stand alone application. The size of the scratchpad is determined by the linker. And it will issue an error if you have not allocated sufficient space for the scratchpad.
There is no C system heap for the CLA, hence there is no support for operations such as malloc and free. This slide shows the changes required to the linker command file to support the C compiler for the CLA.
The three sections-- the data sections that I mentioned in the previous slide-- the scratchpad, the bss CLA, and the const CLA are shown in the red highlighted box here. Notice that for the constants section, I've included a run address and a load address.
So if you're using your application in standalone mode, this section would be loaded into flash and it must be copied over to RAM at runtime. The same goes for the CLA program section-- the Cla1Prog. So if you're using it in standalone mode, you load the code to flash, but then copy it over to its runtime location in RAM.
Now, on some devices like the 2806, the 2803x, and the 2805x, the CLA has a fixed programming RAM. And in these cases, it's RAM ls 3. And data can only be in either of RAM ls 0, 1, or 2. But on newer devices, like 2837x Delfino, you can configure any of the local shared RAM, the lsx RAMs, to be either CLA program or data space.
So check your device data sheet or TRM for the list of memory RAMs that can be allocated to the CLA. In the next module, I will walk through the workshop code and show you the process of migrating code from the C28x to the CLA. Thank you for watching.
This video is part of a series
-
Control Law Accelerator (CLA) hands-on workshop
video-playlist (5 videos)