• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 190 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.

TI-15.4-STACK-GATEWAY-LINUX-SDK: Question on the Linux implementation uses a runtime variable.

user4650693
Intellectual 440 points

Part Number: TI-15.4-STACK-GATEWAY-LINUX-SDK

I am using TI-15-4-STACK-GATEWAY-LINUX-SDK_4.30.00.06 and know that TI Linux implementation uses a runtime variable rather than a compile time constant.

Most of coding is clear to me, except CONFIG_MAC_BEACON_ORDER (in collector.c) and CONFIG_PHY_ID (collector.c, collector.h, and ti_154stack_config.h).

Take CONFIG_MAC_BEACON_ORDER as an example.

--- snipped code ---

#if (CONFIG_MAC_BEACON_ORDER != NON_BEACON_ORDER)
/* This is 3 times the polling interval used in beacon mode. */
#define TRACKING_TIMEOUT_TIME ((1<<CONFIG_MAC_BEACON_ORDER) * 960 * SYMBOL_DURATION * 3 / 1000) /*in milliseconds*/
#else
#define TRACKING_TIMEOUT_TIME (CONFIG_POLLING_INTERVAL * 3) /*in milliseconds*/
#endif

 --- snipped code ---

My understanding is "the pre-processor cannot use variables from the C program in expressions, it can only act on pre-processor macros."

So code above to use CONFIG_MAC_BEACON_ORDER  in the pre-processor is out of my expectation. Actually it always return true. Am I correct?

Regards,

Peter.

  • 0
    TI__Expert 3886 points

    Hi Peter,

    You are indeed correct. The pre-processor cannot use variables from the C program in expressions, it can only act on pre-processor macros. But that is not the case here.

    I'm not particularly familiar with the Linux SDK, but looking at the code and at the User's Guide (https://dev.ti.com/tirex/explore/node?node=ABIZFjEYRCbdsticRjM4Jw__oGlG4RW__LATEST), it seems that ultimately for the Embedded config file, you still get a macro, not a C variable.

    My guess is that the build process has several stages. In the first one, you take care of the global variables defined in the linux_main.c file. And then at some other stage, you use these already defined variables to set the value of the macros in the Embedded Config file (i.e. ti_154stack_config.h).

    So as far as the Embedded Config file knows, these are just regular macros and not C variables, and no rules are broken when it comes to the use of pre-processor macros.

    BR,
    AndresM

  • 0 in reply to AndresM
    Intellectual 440 points

    Hi AndresM,

    If you are talking on Embedded collector, that is fine. I am talking on collector Linux implementation.

    The problem is : C pre-processor #if expression is compile time, but Linux implementations (such CONFIG_MAC_BEACON_ORDER) are runtime variable.

    Let me explain more details from TI doc and code.

    From section "Collector Application Configuration" in "">software-dl.ti.com/.../linux-running-the-example-applications.html, it said Linux implementation use Part 1 and Part 2 to defines and uses a runtime variable rather than a compile time constant.

    For Part 1, we know that ti_154stack_config.h file defines most of the global variables (such as CONFIG_MAC_BEACON_ORDER, CONFIG_PHY_ID, etc.).

    --- snipped code ---

    extern int linux_CONFIG_MAC_BEACON_ORDER;
    #define CONFIG_MAC_BEACON_ORDER linux_CONFIG_MAC_BEACON_ORDER
    #define CONFIG_MAC_BEACON_ORDER_DEFAULT 15

    --- snipped code ---

    For part 2, we know that all global variables are defined in the linux_main.c file along with their default values. At start-up, the code for the linux_main.c file reads and parses the application configuration file (the contents of which may alter the value of the configuration values).

    --- snipped code ---

    int  linux_CONFIG_MAC_BEACON_ORDER = CONFIG_MAC_BEACON_ORDER_DEFAULT

    --- snipped code ---

    So, for TI 15.4 Stack Linux SDK, its implementations in ti_154stack_config.h are runtime variables not constants.

    Therefore, its use in #if expression is not correct from my understanding.

    My sanity tests confirm me, that "#if (CONFIG_MAC_BEACON_ORDER != NON_BEACON_ORDER)" always return true as (0 != 15).

    And "#elif (CONFIG_PHY_ID == APIMAC_250KBPS_IEEE_PHY_0)" always return true as (0 == 0).

    Regards,

    Peter.

  • 0 in reply to user4650693
    TI__Expert 3886 points

    Hi Peter,

    May I ask, how are you running those sanity checks? I would like to do them as well to reproduce what you are seeing.

    BR,
    AndresM

  • 0 in reply to AndresM
    Intellectual 440 points

    Hi AndresM,

    My configurations are SLR using non-beacon mode.

    Change original snipped code in collector.c file below:

    --- snipped code ---

    #if (CONFIG_MAC_BEACON_ORDER != NON_BEACON_ORDER)
    /* This is 3 times the polling interval used in beacon mode. */
    #define TRACKING_TIMEOUT_TIME ((1<<CONFIG_MAC_BEACON_ORDER) * 960 * SYMBOL_DURATION * 3 / 1000) /*in milliseconds*/
    #else
    #define TRACKING_TIMEOUT_TIME (CONFIG_POLLING_INTERVAL * 3) /*in milliseconds*/
    #endif

    --- snipped code ---

    to below. You can see that Linux compiler will fail due to we put one line of wrong code. This makes sure original expression is not correct.

    --- snipped code ---

    #if (CONFIG_MAC_BEACON_ORDER != NON_BEACON_ORDER)
    /* This is 3 times the polling interval used in beacon mode. */
    #define TRACKING_TIMEOUT_TIME ((1<<CONFIG_MAC_BEACON_ORDER) * 960 * SYMBOL_DURATION * 3 / 1000) /*in milliseconds*/

    int foo = 0 /* wrong code */
    #else
    #define TRACKING_TIMEOUT_TIME (CONFIG_POLLING_INTERVAL * 3) /*in milliseconds*/
    #endif

    --- snipped code ---

    This is because CONFIG_MAC_BEACON_ORDER is a runtime variable (i.e. linux_CONFIG_MAC_BEACON_ORDER) and we know "the pre-processor cannot use variables from the C program in expressions". Actually the pre-processor tries to evaluate linux_CONFIG_MAC_BEACON_ORDER that isn't defined as a macro, it treats it as having a value of zero I think. Hope it clear.

    Regards,

    Peter.

  • 0 in reply to user4650693
    TI__Expert 3886 points

    Hi Peter,

    Thank you for the fast reply. I have reproduced the issue you've described, so I will pass this information to the appropriate team to get their feedback.

    While doing some additional debugging, I noticed that CONFIG_MAC_BEACON_ORDER is actually being defined (try adding #define CONFIG_MAC_BEACON_ORDER to collector.c, and you will see the message from the compiler). The main issue is that at least for collector.c, CONFIG_MAC_BEACON_ORDER is just "linux_CONFIG_MAC_BEACON_ORDER", not the numeric value that we were expecting to get from linux_main.c.

    So I don't think that the issue is that the pre-processor is trying to use a C variable in the #ifdef expression, but that the value we want from linux_main.c is not being propagated correctly to collector.c.

    BR,
    AndresM