软件组件缺失特性上报方法、相关术语及兼容技术咨询

First off, the official term you're looking for is Feature Discovery (sometimes also called Capability Querying in embedded systems contexts). This exactly describes the practice of having software components expose their supported features, limitations, and hardware dependencies upfront—rather than letting issues surface only at runtime or relying solely on documentation. It's a core part of building robust, portable embedded software, especially for peripherals like I2C where hardware implementations can vary wildly.

Now, beyond the three methods you outlined, here are additional techniques to tackle compatibility and feature reporting in embedded firmware:

Compile-Time Feature Validation #

• Use preprocessor macros paired with compile-time checks to catch unsupported feature usage early, before code runs on target hardware. For example:

  #if !defined(FEATURE_I2C_10BIT_ADDRESS)
  #error "10-bit I2C addresses are not supported by this hardware"
  #endif
  

  Many embedded SDKs (like STM32 HAL or TI DriverLib) rely heavily on this approach for fixed hardware limitations.

Runtime Capability Negotiation #

• Implement a dedicated function to query component capabilities at runtime, returning a structured set of supported features and limits. Upper-layer code can use this during initialization to adjust behavior proactively. Example:

  typedef struct {
      bool supports_10bit_address;
      uint32_t max_frequency_hz;
      bool supports_clock_stretching;
  } I2C_Capabilities;
  
  I2C_Capabilities i2c_get_capabilities(uint8_t bus_id);
  

  If 10-bit addresses aren't supported, upper code can fall back to 7-bit instead of hitting runtime errors later.

Polymorphic Hardware Abstraction Layers (HAL) #

• Use function pointer tables (in C) or abstract base classes (in C++) to define a uniform peripheral interface, with hardware-specific implementations that encapsulate feature support. Example:

  typedef struct {
      void (*init)(void);
      I2C_Capabilities (*get_capabilities)(void);
      int (*write)(uint8_t addr, uint8_t* data, size_t len);
  } I2C_Driver;
  
  // Hardware-specific implementation for Bus 1
  static const I2C_Driver i2c_bus1_driver = {
      .init = i2c_bus1_init,
      .get_capabilities = i2c_bus1_get_capabilities,
      .write = i2c_bus1_write,
  };
  

  Upper code interacts with any I2C bus through the same interface, while the driver handles feature-specific logic behind the scenes.

Configuration Validation Hooks #

• Add validation steps to configuration functions to catch unsupported settings before they cause issues. Example:

  int i2c_set_frequency(uint8_t bus_id, uint32_t freq_hz) {
      I2C_Capabilities caps = i2c_get_capabilities(bus_id);
      if (freq_hz > caps.max_frequency_hz) {
          return ERROR_UNSUPPORTED_FREQUENCY;
      }
      // Proceed with setting frequency
      return SUCCESS;
  }
  

  This prevents upper code from configuring the peripheral outside its supported range, with clear feedback instead of silent failures.

Self-Testing & Feature Reporting Utilities #

• Include lightweight self-test functions in drivers that verify supported features at startup or on demand, and log or expose results. Example:

  void i2c_run_self_test(uint8_t bus_id) {
      I2C_Capabilities caps = i2c_get_capabilities(bus_id);
      printf("I2C Bus %d Capabilities:\n", bus_id);
      printf("  10-bit Address Support: %s\n", caps.supports_10bit_address ? "Yes" : "No");
      printf("  Max Frequency: %d Hz\n", caps.max_frequency_hz);
      // Additional tests for clock stretching, etc.
  }
  

  This aids debugging and ensures feature support is documented in code and visible at runtime.

To wrap up, combining these techniques with the three methods you identified creates a layered approach:

• Use compile-time checks for fixed hardware limitations.
• Use runtime capability queries for dynamic or configurable features.
• Pair both with clear documentation and self-testing to reduce surprises during testing.

内容的提问来源于stack exchange，提问作者bit_ninja