• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 54 subscribers
  • Views 1546 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

h file ignored

Bruce Matichuk
Intellectual 550 points
Other Parts Discussed in Thread: SYSBIOS

I am very confused about what is included in a compile and what is excluded

I am looking at .c file that is being compiled that includes a reference to a .h file.

/*

 *  ====================== Includes ============================================

 */

#include <inc/hw_memmap.h>

#include <inc/hw_ints.h>

#include <driverlib/ioc.h>

#include <driverlib/udma.h>

#include <xdc/std.h>

#include <xdc/runtime/System.h>

#include <ti/sysbios/family/arm/m3/Hwi.h>

#include <ti/sysbios/family/arm/cc26xx/Power.h>

#include <ti/sysbios/family/arm/cc26xx/PowerCC2650.h>

#include <ti/drivers/PIN.h>

#include "Board.h"

/*

 *  ========================= IO driver initialization =========================

 *  From main, PIN_init(BoardGpioInitTable) should be called to setup safe

 *  settings for this board.

 *  When a pin is allocated and then de-allocated, it will revert to the state

 *  configured in this table.

*/

PIN_Config BoardGpioInitTable[] = {

#if BOARD_SALU

Board_LED1_EN    | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* LED initially off             */

Board_LED2_EN   | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* LED initially off             */

Board_LED3_EN   | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* LED initially off             */

Board_LED4_EN   | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* LED initially off             */

Board_SENS_LED1_EN  | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* LED initially off             */

Board_SENS_LED2_EN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* LED initially off             */

Board_PHOTO_EN  | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* Initially off             */

Board_LDO_EN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* Initially off             */

Board_ECG_SDN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW   | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* Initially off             */

Board_SPI1_ACCEL_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH  | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* Initially high             */

Board_SPI1_FLASH_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH  | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* Initially high            */

Board_SPI1_FLASH_HOLD | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH  | PIN_PUSHPULL | PIN_DRVSTR_MAX,     /* Initially off             */

Board_PWR_INT | PIN_GPIO_OUTPUT_DIS  | PIN_INPUT_EN  |  PIN_NOPULL, /* Input, no pull */

Board_ACCEL_INT | PIN_GPIO_OUTPUT_DIS  | PIN_INPUT_EN  |  PIN_NOPULL, /* Input, no pull */

#else...

 

The define "BOARD_SALU" is in "Board.h"

#ifndef __BOARD_H__

#define __BOARD_H__

#define BOARD_SALU (1)

#ifdef __cplusplus

extern "C" {

#endif

/** ============================================================================

 *  Includes

 *  ==========================================================================*/

#include <ti/drivers/PIN.h>

#include <driverlib/ioc.h>

/** ============================================================================

 *  Externs

 *  ==========================================================================*/

extern PIN_Config BoardGpioInitTable[];

... the reset of my board definitions

____

For some reason my Board.h file is completely ignored by the compiler. I can go into it and type junk and it is completely ignored.

But if you F3 on Board.h CCS finds the file. 

What gives? How do I get the compiler to "see" my .h file?

  • 0
    TI__Guru**** 159725 points
    How a compiler files a file is based on the way you include it. i.e. #include "" and #include <> mean different things. This video explains the difference: www.youtube.com/watch

    Then in your project options you specify where the compiler should search for files. This behavior varies a bit based on whether you used <> or "".

    In your case if you have a #include "board.h" line and you are not getting an error about not being able to find the file then the compiler is finding some board.h file. However it may be a different one that is somewhere on the search path. Given what you are describing that is what I suspect.

    Regards,
    John
  • 0 in reply to JohnS
    Intellectual 550 points
    John,
    The video was great! Thanks.

    I already have a pretty good idea about how h files work so that wasn't really what my question was about.
    My question was more along the lines of "Why is Code Composer broken?"
    Or possibly "Why is Code Composer doing something mysterious that is completely not obvious?"

    Every h file that is referenced within the current c file should/must be read by the compiler whether or not the short name is already referenced at another point in the compilation hierarchy. The <> vs "" simply inform the include processer where to look.

    There is one practical reason that I can think of for h files being ignored. That is when "precompiled" headers are used. However, the compiler (CCS) is not including any precompiled headers, that I know of. If it is using a precompiled header, and it is not explicitly telling me about it, then that is a bug.

    What find even more mysterious is that the "Board.h" file I'm referencing in my c file s contained in the same directory. When the "include" processor is running it is supposed to look in the local directory first if quotes are used for the h file reference. In my case, the local file is being ignored.

    Either the Code Composer designers have built a mysterious hiding h file feature, or there is a bug.
  • 0 in reply to Bruce Matichuk
    Guru 92251 points

    Bruce Matichuk said:
    My question was more along the lines of "Why is Code Composer broken?"
    Or possibly "Why is Code Composer doing something mysterious that is completely not obvious?"

    To investigate what is happening suggest you set the Parser Preprocessing Options for the project to the following and then re-compile the project:

    That will cause the compiler to create a .pp file for each source file in the project, which contains the output from the pre-processor, along with comments about which files have been included. That should highlight if the compiler is picking up a board.h file from an unexpected location.

  • 0 in reply to Chester Gillon
    Intellectual 550 points

    Chester,

    That's a good idea. I will look into that.

    But let's assume that the board.h file is somehow being consumed by the preprocessor, that doesn't make this less confusing. First of all, board.h is going to be unique to every project so it doesn't make any sense to pre-compile that particular h file by default. Secondly, the compiler should be smart enough to know that a file that I've added to the project is being ignored and it should tell me that. 

  • 0 in reply to Bruce Matichuk
    Guru 92251 points

    Bruce Matichuk said:
    Secondly, the compiler should be smart enough to know that a file that I've added to the project is being ignored and it should tell me that.

    The compiler is just a command line tool which doesn't know anything about the CCS project structure.

    What would be useful is for the compiler to report a warning if an include file is found in more than one #include search path.

    With TI ARM compiler v5.2.6 I created a project in which there was a Board.h file into two directories on the #include search paths. With the Issue Remarks, Verbose Diagnostics and all MISRA-C:2004 warnings enabled, the compiler didn't report any warnings about having the Board.h include file in two search paths. Changing the order of the directories on the #include search path changed which of the two Board.h files the compiler used. Not sure if worth requesting an enhancement to the compiler to add a warning about duplicate files in the #include search paths.

  • 0 in reply to Chester Gillon
    TI__Guru**** 159725 points

    It would be nice if somehow when you added a header file that CCS warned you if it wasn't on your search path.  It would need to come the CCS build system as the compiler doesn't care.  The compiler is only concerned if it can find a file of the specified name on the search path.  If it can't then it will complain.  If it can then it is happy.

    One tool that might be of some help is the Include browser.  To open it you need to fo to View -> Other.  Type include in the filter box.  Then select the Include Browser.  With this tool you drag a source file into it and it will show the include structure and you can click on each file and it will open them so you can see which exact one is being included.  You can also click on the little down arrow on the far right and select "show folders".  That will give you a view something like this:

  • 0 in reply to JohnS
    Intellectual 550 points
    That looks extremely helpful! Many thanks for pointing that out!
  • 0 in reply to JohnS
    Intellectual 550 points
    The problem with the include hiearchy is that it doesn't match the project hierachy or the file hiearchy.
    So when you see an h file reference, there is really no good way to investigate it without this browser tool.

    The visual project hiearchy is misleading. For example, if you have an h file within a folder in visual project list but that h file is not in the same physical directory as the c file listed right next to it, then the h file that you see might not be the h file included. The include processor will look in the directory.

    Normally, for new users, this is probably not a problem if you are build small projects from scratch. In my case, however, I had a developer build some code which I included in my project. He made changes to the default project and to the TI RTOS files. I had some trouble following the h file when I incorporated his changes into the SimpleBLEPeripheral project.

    In my opinion, the h file browser functionality should be included in the project browser. In essence, every c file references h files. And every h file references other h files. That hiearchy is folder dependent not project structure dependant, so the reference hiearchy should be made explicit and navigable within the project structure.