Compiler/MSP-EXP432P4111: Using google test with the TI Compiler

Reading my own post, I find it pretty confusing, so I feel compelled to add some more details on what I try to achieve and how I currently proceed.

The goal is to unit test all non hardware specific code, in a way similar to what is done for non-embedded system programming. My background is Java/gradle.

More specifically, I want to run unit tests:

- in the CCS IDE, and I want to see green (preferably) or red bars

- from the command line to test a set of projects

- on a continuous integration (CI) server.

So what I have decided to do:

To set this up, you need to install the C/C++ unit test eclipse packages that are part  of the Eclipse CDT since Juno.

You also need to install google test on your computer.

You need the latest ( really the latest ) gradle version 4.7-rc1.

For a given project "p", create a CCS project p and another p.lib:

p is a TI compiler project, with or without TI-RTOS

p.lib is a C++ project configured as executable with the Linux GCC toolchain.

p.lib must be set up as a native gradle C++ project. See here and start with this example .

This allows to run all tests from the commandline:

$ ./gradlew check

Inside the CCS IDE, create a Debug Configuration from the C/C++ template and select google test. Uncheck "stop at main" breakpoin.

When you debug this configuration you get what is familiar to java developers:

Finally, the CI integration is an open issue. I am using bitbucket pipelines and I don't have as of right now a working configuration for this setup.

Finally, in you p project add linked folder to dependent .lib projects, since we need to compile all code with the ARM compiler.

Being able to run unit tests in familiar ways is helpful for me.

Enjoy testing !

Peter

Chris, thank you, I would love to get feedback on that topic , as it seems important to me.

Some final details:

Here is a screenshot from the unit tests run in batch mode:

And I also managed to get it to work on the bitbucket pipeline build server:

So for non-hardware dependent code, I have now exactly the same testing environment as the one I use for desktop c++ or desktop java.

Automatic hardware dependent code testing can now be done with the DDS scripting environment with code written in java  which - you guessed it - is unit tested with junit in exactly the same environment as the one show above.

Here is my deceptively simple CI script ( bitbucket-pipeline.yml ) which uses the default docker image provided by Atlassian:

❯ cat bitbucket-pipelines.yml
pipelines:
  default:
    - step:
        caches:
          - gradle
        script:
          - ./gradlew clean check

This requires the gradle wrapper to be in the repo as there is no gradle installed in the default image.

Regards

Peter.

Peter Vittali said:

I would like to use gtest ( google test) to run unit tests for TI code (ti-cgt-arm-18.1.1.LTS).

I am not familiar with gtest.  Is it documented to work with an compiler for embedded bare metal systems?

Peter Vittali said:

In my CCS installation folder I have:

~/ti
❯ print -l **/stat.h
ccsv8/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major/arm-none-eabi/include/sys/stat.h
simplelink_msp432p4_sdk_2_10_00_14/kernel/tirtos/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/include/sys/stat.h

I very much doubt anyone uses those header files in combination with the TI ARM compiler.

Peter Vittali said:

Shouldn't this file be available independently from the stack I use (RTOS or bare metall) ?

No.  The code in stat.h is very dependent on the file system.  The TI ARM compiler makes no presumptions about the file system.  It is a freestanding implementation, and not a hosted implementation.

Thanks and regards,

-George

Hi George

Thanks for getting back on this topic. As I explained in my follow up, my initial post was very confusing because I mixed up the cross-compiling toolchain.

gtest is most likely not meant to run on embedded systems, in fact its an application that writes to stdout as shown in my follow up post.

I am coming from a desktop environment and failed to wrap my mind around the fact that I now have to compile for an embedded system while still wanting to use my favorite desktop tools like unit testing frameworks (gtest).

I apologize for the noise.

Rather than messing with the header files in the install dir , I should have phrased my question like this:

how do embedded programmers leverage the power of unit testing in a similar way as non-embedded programmers are used to do ?

In my follow up post, I describe a possible approach where the hardware independent part of the code (library code) can be tested with the Linux toolchain and gtest, like on a desktop project. This approach is not entirely satisfying because the library code obviously still needs to be compiled with the TI compiler as well, in order to be loaded on the target. I am using linked folders in eclipse for this and this is probably not the best solution.  Feedback is very welcome.

Regards

Peter

Chris

Thanks for the follow up, I am looking forward to read what the TI experts have to say about the embedded unit testing toolchain.

Regards

Peter