which MSP432 build configuration should I use to explore class implementation with the driverlib

Hi James,

We are looking into the matter and trying to get your request to the right team. We will get back to you in time.

Regards,

David

Hello Tim,

Thank you very much for picking up my issue. I commented out the lines in the CMSIS_CSS.h as suggested for the work around. Using the standard build with driverlib, renaming main.c to main.cpp (for C++ behavior), and running TI v5.2.4 compiler version I still get a build error stating "fata error #1965: cannot open source file "driverlib.h". There is a red "x" on the #include "driverlib.h" at the top of main.cpp.

In order to get the compiler to include a class header (e.g. #include "rectangle.h") I needed to change the name of main.c to main.cpp. Could this be the reason the work around isn't working? Or was the work around to fix main.c reluctance to accept class headers? If so, then I need to try again.

thank yoiu

Jim

Jim,

In this case what is happening is that the compiler is searching for the "driverlib.h", however it cannot find it.  You have to specify the path in the compiler options where this file is located. Right click your project, go to properties, and then navigate to the following menu:

In the dialog box, specify where driverlib.h is located. In my case it is "C:\ti\msp430\MSP432_DriverLib_2_20_00_08\driverlib\MSP432P4xx", but it really depends on where you installed CCS or where you downloaded DriverLib/MSPWare to. Once you specify to the compiler where to find "diverlib.h" it should compile without issue. In any case, please let me know and I will be happy to support if you are having more issues.

Best Regards,

Hi Tim

I added the path variable "C:\ti\msp430\MSPWare_2_20_00_19\driverlib\driverlib\MSP432P4xx" and successfully compiled the C++ class headers and accessed driverlib utilities. If I could trouble you a little more I have some clarification questions that would help me understand the system a little better.

1. in your compiler build path I noticed that the msp432Pxx is specified using the (PROJECT_ROOT) variable. I also have the same build specification. But My PROJECT_ROOT points to the directory of my C++ project which does not contain the driverlib so I would expect it to fail. Do you have the driverlib,h located in your project folder? If not, how did the compiler find your driverlib.h? Is the library path part of the Includes folder and if so, how did it get there without directly specifying it in the dialogue box?

2. My PROJECT_ROOT contains an msp432p4xx_driverlib.a entity. What is it purpose?

3. The Includes folder also has path variable containing the Debug_TI folder. This path specifies that msp432p4xx is in my PROJECT_ROOT directory which it is not. Does the Debug tool search the Includes folder as well?

4. Is the work around still necessary (commenting out some of the compiler specifications) and should I restore it to original? And why does commenting out those directives make a difference for how the compiler does it build for C++ headers?

I apologize for all the questions. It just that the system has a lot of overhead to give a standard look and feel across a very large product family but it is very hard to comprehend. So I really don't know if all the pieces are working as they should.

Jim,

I'm glad that this worked for you. To answer your questions:

1. What I put for #3 is the answer to this question. DriverLib is there- but in library form.
2. This file is the static library. When we release DriverLib, we release a precompiled library of all of the DriverLib sources. This way, instead of having to compile all of DriverLib when you build your project, the linker will just grab the symbols it needs from this precompiled library and build your executable. I'd recommend reading this page on static libraries.
3. I'm not seeing the Debug_TI folder that you are referring to.  The Debug word that you are seeing is probably related to the build configuration. You can have several build configurations (such as Debug and Release).
4. I've closed the loop with the compiler team- but there are some variations internally that happen when you compile C and C++. When compiling with C these symbols aren't used within the compiler and you don't get the conflict- but when C++ is compiled this problem occurs. You can leave these symbols commented out and you shouldn't have any issue. They will be removed with a future version of the header file.

Let me know if this clarifies your questions. 

Best Regards,

Hi Tim

Thank you very much for your support, I really appreciate all the help you have given me. With regard to my first question of my previous post I noticed that it appears that I have the same search path variables as yours. So I was wondering why the path variables worked for you but not for me (until I explicitly put the path to the library in). Did you have the library in your PROJECT_ROOT directory?

The driverlib has a very nice document describing the API. Is there an equivalent API description for the macro expansions (those that don't yet have DriverLib equivalents)?

Again thank you very much for taking the time and effort to support my learning curve

Jim

Hello Jim,

No problem at all with the support.

For my library file, I had a virtual link to my file in CCS. This means that CCS sees this file in my project root, however is actually "linked" to a file in the file system. All of our example DriverLib projects are setup in this way. If you go to properties for the .lib file, you will see the following:

(the paths may vary depending on your system). The MSPWAREDLIB_ROOT variable is a variable that is defined automatically by CCS. Note that if you are using the .a library, this is the library compiled via GCC. Since ARM compilers tend to have a "compatibility" between compilers this should work, but I'd recommend using the .lib file under the "ccs" directory of DriverLib for CCS projects.

I have brought the lack of documentation of these macros to the attention of the compiler team. These macro extensions should be added to the compiler User's Guide in the near future.

Best Regards,

Hi Tim,

I've run into additional problem running C++ on CCS6. I first started having problems while trying to write an interrupt handler for Timer A0.

I edited msp432_startup_css.c to put in an external declaration interrupt handler i.e.   extern void Timer_A0_N (void);  replaced defaultISR  with Timer_A0_N in the interruptVectors[] Table at the location commented /* TA0_N ISR */ . I then defined the procedure in main.cpp static void Timer_A0_N (void) {....} and did a build to check my progress. I am getting "error #10234-D unresolved symbols remain" and a failed build. 

It occurred to me that the compiler wasn't finding the startup_css.c file. So I put a path to it in the include file of the main procedure. This gave different errors. I looked into the startup_css.c file and saw that interrupt table pragma was written for standard "C" not "C++" (page 95 of the compiler user manual). I changed the pragma to C++ semantics and renamed the startup_css.c to startup_css.cpp.

this resulted in compiler warnings that the table was not used. A search on the forum showed another person having the same problem running c++ code with their interrupt vector table.

 .

 

My questions are:

1. What switches should I set to put the compiler in c++ mode? It seems tedious that I have to rename files and change semantics in the startup_css or other files to make the eco-system work.

Hello Jim,

Sorry for the delayed response. Out of curiosity, could you try removing the "static" from the " static void Timer_A0_N (void) {....} " in your main.cpp file?

To answer your question- there shouldn't be any specific switches that you need to put the compiler in CPP mode. All of this should be done in the background automatically by CCS.

Best Regards,

Hi Tim

The static declaration made no difference. The problem was that interrupt vector table was not found. When I manually put the link in, the compiler complained that the pragma was ill formed. Checking the compiler documentation I found that the file used C semantics not C++. I changed the pragma semantics to C++ and their were numerous other compiler complaints, most likely due to ill-formed C++ semantics downstream.

The compiler does not distinguish between C and C++ unless I modify the make file attribute to tell it to use .cpp file extensions. But even if the compiler supports C++, it would appear that the eco-system does not. To do so would require a switch somewhere to select C++ compatible files and there is probably too much existing collateral written in C to easily do so without a significant effort from marketing and the software developers of the eco-system. I seen other posts from people also struggling with C++ so it might be wise to alert your marketing department to warn that the eco-system is not C++ friendly. At this point, I decided to stop fighting an uphill battle and reverted my code to C. It is disappointing because it makes it harder to maintain for branches in the design. But it is still doable.

thank you for your support, I am grateful and greatly appreciate that you took the trouble to help me through the difficulties.

Jim

Jim,

Sorry that you are having trouble. I have filed an issue in our internal system to add some C++ example projects to the DriverLib collateral so hopefully this will help in the future.

Best Regards,
Tim

Hi Tim

Thank you for responding.  

I would like to confirm that the eco-system really does support C++ code and that I just did something stupid or didn't import the right project file.

Right now judging by the ill formed pragmas of the Interrupt Table file  it doesn't seem that the system works with C++ code due to differences in semantics between C and C++. Can you confirm that the eco-system is fully capable of supporting C++ code for interrupt tables? If so, please let me know the settings and the process to do so. If not, then I think this issue should be elevated to the developers of the eco-system to add major changes (which is more than just a few examples).

thank you

I appreciate your effort.

jim

Jim,

I do see what you say with the problems caused by changing your startup file to .cpp. One way to fix the problems introduced by here is to keep your startup file as a .c extension, and then put the following around all of your ISRs:

extern "C"
{
    void systick_isr(void)
    {
        MAP_GPIO_toggleOutputOnPin(GPIO_PORT_P1, GPIO_PIN0);
    }
}

The extern "C" bracket will tell the compiler to use C style linking notations for the enclosed code. Other than this, it might be worth asking this same question on the TI Compiler E2E to get better support (this is delving out of the DriverLib scope).

Best Regards,