Universal Interface Technology in Embedded Software Development: Design, Implementation, and Practice

In embedded system development, universal interface technology is a core means to achieve module decoupling, hardware abstraction, and cross-platform compatibility. By defining standardized functions, data structures, and interaction protocols, it enables seamless collaboration among different modules (such as sensors, peripherals, communication components), hardware platforms (such as STM32, PIC, ARM Cortex-M series), and software versions. This article systematically explains embedded universal interface technology from design principles, core technologies, implementation methods, typical application scenarios to best practices, helping developers build flexible, maintainable, and scalable embedded systems.

1. Core Value of Universal Interface Technology: An Embedded Perspective

Embedded systems have characteristics of hardware diversity (e.g., the same function adapting to different MCUs), resource constraints (limited RAM/ROM space, limited CPU power), and long-term maintenance (firmware upgrades, function iterations). The value of universal interface technology is mainly reflected in the following four aspects:

1.1 Module Decoupling, Reducing Dependencies

The universal interface isolates the underlying hardware details from the upper business logic through an abstraction layer, allowing the driver module, application module, and communication module to be developed and tested independently. For example:

  • Sensor drivers only need to provide a universal interface for “initialization-reading-closing” without worrying about how the application layer processes the data;
  • The application layer only needs to call the interface functions without needing to know whether the sensor communicates via I2C or SPI, or the specific register configuration.

1.2 Hardware Abstraction, Simplifying Portability

Embedded systems often need to adapt to different hardware platforms (e.g., migrating from STM32F103 to STM32L476), and the universal interface can shield the underlying differences. For example:

  • Defining the <span>gpio_set_pin(uint8_t pin, bool state)</span> interface, where the underlying implementation varies based on different MCUs (STM32 uses HAL library, PIC uses register operations), without requiring changes to the upper layer.

1.3 Function Expansion, Supporting Iteration

New functions or hardware can be flexibly added through the universal interface without needing to refactor existing code. For example:

  • When adding a “temperature and humidity sensor” to the sensor interface, it only requires implementing the interface function and registering it, allowing the application layer to call through the unified interface without modifying other modules.

1.4 Standardized Collaboration, Improving Efficiency

In team development, the universal interface defines the “contract” between modules, allowing hardware engineers, driver engineers, and application engineers to develop in parallel based on the interface. For example:

  • Hardware engineers provide peripheral register mapping tables, driver engineers implement interface functions, and application engineers call interfaces to develop business logic, reducing communication costs.

2. Design Principles of Universal Interfaces: Adapting to Embedded Scenarios

The design of universal interfaces needs to balance functionality (meeting requirements), simplicity (resource constraints), and compatibility (cross-platform). The core principles are as follows:

2.1 Modularity: Single Responsibility

Each interface focuses on a specific type of function (e.g., the UART interface is responsible for data transmission and reception, the ADC interface is responsible for analog signal acquisition), avoiding “large and comprehensive” interfaces. For example:

  • Incorrect: Designing the <span>peripheral_control(uint8_t type, uint8_t cmd, void* data)</span> interface to handle UART, SPI, and I2C operations simultaneously;
  • Correct: Splitting into <span>uart_send(), spi_write(), i2c_read()</span> independent interfaces with clear responsibilities.

2.2 Abstraction: Hiding Implementation Details

Interfaces only expose “what to do” without revealing “how to do it.” For example:

  • The sensor interface <span>sensor_read(uint8_t id, float* data)</span> only needs to define inputs (sensor ID) and outputs (data pointer), without exposing I2C addresses, register addresses, and other low-level details.

2.3 Standardization: Unified Naming and Parameters

Interface naming, parameter order, and data types follow a unified specification to reduce learning costs. For example:

  • Function naming:<span>xxx_init(), xxx_deinit(), xxx_config(), xxx_read(), xxx_write()</span>;
  • Parameter order:<span>(handle/ID, input parameter, output parameter, length/flag)</span>;
  • Data types: Prefer using <span>stdint.h</span> defined fixed-length types (<span>uint8_t, int32_t</span>), avoiding platform-dependent types like <span>int, short</span>.

2.4 Compatibility: Backward Compatibility and Version Control

When changing interfaces, ensure that old version code can run normally, which can be achieved in the following ways:

  • New interfaces: Do not modify old interfaces, add new interfaces with version numbers (e.g., <span>uart_send_v2()</span>);
  • Extended parameters: Use structures to encapsulate parameters, and when adding fields, the old version ignores the new fields (the structure must be initialized to 0);
  • Version identification: Add a version number parameter in the interface (e.g., <span>uint8_t version</span>), and handle different logic based on the version number.

2.5 Lightweight: Resource Optimization

Embedded systems have limited resources, and interface design needs to be streamlined:

  • Reduce parameters: Avoid passing large structures (prefer passing pointers);
  • Minimize data types: Use <span>uint8_t</span> to represent status/flags instead of <span>uint32_t</span>;
  • Avoid dynamic memory: Do not use <span>malloc/free</span> inside the interface; if a buffer is needed, it should be provided by the caller (e.g., <span>uart_receive(uint8_t* buf, uint16_t len)</span>).

3. Core Implementation Technologies of Universal Interfaces

The implementation of embedded universal interfaces relies on function encapsulation, data structure abstraction, and registration mechanisms. The following are four core technologies:

3.1 Structure-based Interface Encapsulation

Encapsulating interface-related data members (state, configuration, handle) and function pointers (operation methods) through structures to achieve “object-oriented” interfaces. For example, a universal UART interface can be defined as:

// UART interface data structure (handle)
typedef struct {
    uint32_t baudrate;          // Baud rate
    uint8_t parity;             // Parity bit (0=no parity, 1=odd parity, 2=even parity)
    void* hw_instance;          // Hardware instance (peripheral handle for different MCUs, e.g., STM32's UART_HandleTypeDef)
    // Interface function pointers
    int (*init)(void* handle);  // Initialization
    int (*send)(void* handle, const uint8_t* data, uint16_t len);  // Send data
    int (*recv)(void* handle, uint8_t* data, uint16_t len);        // Receive data
} UartHandle;

// STM32 UART interface implementation
static int stm32_uart_init(void* handle) {
    UartHandle* uart = (UartHandle*)handle;
    // Call STM32 HAL library initialization code (omitted)
    return 0;
}

// Register STM32 UART interface
UartHandle stm32_uart1 = {
    .baudrate = 115200,
    .parity = 0,
    .hw_instance = &huart1,  // STM32 HAL library UART handle
    .init = stm32_uart_init,
    .send = stm32_uart_send,
    .recv = stm32_uart_recv
};

// Application layer call (no need to care about underlying hardware)
UartHandle* uart = &stm32_uart1;
uart->init(uart);          // Initialize
uart->send(uart, "test", 4);  // Send data

Advantages: Structures can carry hardware instances and configurations, and function pointers implement differentiated logic for different hardware platforms, allowing the application layer to call interfaces through a unified handle.

3.2 Function Pointer Table: Universal Algorithm and Driver Adaptation

Organizing function pointers of similar interfaces into an array (“function table”) allows for quick calls to different implementations via indexing, suitable for multi-device adaptation (e.g., multiple I2C sensors). For example, the sensor universal interface:

// Sensor type enumeration
typedef enum {
    SENSOR_TEMP,   // Temperature sensor
    SENSOR_HUMI,   // Humidity sensor
    SENSOR_PRESS   // Pressure sensor
} SensorType;

// Sensor interface function pointer type
typedef struct {
    int (*init)(uint8_t addr);       // Initialization (I2C address)
    int (*read)(uint8_t addr, float* data);  // Read data
} SensorOps;

// Temperature sensor implementation
static int temp_sensor_init(uint8_t addr) { /* I2C initialization logic */ }
static int temp_sensor_read(uint8_t addr, float* data) { /* Read temperature */ }

// Humidity sensor implementation
static int humi_sensor_init(uint8_t addr) { /* I2C initialization logic */ }
static int humi_sensor_read(uint8_t addr, float* data) { /* Read humidity */ }

// Sensor function table (index corresponds to SensorType)
SensorOps sensor_ops_table[] = {
    [SENSOR_TEMP] = {temp_sensor_init, temp_sensor_read},
    [SENSOR_HUMI] = {humi_sensor_init, humi_sensor_read},
    [SENSOR_PRESS] = {press_sensor_init, press_sensor_read}
};

// Generic sensor interface (application layer call)
int sensor_generic_init(SensorType type, uint8_t addr) {
    if (type >= sizeof(sensor_ops_table)/sizeof(SensorOps)) {
        return -1;  // Invalid type
    }
    return sensor_ops_table[type].init(addr);  // Call corresponding sensor's initialization function
}

Advantages: Adding a new sensor only requires adding an entry in the function table, and the application layer can call through the unified interface without modifying core logic.

3.3 Macro Definitions and Conditional Compilation: Cross-Platform Adaptation

Using macro definitions and conditional compilation to shield differences between different hardware platforms, achieving cross-platform compatibility of interfaces. For example, the universal GPIO interface:

// gpio.h (universal interface definition)
#include <stdint.h>
typedef enum {GPIO_INPUT, GPIO_OUTPUT} GpioMode;
void gpio_set_mode(uint8_t pin, GpioMode mode);
void gpio_write(uint8_t pin, uint8_t state);

// gpio_stm32.c (STM32 platform implementation)
#ifdef STM32F103xx
#include "stm32f1xx_hal.h"
void gpio_set_mode(uint8_t pin, GpioMode mode) {
    GPIO_InitTypeDef gpio_init;
    gpio_init.Pin = 1 << pin;
    gpio_init.Mode = (mode == GPIO_OUTPUT) ? GPIO_MODE_OUTPUT_PP : GPIO_MODE_INPUT;
    HAL_GPIO_Init(GPIOA, &gpio_init);  // Assume using GPIOA
}
// ... (other function implementations)
#endif

// gpio_pic.c (PIC platform implementation)
#ifdef PIC16F877A
#include <pic16f877a.h>
void gpio_set_mode(uint8_t pin, GpioMode mode) {
    if (mode == GPIO_OUTPUT) {
        TRISA &= ~(1 << pin);  // Set TRISA register to output
    } else {
        TRISA |= (1 << pin);   // Set TRISA register to input
    }
}
// ... (other function implementations)
#endif

Advantages: By using <span>#ifdef</span> to distinguish different platform codes, the same interface header file can adapt to multiple hardware, and the corresponding implementation is selected at compile time based on the target platform.

3.4 Interface Registration Mechanism: Dynamic Binding and Extension

By registering functions to “register” interface implementations into the system, achieving runtime dynamic binding, suitable for plug-in modules (e.g., hot-pluggable sensors). For example, the universal communication interface registration:

// Communication interface type definition
typedef enum {COMM_UART, COMM_SPI, COMM_I2C} CommType;
typedef struct {
    CommType type;
    int (*send)(const uint8_t* data, uint16_t len);
    int (*recv)(uint8_t* data, uint16_t len);
} CommInterface;

// Interface registration linked list (stores registered interfaces)
typedef struct CommNode {
    CommInterface iface;
    struct CommNode* next;
} CommNode;
static CommNode* comm_list = NULL;

// Register interface function
void comm_register(CommInterface* iface) {
    CommNode* node = (CommNode*)malloc(sizeof(CommNode));  // In actual embedded systems, use static memory
    node->iface = *iface;
    node->next = comm_list;
    comm_list = node;
}

// Find interface function (by type)
CommInterface* comm_find(CommType type) {
    CommNode* node = comm_list;
    while (node) {
        if (node->iface.type == type) {
            return &node->iface;
        }
        node = node->next;
    }
    return NULL; // Not found
}

// Application layer usage
CommInterface uart_iface = {COMM_UART, uart_send, uart_recv};
comm_register(&uart_iface);  // Register UART interface

CommInterface* comm = comm_find(COMM_UART);
if (comm) {
    comm->send("data", 4);  // Call UART send
}

Advantages: Supports dynamically adding interfaces (e.g., registering interfaces after detecting new sensors at runtime) without modifying core framework code, adhering to the “open-closed principle”.

4. Typical Application Scenarios and Code Examples

Universal interface technology is widely applied in embedded systems. The following are five core scenarios and practical code:

4.1 Peripheral Driver Abstraction Interface

Scenario: The same type of peripherals (e.g., UART, SPI) across different MCUs have significant interface differences. The universal interface shields these differences, enabling cross-platform reuse of drivers.

Example: Universal UART Driver Interface

// uart.h (universal interface definition)
#include <stdint.h>
#include <stdbool.h>

// UART configuration parameter structure (extended compatibility)
typedef struct {
    uint32_t baudrate;          // Baud rate
    uint8_t parity;             // 0=no parity, 1=odd, 2=even
    uint8_t stop_bits;          // 1 or 2
    bool flow_control;          // Flow control enable
} UartConfig;

// UART handle (opaque structure, hiding implementation details)
typedef struct UartHandle UartHandle;

// Universal interface functions
UartHandle* uart_init(uint8_t port, UartConfig* config);  // Initialize
int uart_send(UartHandle* handle, const uint8_t* data, uint16_t len);  // Send
int uart_recv(UartHandle* handle, uint8_t* data, uint16_t len, uint32_t timeout);  // Receive
void uart_deinit(UartHandle* handle);  // Deinitialize

// stm32_uart.c (STM32 platform implementation)
struct UartHandle {
    UART_HandleTypeDef hal_handle;  // STM32 HAL library handle
};

UartHandle* uart_init(uint8_t port, UartConfig* config) {
    UartHandle* handle = malloc(sizeof(UartHandle));  // Actual use static memory
    handle->hal_handle.Instance = (port == 0) ? USART1 : USART2;
    handle->hal_handle.Init.BaudRate = config->baudrate;
    // ... (other HAL configurations)
    HAL_UART_Init(&handle->hal_handle);
    return handle;
}

// ... (other function implementations, calling HAL_UART_Transmit, etc.)

// pic_uart.c (PIC platform implementation, omitted)

Advantages: The application layer operates UART through interfaces like `uart_init(), uart_send()`, without modifying code to adapt to different MCUs like STM32, PIC, etc.

4.2 Sensor Data Interaction Interface

Scenario: Various sensors (e.g., temperature and humidity, pressure, light) need to report data to the main control module. The universal interface standardizes data formats and interaction processes.

Example: Universal Sensor Data Interface

// sensor.h (universal interface definition)
#include <stdint.h>

// Sensor type and data ID
typedef enum {
    SENSOR_TEMP = 0x01,  // Temperature (°C, float)
    SENSOR_HUMI = 0x02,  // Humidity (% , float)
    SENSOR_LUX = 0x03   // Light (lux, uint32_t)
} SensorDataID;

// Sensor data structure (universal format)
typedef struct {
    uint8_t sensor_id;    // Sensor ID (distinguishing multiple sensors)
    SensorDataID data_id; // Data type ID
    union {               // Data union (supporting multiple types)
        float f_val;
        uint32_t u32_val;
        int32_t i32_val;
    } data;
} SensorData;

// Sensor callback function (notifying application layer when data is ready)
typedef void (*SensorCallback)(SensorData* data);

// Universal interface functions
int sensor_register_callback(uint8_t sensor_id, SensorCallback cb);  // Register callback
int sensor_report_data(SensorData* data);  // Report data (called by sensor driver)

// Application layer implementation
void app_sensor_handler(SensorData* data) {
    switch (data->data_id) {
        case SENSOR_TEMP:
            printf("Temp: %.2f°C\n", data->data.f_val);
            break;
        // ... (other data processing)
    }
}

// Register callback during initialization
sensor_register_callback(0x01, app_sensor_handler);  // Register callback for sensor 0x01

Advantages: The sensor driver only needs to fill in data according to the `SensorData` format and call `sensor_report_data()`. The application layer processes all sensor data through a unified callback, and when adding new sensors, there is no need to modify application layer logic.

4.3 Communication Protocol Interface

Scenario: Embedded systems often involve various communication protocols (e.g., Modbus, CANopen, custom protocols). The universal interface standardizes protocol parsing and encapsulation processes.

Example: Universal Protocol Interface

// protocol.h (universal interface definition)
#include <stdint.h>

// Protocol packet structure
typedef struct {
    uint8_t dev_addr;      // Device address
    uint8_t cmd;           // Command code
    uint8_t* data;         // Data payload
    uint16_t data_len;     // Data length
    uint16_t crc;          // Checksum
} ProtocolPacket;

// Protocol interface function pointer type
typedef struct {
    int (*pack)(ProtocolPacket* pkt, uint8_t* buf, uint16_t* buf_len);  // Pack
    int (*unpack)(const uint8_t* buf, uint16_t buf_len, ProtocolPacket* pkt);  // Unpack
    uint16_t (*crc_calc)(const uint8_t* data, uint16_t len);  // Checksum calculation
} ProtocolOps;

// Modbus protocol implementation
ProtocolOps modbus_ops = {
    .pack = modbus_pack,
    .unpack = modbus_unpack,
    .crc_calc = modbus_crc16
};

// Custom protocol implementation
ProtocolOps custom_ops = {
    .pack = custom_pack,
    .unpack = custom_unpack,
    .crc_calc = custom_crc8
};

// Universal protocol processing function
int protocol_process(ProtocolOps* ops, ProtocolPacket* pkt, uint8_t* tx_buf, uint16_t* tx_len) {
    return ops->pack(pkt, tx_buf, tx_len);  // Call specific protocol's packing function
}

Advantages: By switching the `ProtocolOps` structure, the same application layer code can adapt to different communication protocols like Modbus and custom protocols, achieving “one logic, multiple protocol support”.

4.4 Cross-Platform Configuration Interface

Scenario: In embedded systems, hardware configurations (e.g., pin assignments, peripheral enables) need to be adjusted based on different hardware versions. The universal configuration interface achieves centralized management and dynamic loading of configuration parameters.

Example: Universal Configuration Interface

// config.h (universal interface definition)
#include <stdint.h>

// Configuration item ID
typedef enum {
    CFG_GPIO_PIN,    // GPIO pin configuration
    CFG_UART_BAUD,   // UART baud rate
    CFG_ADC_CHANNEL  // ADC channel
} ConfigID;

// Configuration value union
typedef union {
    uint32_t u32_val;
    uint8_t u8_val[4];
} ConfigValue;

// Configuration interface functions
int config_get(ConfigID id, ConfigValue* value);  // Get configuration
int config_set(ConfigID id, ConfigValue* value);  // Set configuration
int config_load(void);  // Load configuration from Flash
int config_save(void);  // Save configuration to Flash

// config_impl.c (implementation, based on Flash storage)
typedef struct {
    ConfigID id;
    ConfigValue default_val;  // Default value
    ConfigValue current_val;  // Current value
} ConfigItem;

// Configuration table (different hardware versions adapt by modifying this table)
ConfigItem config_table[] = {
    {CFG_GPIO_PIN, {.u32_val = 0x00000001}, {0}},  // Default PA0
    {CFG_UART_BAUD, {.u32_val = 115200}, {0}},
    {CFG_ADC_CHANNEL, {.u32_val = 3}, {0}}  // Default ADC3
};

int config_get(ConfigID id, ConfigValue* value) {
    for (int i = 0; i < sizeof(config_table)/sizeof(ConfigItem); i++) {
        if (config_table[i].id == id) {
            *value = config_table[i].current_val;
            return 0;
        }
    }
    return -1;
}

Advantages: By modifying the `config_table`, the configuration needs of different hardware versions can be adapted without modifying application layer code. Configuration parameters can be stored in Flash, supporting runtime modifications.

5. Best Practices and Pitfalls Guide

5.1 Interface Documentation Standards

  • Must include: Function description, parameter explanation (input/output/value range), return values (error code definitions), calling examples, notes (e.g., thread safety, execution time);
  • Example template:
    “`c
    /**
    * @brief Read sensor data
    * @param[in] sensor_id Sensor ID (0-15)
    * @param[out] data Output data pointer (float array, length at least 1)
    * @param[in] data_len Data length (currently supports 1)
    * @return 0=success, -1=invalid ID, -2=data not ready, -3=communication error
    * @note 1. Ensure the sensor is initialized before calling
    * 2. Execution time is about 5ms, not supported in interrupt context
    */
    int sensor_read(uint8_t sensor_id, float* data, uint8_t data_len);
    “`

5.2 Error Handling Mechanism

  • Unified error codes: Define global error codes (e.g., <span>ERR_OK=0, ERR_NULL_PTR=-1, ERR_TIMEOUT=-2</span>), avoiding independent error code definitions for each interface;
  • Error propagation: Interface functions return error codes, not using global variables to store error states, making it easier to locate issues;
  • Fault-tolerant design: Critical interfaces provide default behaviors (e.g., using default values when configuration parameters are invalid).

5.3 Compatibility Testing

  • Forward compatibility testing: New interfaces must verify that old version application code runs normally;
  • Cross-platform testing: Verify interface functionality in target hardware platforms (e.g., STM32, PIC) and simulation environments;
  • Boundary testing: Test interface behavior with parameters as NULL, maximum values, and minimum values.

5.4 Resource Optimization Techniques

  • Static memory instead of dynamic allocation: Use <span>static</span> variables or global arrays to store interface handles, avoiding memory fragmentation caused by <span>malloc/free</span>;
  • Inline functions to reduce call overhead: Use <span>static inline</span> for simple interfaces (e.g., <span>gpio_write</span>) to reduce function call stack overhead;
  • Macro definitions to simplify repetitive code: Use macros to encapsulate common logic (e.g., register operations, error checks), but avoid excessive use of complex macros.

6. Conclusion

Universal interface technology is the cornerstone of modular, maintainable, and scalable embedded systems. By following the design principles of modularity, abstraction, and standardization, combined with implementation technologies such as structure encapsulation, function pointer tables, and conditional compilation, it is possible to build universal interfaces that adapt to multiple hardware and scenarios. In actual development, it is necessary to balance the functionality of interfaces with resource overhead, focus on documentation standards and compatibility testing, ultimately achieving the goal of “one design, multi-platform reuse”.

Mastering universal interface technology not only enhances the development efficiency and quality of embedded systems but also cultivates engineers’ “abstract thinking” and “system perspective”, laying a solid foundation for tackling complex embedded projects.

Leave a Comment