这个枚举构造和赋值是否允许?

时间:2016-10-25 19:06:02

标签: c linux gcc lora

这会在Linux GCC中编译和工作吗?

在Github托管的LoRa网关堆栈中,我在loragw_hal.h中找到了以下构造

enum lgw_radio_type_e {
    LGW_RADIO_TYPE_NONE,
    LGW_RADIO_TYPE_SX1255,
    LGW_RADIO_TYPE_SX1257
};

#define LGW_RF_CHAIN_NB     2   /* number of RF chains */

然后在loragw_hal.c

static enum lgw_radio_type_e rf_radio_type[LGW_RF_CHAIN_NB];

编辑:数组未在代码中的任何位置初始化

然后在函数

setup_sx125x(uint8_t rf_chain, uint32_t freq_hz)

以下switch语句用于根据rf_chain参数

选择rf链
switch (rf_radio_type[rf_chain]) {
    case LGW_RADIO_TYPE_SX1255:
        // some code
        break;
    case LGW_RADIO_TYPE_SX1257:
        // some code
        break;
    default:
        DEBUG_PRINTF("ERROR: UNEXPECTED VALUE %d FOR RADIO TYPE\n", 
        rf_radio_type[rf_chain]);
        break;
}
当调用函数时,

rf_chain参数设置为1,当然它选择默认的错误'意外的射频链'。

版权所有者Semtech Inc.支持,如果您对其产品有任何问题,请始终注明此代码作为参考。

但我觉得这段代码无论如何都不会在没有任何修改的情况下运行。

所以我在论坛上的问题是,除了上面的这个结构不是真的有意义之外,这不是一个错误的构造吗?

这会在Linux GCC中编译和工作吗?

我尝试在GCC ARM下使用此代码,但它似乎无法正常工作。

2 个答案:

答案 0 :(得分:1)

您似乎试图引起对此的注意:

enum lgw_radio_type_e {
    LGW_RADIO_TYPE_NONE,
    LGW_RADIO_TYPE_SX1255,
    LGW_RADIO_TYPE_SX1257
};

#define LGW_RF_CHAIN_NB     2   /* number of RF chains */
     

[...]

static enum lgw_radio_type_e rf_radio_type[LGW_RF_CHAIN_NB];
     

[...]数组未在代码中的任何位置初始化

阵列未显式初始化并不是一个特殊问题。如果未提供显式初始化程序,则文件范围变量(和static块范围变量)将进行默认初始化。在这种情况下,数组声明等同于

static enum lgw_radio_type_e rf_radio_type[2] = {
        LGW_RADIO_TYPE_NONE, LGW_RADIO_TYPE_NONE
    };

这本身似乎很明智。

你继续说,

  

[...]调用该函数时,它会选择默认的错误'意外的rf链'当然。

我没有看到任何理由期望选择不同的案例,但我也没有理由认为不同的案例会选择 。也不清楚switch本身在什么情况下执行。

如果事实上存在相应的硬件,则通常期望在驱动程序初始化期间设置rf_radio_type的一个或两个元素。如果整体代码(不仅仅是您提供的部分)是正确的,那么当switch的值不同于rf_radio_type[rf_chain]时,它可能无法执行呈现的LGW_RADIO_TYPE_SX1255 LGW_RADIO_TYPE_SX1257 <div class="col s2 offset-s4 valign" id="shoppingCart"> <a class="waves-effect waves-teal btn-flat no-margin white-text right" th:inline="text"><i class="material-icons right">shopping_cart</i>[[@{${total}+' руб'}]]</a> </div> 。另一方面,打印错误消息本身基本上是无害的;如果驱动程序打印出来,那么这可能只是一个实施质量问题,而不是一个功能缺陷。

  

所以我在论坛上的问题是,除了这个结构   上面说的并不是真的有道理,那不是一个错误的构造吗?

不,不是。据我所知,所有呈现的结构都具有尽可能的意义,当它们脱离上下文时可以预期。

  

这会在Linux GCC中编译和工作吗?

您已经提供了几个单独有效的C片段,但它们并不构成有效的翻译单元。可以形成一个完整,有效的翻译单元,其中包含将成功编译并完成任何操作的所有片段。碎片本身不会干扰编译,也不一定会导致故障。

  

我尝试在GCC ARM下使用此代码,但它似乎无法正常工作。

我发现你对整体代码的预期行为的评估显然有点乐观。

答案 1 :(得分:0)

  

编辑:数组未在代码中的任何位置初始化

正如另一个答案所指出的,如果程序员没有明确地设置它们,C标准要求具有静态存储持续时间的变量被隐式初始化为零。因此,就C标准而言,这是完全正常的代码。

然而,编写依赖于.bss中静态存储持续时间变量初始化的代码被认为是嵌入式系统编程中的不良做法。这是因为在嵌入式系统上经常省略执行.data的复制和.bss的零初始化的代码,这是一种非常常见的非标准做法,以加快程序启动速度

这种非标准选项通常称为&#34; minimal / compact / fast start-up&#34;或类似的编译器选项。如果您启用了这样的选项 - 这很常见 - 代码将无法运行。

好的做法是稍后在&#34;运行时&#34;中初始化这些变量。相反,在他们第一次使用之前。

总结:代码写得很潦草,因为这里的目的是在许多不同的微控制器平台上提供可移植代码,而不是为某些PC提供代码。我猜它是由某种PC程序员编写的,就像这些协议栈一样。