-1

这会在 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，当函数被调用时，它当然会选择默认的 Error 'unexpected rf chain'。

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

但我有一种感觉，如果不进行任何修改，这段代码无论如何都不会运行。

所以我在这里向论坛提出的问题是，除了上面的这个构造没有真正意义之外，这不是一个错误的构造吗？

这会在 Linux GCC 下编译和工作吗？

我尝试在 GCC ARM 下使用此代码，但它似乎没有按计划工作。

4

2 回答 2

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
    };

这本身似乎很明智。

你接着说，

[...] 当函数被调用时，它当然会选择默认的错误“意外的射频链”。

我看不出有任何理由期望选择不同的案例，但我也看不出有任何理由假设不会选择不同的案例。也不清楚它switch本身在什么情况下被执行。

rf_radio_type如果实际上存在相应的硬件，人们通常会期望在驱动程序初始化期间设置一个或两个元素。如果整个代码（不仅仅是您呈现的部分）是正确的，那么switch当rf_radio_type[rf_chain]它的值与LGW_RADIO_TYPE_SX1255和不同时，它可能不会执行呈现的代码LGW_RADIO_TYPE_SX1257。另一方面，打印错误消息本身基本上是无害的。如果驱动程序打印了它，那么这可能只是实施质量问题，而不是功能缺陷。

所以我在这里向论坛提出的问题是，除了上面的这个构造没有真正意义之外，这不是一个错误的构造吗？

不，不是。据我所知，所有提出的结构在脱离上下文时都尽可能地有意义。

这会在 Linux GCC 下编译和工作吗？

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

我尝试在 GCC ARM 下使用此代码，但它似乎没有按计划工作。

我发现您对您对整体代码预期行为的评估的明显信心有点乐观。

于 2016-10-25T20:07:04.303 回答
0

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

正如在另一个答案中指出的那样，如果程序员没有明确设置它们，C 标准要求具有静态存储持续时间的变量隐式初始化为零。因此，就 C 标准而言，这是很好的代码。

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

这样的非标准选项在编译器选项中通常称为“最小/紧凑/快速启动”或类似名称。如果您启用了这样的选项 - 这很常见 - 代码将不起作用。

好的做法是稍后在“运行时”中初始化这些变量，然后再第一次使用它们。

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

于 2017-03-08T16:03:30.640 回答