158. Abstract Sensor Debugging

1. Data Abstraction (The Public API)

Designing a class where the user sees simple functions, but the complex logic happens privately.

class WiFiModule {
private:
    // Complex hidden details (User doesn't need to see these)
    void spi_write(uint8_t byte) { /* ... */ }
    void handshake_tcp() { /* ... */ }
    int socket_id;

public:
    // Simple Abstraction (User sees only this)
    void connect(const char* ssid, const char* pass) {
        spi_write(0x01); // Internal logic
        handshake_tcp(); // Internal logic
    }
};

int main() {
    WiFiModule wifi;
    // The user calls one simple function.
    // They don't know (or care) that it triggered 50 SPI transactions.
    wifi.connect("HomeNet", "1234");
}

2. Abstract Classes (Pure Interfaces)

Defining a blueprint that enforces what a device must do, without defining how.

// Abstract Base Class
class IMotor {
public:
    virtual void setSpeed(int speed) = 0; // Pure Virtual
    virtual void stop() = 0;
};

// The user code works with the "IMotor" abstraction,
// ignoring whether it's a DC Motor or Stepper Motor.
void emergency_shutdown(IMotor* m) {
    m->stop();
}

These two are often confused but are distinct.

1. HAL (Hardware Abstraction Layer)

This is the textbook definition of abstraction in firmware.

You write code like GPIO_Write(PIN_5, HIGH).

• Abstraction: "Set Pin 5 High".
• Implementation: On AVR, this writes to PORTB. On STM32, it writes to BSRR register. On Linux, it writes to a file /sys/class/gpio. Your application logic relies on the abstraction, making it portable.

2. Reducing Cognitive Load

A Junior Developer can use a complex driver (e.g., a FAT32 filesystem wrapper) by just calling file.open() and file.write(). They don't need to understand sectors, clusters, or allocation tables to use it effectively.